Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Rich Freeman <rich0@gentoo.org>]

On Mon, Jan 29, 2018 at 11:35 PM, Nikos Chantziaras <realnc@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