On 31/01/18 11:48, taii...@gmx.com wrote:
On 01/31/2018 04:16 AM, Nikos Chantziaras wrote:
On 30/01/18 23:43, Rich Freeman wrote:
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.
Well, if you're running a local process that is trying to attack you,
you've been compromised already, imo.
Local processes are always trusted. If Spectre is a vulnerability that
can be exploited by trusted code, it's not really a vulnerability.
Trusted code is called "trusted" for a reason.
I wouldn't classify for instance running a multiplayer game in a VM as
"trusted" code, the whole point of hardware virtualization is that you
don't have to trust what is being executed there.
Not to mention the issue with most websites requiring javascript for no
reason to function properly.
Yeah, that's the kind of software that benefits from the Spectre
mitigation patches. Like browsers, virtualization or emulation software,
the kernel, etc.
Rebuilding the whole system with these flags on doesn't sound like a
good idea. Now, I don't know if it would hurt anything, but it's not
uncommon for build flags to break random stuff.
I haven't seen any word from anyone yet as to whether these flags are
actually recommended or not on a system-wide basis. The GCC patches were
primarily developed for the kernel, but there was no word about whether
or not people should build all their software with these flags or not.
So my educated guess is: No. Don't do that. If a package is affected, it
stands to reason that the upstream of that package would change their
build system to use these new flags where needed.
But as always: I could be wrong :-)
