On Mon, Jan 29, 2018 at 11:35 PM, Nikos Chantziaras <rea...@gmail.com> wrote: > On 30/01/18 00:36, Henry Kohli wrote: >> >> Would it be usefull to do a emerge -e @world with the new GCC 7.3 ? > > These flags are for *affected* applications only. That means application > that: a) run third-party code, and b) do so in a sandbox.
While I agree that it doesn't make sense to go rebuilding everything right now, I did want to caution that Spectre is probably a bit wider-reaching than you're suggesting. The sandboxed code issue is actually more of a problem with meltdown as it doesn't require vulnerable interfaces to work - but meltdown has nothing to do with gcc 7.3. Meltdown does not require any process vulnerability to work - it just requires a vulnerable CPU and data mapped into virtual address space that shouldn't be accessible. Spectre is more about having vulnerable functions in your code being executable by untrusted code, acting on untrusted data. Now, a lot of sandboxes do have APIs in them that would be vulnerable, but the problem goes beyond this. Any kind of API/IPC mechanism, including sockets, could potentially be exploitable, as long as it is interacting with some kind of local process (perhaps indirectly). Spectre is about using data to trick a process to leak state via the side channel of the cache, and then using local code to probe the cache. If you had some program that listened on a socket and accepted a length and a string and then did a bounds check using the length, it might be exploitable if a local process could feed it data. Even if the process only listened for outside connections it might be vulnerable if a local process colluded with a remote host to make that connection. Now, the more directly coupled the untrusted process is to the vulnerable one the easier this would probably be to pull off. This is why the kernel system call interface is so attractive. That, and also the fact that kernel memory is of course a high-value target. How exploitable any particular process is depends a lot on the actual code/etc. Spectre should be seen as a class of vulnerabilities just like buffer overflows. Not every call to strcpy is vulnerable to a buffer overflow, but it is certainly an opportunity for one. Well, in the same way things like bounds checks or indirect calls that are associated with untrusted input are also opportunities. I imagine that other classes of Spectre will emerge over the coming years as well. To some degree compilers might be able to become smart enough on their own to detect vulnerable code and add protections. The question is whether that can be done with little overhead, vs having developers identify these points and mark them for the compiler (which I think is the current approach). Disclaimer: I'm definitely not a major authority in Spectre. However, the attack should not be considered limited to sandboxes and JIT and such. -- Rich
