6 ms·

Local Privilege Escalation in OpenBSD's Dynamic Loader

141 points by lelf 7y ago

ajross 7y ago
Ouch. Been a rough week for OpenBSD. And their errata description linked from the CVE seems... sorta obfuscatory: "ld.so may fail to remove the LD_LIBRARY_PATH environment variable for set-user-ID and set-group-ID executables in low memory conditions." This is true, but really fails to capture the fact that this is a trivially exploitable local root. "Low memory conditions" refers not to global system state but to the availability of memory to the process, which is under the control of the attacker via setrlimit(). Not good, folks.
- duelingjello 7y ago
  The CVE is text is accurate, the commit is an abbreviation. I wish they would've included the CVE in the commit message though. OpenBSD through 6.6 allows local users to escalate to root because a check for LD_LIBRARY_PATH in setuid programs can be defeated by setting a very small RLIMIT_DATA resource limit. When executing chpass or passwd (which are setuid root), _dl_setup_env in ld.so tries to strip LD_LIBRARY_PATH from the environment, but fails when it cannot allocate memory. Thus, the attacker is able to execute their own library code as root. Also, certain system calls like set(e)[gu]id should be pledged() opt-out rather than opt-in. It's probably a breaking change in a lot of software, but only some calls should ever be called in limited scopes where they're used and then prevented from being called ordinarily. You don't all the always doors unlocked, especially the ones that lead outside from the 11th floor without a fire escape, if you're only using a few of them.
  - tedunangst 7y ago
    Since passwd requires setuid, it would obviously choose to be able to call setuid.
  - deleted 7y ago
    [deleted]
- asveikau 7y ago
  I think it's actually been a good week for OpenBSD. Last week, all of those issues were unpatched.
  - bouncycastle 7y ago
    Hopefully next week will be better.
duelingjello 7y ago
Here's the patch: https://github.com/openbsd/src/commit/eee3c75f9abd5ea51e066dd0fe6b1efa470e4d0c https://github.com/openbsd/src/commit/eee3c75f9abd5ea51e066d... https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/loader.c.diff?r1=1.187&r2=1.187.2.1&f=h https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/...
- cryptonector 7y ago
  My preference would be to check if issetugid() then remove all env vars from environ[] that start with "LD". Don't even getenv() them.
saagarjha 7y ago
More interesting link: https://www.openwall.com/lists/oss-security/2019/12/11/9 https://www.openwall.com/lists/oss-security/2019/12/11/9
- dang 7y ago
  Ok, we've changed to that from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19726 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1972.... Thanks!
bilekas 7y ago
This is quite a clever approach, and to be honest I feel its quite trivial.. Surprising though they have had a bad week!
- blattimwind 7y ago
  For most projects I agree, but with OpenBSD every issue that is discovered seems to result in much more than just a simple fix. I bet the OpenBSD developers are going through their code with a very fine comb these days and look long and hard at execs and memory error handling.
jmiserez 7y ago
>We thank Theo de Raadt and the OpenBSD developers for their incredibly quick response: they published a patch for this vulnerability in less than 3 hours. Wow!
cesarb 7y ago
The problem with set-user-ID executables is that they (and the dynamic loader they use) effectively operate in a "blacklist" basis: there's a list of "evil" things they have to protect against (in this case, environment variables controlling the dynamic loader), and if they fail to protect against one of them (in this case, the dynamic loader didn't think of protecting against low RLIMIT_DATA, though a component called later by chpass did) it's game over. Contrast with something like a service called over dbus: the caller has little to no control over the service's environment, and the most the caller can do is try to confuse it with nonsense dbus calls. It's a "whitelist" basis: only calls the service understands (or think it understands) can do anything, everything else is rejected by default.
- useerup 7y ago
  This. setuid/SUID root was - and still is - a terrible idea. It is a (deliberate) hole in the security barrier. It was an idea spawned out of necessity because of the limited expressiveness of the standard Unix security model. Once you let a process run with root or other elevated capabilities, that process should be isolated so nothing about the process can be controlled by the unprivileged user. SUID root utilities violates that.
  - cryptonector 7y ago
    It was a reasonable enough mechanism for the 70s. It certainly isn't now. Now you want to do all legitimate local privilege escalations via IPC.
  - deleted 7y ago
    [deleted]
doodle_111 7y ago
C

141 points by lelf 7y ago

Ouch. Been a rough week for OpenBSD. And their errata description linked from the CVE seems... sorta obfuscatory: "ld.so may fail to remove the LD_LIBRARY_PATH environment variable for set-user-ID and set-group-ID executables in low memory conditions." This is true, but really fails to capture the fact that this is a trivially exploitable local root. "Low memory conditions" refers not to global system state but to the availability of memory to the process, which is under the control of the attacker via setrlimit(). Not good, folks.

duelingjello 7y ago
The CVE is text is accurate, the commit is an abbreviation. I wish they would've included the CVE in the commit message though. OpenBSD through 6.6 allows local users to escalate to root because a check for LD_LIBRARY_PATH in setuid programs can be defeated by setting a very small RLIMIT_DATA resource limit. When executing chpass or passwd (which are setuid root), _dl_setup_env in ld.so tries to strip LD_LIBRARY_PATH from the environment, but fails when it cannot allocate memory. Thus, the attacker is able to execute their own library code as root. Also, certain system calls like set(e)[gu]id should be pledged() opt-out rather than opt-in. It's probably a breaking change in a lot of software, but only some calls should ever be called in limited scopes where they're used and then prevented from being called ordinarily. You don't all the always doors unlocked, especially the ones that lead outside from the 11th floor without a fire escape, if you're only using a few of them.
- tedunangst 7y ago
  Since passwd requires setuid, it would obviously choose to be able to call setuid.
- deleted 7y ago
  [deleted]
asveikau 7y ago
I think it's actually been a good week for OpenBSD. Last week, all of those issues were unpatched.
- bouncycastle 7y ago
  Hopefully next week will be better.

duelingjello 7y ago

Here's the patch: https://github.com/openbsd/src/commit/eee3c75f9abd5ea51e066dd0fe6b1efa470e4d0c https://github.com/openbsd/src/commit/eee3c75f9abd5ea51e066d... https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/loader.c.diff?r1=1.187&r2=1.187.2.1&f=h https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/...

cryptonector 7y ago
My preference would be to check if issetugid() then remove all env vars from environ[] that start with "LD". Don't even getenv() them.

saagarjha 7y ago

More interesting link: https://www.openwall.com/lists/oss-security/2019/12/11/9 https://www.openwall.com/lists/oss-security/2019/12/11/9

dang 7y ago
Ok, we've changed to that from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19726 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1972.... Thanks!

bilekas 7y ago

This is quite a clever approach, and to be honest I feel its quite trivial.. Surprising though they have had a bad week!

blattimwind 7y ago
For most projects I agree, but with OpenBSD every issue that is discovered seems to result in much more than just a simple fix. I bet the OpenBSD developers are going through their code with a very fine comb these days and look long and hard at execs and memory error handling.

jmiserez 7y ago

>We thank Theo de Raadt and the OpenBSD developers for their incredibly quick response: they published a patch for this vulnerability in less than 3 hours. Wow!

cesarb 7y ago

The problem with set-user-ID executables is that they (and the dynamic loader they use) effectively operate in a "blacklist" basis: there's a list of "evil" things they have to protect against (in this case, environment variables controlling the dynamic loader), and if they fail to protect against one of them (in this case, the dynamic loader didn't think of protecting against low RLIMIT_DATA, though a component called later by chpass did) it's game over. Contrast with something like a service called over dbus: the caller has little to no control over the service's environment, and the most the caller can do is try to confuse it with nonsense dbus calls. It's a "whitelist" basis: only calls the service understands (or think it understands) can do anything, everything else is rejected by default.

useerup 7y ago
This. setuid/SUID root was - and still is - a terrible idea. It is a (deliberate) hole in the security barrier. It was an idea spawned out of necessity because of the limited expressiveness of the standard Unix security model. Once you let a process run with root or other elevated capabilities, that process should be isolated so nothing about the process can be controlled by the unprivileged user. SUID root utilities violates that.
- cryptonector 7y ago
  It was a reasonable enough mechanism for the 70s. It certainly isn't now. Now you want to do all legitimate local privilege escalations via IPC.
- deleted 7y ago
  [deleted]

doodle_111 7y ago