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

[Rich Freeman]

On Wed, Jan 31, 2018 at 4:16 AM, Nikos Chantziaras <realnc@×××××.com> 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.

Not at all.  This is the whole point of uids on linux and any POSIX
OS.  There is separation of privilege.

I should be able to give you ssh access to my database server using a
UID different from my database server, and it should be impossible for
you to damage my database (particularly if I am using resource
limits/etc).

Spectre allows local processes to probe the cache to obtain data
leaked from other processes running under different UIDs (or even the
kernel) which they should not have access to.

If MariaDB has vulnerable code listening on its socket, and you can
talk to that socket, and run code under a different UID, then you
could in theory read arbitrary data from MariaDB's memory.  That could
include tables you don't otherwise have privileges to read, or
possibly even credentials stored in memory that could allow you to
connect to the server and execute arbitrary queries.

Also, all this is requires is code running on the same CPU.  It could
be in a different VM, or a different container.

However, I wouldn't completely neglect local priv escalation attacks.
Sure, every sysadmin would prefer to not have code running on their
server that they didn't put there, but there is still such a thing as
defense in depth.  There is a reason we don't run all our daemons as
root.  If your server's ntp client somehow has a vulnerability and now
there is malicious code running under the ntp UID, it would still be
preferable that this code STAY contained in the ntp UID vs having
access to more mission-critical processes on the server.  Sure, you
will still want to wipe the server and install a clean one, but it
would be nice if you could do that after migrating your production
database/website/whatever to another server, versus having to revert
to the last backup.

--
Rich