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