public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
Date: Wed, 31 Jan 2018 09:24:45 -0500	[thread overview]
Message-ID: <CAGfcS_m8rG22R4dd+c5zaa8x65FG6KWv9Gt=tQc-oZM5XfTyBg@mail.gmail.com> (raw)
In-Reply-To: <p4s1cu$qjr$1@blaine.gmane.org>

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


      parent reply	other threads:[~2018-01-31 14:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29  9:11 [gentoo-user] gcc 7.3 + kernel 4.15 = spectre_v2 fixed Adam Carter
2018-01-29 17:50 ` [gentoo-user] " Ian Zimmerman
2018-01-29 18:35   ` Alexander Kapshuk
2018-01-30 21:20     ` Ian Zimmerman
2018-01-29 18:35   ` Mike Gilbert
2018-01-29 18:56     ` Mick
2018-01-29 19:32       ` Mike Gilbert
2018-01-29 22:36 ` [gentoo-user] " Henry Kohli
2018-01-30  4:35   ` [gentoo-user] " Nikos Chantziaras
2018-01-30 21:43     ` Rich Freeman
2018-01-31  9:16       ` Nikos Chantziaras
2018-01-31  9:48         ` Taiidan
2018-01-31 10:22           ` Nikos Chantziaras
2018-01-31 11:30             ` Martin Vaeth
2018-01-31 12:04               ` Mick
2018-01-31 12:20                 ` Nikos Chantziaras
2018-01-31 12:38                   ` Mick
2018-02-02 11:19                   ` Mick
2018-02-03  8:14                     ` Nikos Chantziaras
2018-01-31 11:17         ` Martin Vaeth
2018-01-31 12:07           ` Nikos Chantziaras
2018-01-31 13:23             ` Martin Vaeth
2018-01-31 14:34             ` Rich Freeman
2018-01-31 14:24         ` Rich Freeman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGfcS_m8rG22R4dd+c5zaa8x65FG6KWv9Gt=tQc-oZM5XfTyBg@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox