4 ms·

That is a crazy number of CVEs. At a quick glace I am seeing a lot of local root exploits. Generally speaking if a attacker has an account on your system you ar

That is a crazy number of CVEs. At a quick glace I am seeing a lot of local root exploits. Generally speaking if a attacker has an account on your system you are already hosed. But this doesn't bode well for more vulnerabilities of this nature that don't require local root.

staticassertion 9y ago
> Generally speaking if a attacker has an account on your system you are already hosed. Keep in mind that software is moving towards a sandboxed world, especially with containers. Local attack surface is becoming increasingly valuable.
- geofft 9y ago
  On the other hand, all of these are local exploits against userspace software, not against the kernel. So assuming your container's security model works (... which is a big assumption), the most an attacker can do is gain privileges within the container, if you have setuid-container-root binaries inside, or perhaps get arbitrary code execution or something inside the container. But they shouldn't be able to escape. (That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)
  - staticassertion 9y ago
    Good points! I also appreciated your writeup on this class of attacks.
  - kevinr 9y ago
    As we have seen with old SSL versions and Windows XP, it will be 10-15 years before the whole world is migrated onto containerized software, so this exploit should have a long, long active life.
  - caf 9y ago
    It probably makes sense these days to differentiate between "local root" and "container root" in security advisories.
    - geofft 9y ago
      Well, none of these exploits are container-specific. They're against setuid binaries, and it just so happens that setuid binaries in CLONE_NEWUSER containers only give you root in the container, and not real root. Containers that don't use CLONE_NEWUSER and have setuid-root binaries do give you real root, though, and I believe e.g. Docker doesn't do user namespaces by default. Another perfectly valid way of working around the exploits is to just have an installation with no setuid binaries or file capabilities. This is difficult in a general-purpose OS that needs to be backwards compatible with traditional UNIXy things, but usually totally achievable if you're building a machine to run some specific service. (And in particular it should be really easy within a container, such that these attacks would get you neither container root nor host root.) A contained-process-to-actual-root exploit is basically either going to be an arbitrary code execution vulnerability in the kernel itself, which tends to be referred to as something more dramatic as "local root", or a logic flaw in the container security mechanisms of the kernel itself.
      - caf 9y ago
        Well yeah, the intended reading would be "if you're not running in a (user-namespaced) container, container root is local root". Maybe "namespace root" is a better term, though, where it's clear what it means if you're running in the init namespace. It seems to me that "local root" is quite commonly used for kernel code execution vulnerabilities. There's also the possibility of a flaw in a service running in the init namespace that is exposed to the container.
- deleted 9y ago
  [deleted]
bjornsing 9y ago
> Generally speaking if a attacker has an account on your system you are already hosed. Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?
- pja 9y ago
  Much larger attack surface => far easier to find exploitable bugs.
- fictioncircle 9y ago
  > Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them? [Core Services] + SSH is generally something you can harden effectively against attacks. [2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on. The simple fact is, there is just too much attack surface on a vanilla Linux box once you have an account that you can reliably do EVERYTHING you need to do to secure it 24/7/365. At least imho, given my time constraints/budget.
  - bjornsing 9y ago
    > [2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on. Does a modern Linux come with that many binaries SETUID?!? Sorry, I couldn't resist. :P But yea, I see your point. It's a bit sad though; that all these people's hard work (e.g. OP) is all in vain...
    - rodgerd 9y ago
      > that all these people's hard work (e.g. OP) is all in vain... Part of the reason people's hard work is in vain is because any time the topic of doing things better comes up, a cluster of developers will insist there's no point in improving e.g. filesystem because "once they're on the box, you're screwed." So it becomes a self-fullfilling prophecy.
kseifried 9y ago
There will probably be more CVEs as people find other setuid apps that can be manipulated (people know what to look for now).
cookiecaper 9y ago
I mean, it's certainly some level of access if there's a local privilege escalation, but it's not "your box is already pwned". Proper isolation and correct permissions on the system will keep the damage isolated. I've seen attacks that were more-or-less nerfed because they couldn't find an open local privilege escalation. I don't think these should be written off as "Well, you're screwed anyway" like we tend to do when discussing security against an attacker who has direct physical access to the hardware. Isolated user accounts are widely used as the model for running services because they provide significant (if non-total) benefit.

staticassertion 9y ago

> Generally speaking if a attacker has an account on your system you are already hosed. Keep in mind that software is moving towards a sandboxed world, especially with containers. Local attack surface is becoming increasingly valuable.

geofft 9y ago
On the other hand, all of these are local exploits against userspace software, not against the kernel. So assuming your container's security model works (... which is a big assumption), the most an attacker can do is gain privileges within the container, if you have setuid-container-root binaries inside, or perhaps get arbitrary code execution or something inside the container. But they shouldn't be able to escape. (That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)
- staticassertion 9y ago
  Good points! I also appreciated your writeup on this class of attacks.
- kevinr 9y ago
  As we have seen with old SSL versions and Windows XP, it will be 10-15 years before the whole world is migrated onto containerized software, so this exploit should have a long, long active life.
- caf 9y ago
  It probably makes sense these days to differentiate between "local root" and "container root" in security advisories.
  - geofft 9y ago
    Well, none of these exploits are container-specific. They're against setuid binaries, and it just so happens that setuid binaries in CLONE_NEWUSER containers only give you root in the container, and not real root. Containers that don't use CLONE_NEWUSER and have setuid-root binaries do give you real root, though, and I believe e.g. Docker doesn't do user namespaces by default. Another perfectly valid way of working around the exploits is to just have an installation with no setuid binaries or file capabilities. This is difficult in a general-purpose OS that needs to be backwards compatible with traditional UNIXy things, but usually totally achievable if you're building a machine to run some specific service. (And in particular it should be really easy within a container, such that these attacks would get you neither container root nor host root.) A contained-process-to-actual-root exploit is basically either going to be an arbitrary code execution vulnerability in the kernel itself, which tends to be referred to as something more dramatic as "local root", or a logic flaw in the container security mechanisms of the kernel itself.
    - caf 9y ago
      Well yeah, the intended reading would be "if you're not running in a (user-namespaced) container, container root is local root". Maybe "namespace root" is a better term, though, where it's clear what it means if you're running in the init namespace. It seems to me that "local root" is quite commonly used for kernel code execution vulnerabilities. There's also the possibility of a flaw in a service running in the init namespace that is exposed to the container.
deleted 9y ago
[deleted]

bjornsing 9y ago

> Generally speaking if a attacker has an account on your system you are already hosed. Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?

pja 9y ago
Much larger attack surface => far easier to find exploitable bugs.
fictioncircle 9y ago
> Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them? [Core Services] + SSH is generally something you can harden effectively against attacks. [2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on. The simple fact is, there is just too much attack surface on a vanilla Linux box once you have an account that you can reliably do EVERYTHING you need to do to secure it 24/7/365. At least imho, given my time constraints/budget.
- bjornsing 9y ago
  > [2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on. Does a modern Linux come with that many binaries SETUID?!? Sorry, I couldn't resist. :P But yea, I see your point. It's a bit sad though; that all these people's hard work (e.g. OP) is all in vain...
  - rodgerd 9y ago
    > that all these people's hard work (e.g. OP) is all in vain... Part of the reason people's hard work is in vain is because any time the topic of doing things better comes up, a cluster of developers will insist there's no point in improving e.g. filesystem because "once they're on the box, you're screwed." So it becomes a self-fullfilling prophecy.

kseifried 9y ago

There will probably be more CVEs as people find other setuid apps that can be manipulated (people know what to look for now).

cookiecaper 9y ago

I mean, it's certainly some level of access if there's a local privilege escalation, but it's not "your box is already pwned". Proper isolation and correct permissions on the system will keep the damage isolated. I've seen attacks that were more-or-less nerfed because they couldn't find an open local privilege escalation. I don't think these should be written off as "Well, you're screwed anyway" like we tend to do when discussing security against an attacker who has direct physical access to the hardware. Isolated user accounts are widely used as the model for running services because they provide significant (if non-total) benefit.