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