Nikos Chantziaras <rea...@gmail.com> wrote: > > For example, if you don't trust Firefox, don't install Firefox. But you > *do* trust Firefox. What you don't trust is the JS code Firefox is > executing.
That's an artificial distinction, because it is actually firefox which is executing the code during the interpretation of JS. > So Firefox needs protection. The only "protection" firefox could be giving is that interpreted JS is not able to do anything (not access any file or any program outside of a well-defined sandbox). For various reasons, this is not the case and will not be the case in any foreseeable future. What does need protection is all the programs which can be accessed (almost no matter how indirectly) by JS code - which is almost everything running on a typical desktop. Admittedly, firefox can help by e.g. making it harder to use timers for the precise time measurement needed for "simple" spectre exploits. This is already happening, but this is independent of the mitigations provided by the compiler. > I was under the impression that it's the function that performs the call > that needs protection. The called function doesn't need protection, > because if it ends up being actually called, then it's too late already. The opposite is true. There should be no problem for any code (even untrusted) to query gnupg to verify the validity of the signature. But with the spectre exploits, this query might be used to get the secret key which gnupg must access. So it is gnupg which needs the protection (unless you want to make it much harder to use gnupg). > For example, if sandboxed, untrusted code wants to speculatively execute > a memcpy(), then the sandbox would need to call it on behalf of the > untrusted code. In my above example, it is gnupg which speculatively executes some code if queried e.g. to verify a signature. The "attacking" program then might use this fact (under some conditions) to understand which secret key was used. Everything which untrusted code can influence (no matter how indirectly) is possible subject to be exploited if it uses speculative execution. Therefore, the only way to be on the safe side is to avoid speculative execution altogether. > But if the sandbox is protected, the memcpy() call would > never be made speculatively, since retpoline will trap it. This means that the sandbox-code itself is protected from being "read" by other code. But already if e.g. a webpage uses libjpeg to render a picture (even if it would do it inside of an otherwise protected sandbox), and libjpeg uses speculative execution (which it does if you do not have compiled it with the new compiler switches), javascript might (theoretically) be used to get image data it normally has no access to. Admittedly, this is all very theoretical and whether it is actually possible to write working exploits is a different story (that's why I wrote "(under some conditions)" and "(theoretically)"): Not every speculative execution actually _can_ be exploited, but there is always a certain probability (the more direct the victim program can be accessed by the thief code, the higher the probability is).
