macOS Sudo vulnerability could give root privileges to any local user

Posted:
in macOS edited February 2021
A decade-old flaw found in the Sudo tool could lead to root access on Unix-based systems, including macOS Big Sur and earlier versions.

Sudo exploit in Unix could lead to root access
Sudo exploit in Unix could lead to root access


In January, security researchers disclosed a new vulnerability that can affect Unix-based operating systems. The exploit is identified as CVE-2021-3156, heap-based buffer overflow in Sudo. The exploit appears similar to a previously patched flaw called CVE-2019-18634.

The researchers at Qualys identified the exploit in Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2). They say it can affect other operating systems and distributions running the affected version of Sudo. All legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1 are affected.

The researchers note that users will need access to the computer to run the exploit. The exploit has existed for at least 10 years, however this is the first known documentation of it.

At first, it was not clear whether the vulnerability exists in macOS, but security researcher Matthew Hickey disclosed on Wednesday that the bug can also be exploited on Macs.

CVE-2021-3156 also impacts @apple MacOS Big Sur (unpatched at present), you can enable exploitation of the issue by symlinking sudo to sudoedit and then triggering the heap overflow to escalate one's privileges to 1337 uid=0. Fun for @p0sixninja pic.twitter.com/tyXFB3odxE

-- Hacker Fantastic (@hackerfantastic)


"To trigger it, you just have to overwrite argv[0] or create a symlink, which therefore exposes the OS to the same local root vulnerability that has plagued Linux users the last week or so," Matthew Hickey, co-founder of Hacker House told ZDNet.

Hickey's findings were confirmed by other prominent macOS security researchers. Patrick Wardle confirmed the findings to ZDNet, and vulnerability analyst Will Dormann verified the research in a tweet.

Can confirm with macOS Big Sur on both x86_64 and aarch64. pic.twitter.com/nQqQ8rskv7

-- Will Dormann (@wdormann)


Now that the exploit has been made known to Linux distributors it will likely be patched soon. Apple could release a security update with the patch at any time, but users can act sooner if they feel it is necessary.

Qualys offers a paid program that explains how to patch the exploit, however most users will not need to concern themselves.

Who's at risk, and how to protect yourself

The vulnerability exists in both older and recent macOS versions, so it appears that a significant number of Macs can be exploited. However, since the vulnerability requires local access to the computer and the exact exploitation has not been made public, it is unlikely any regular user will be affected prior to a macOS update.

Hickey said he notified Apple of the security flaw earlier on Wednesday. Apple has declined to comment while it investigates the issue.
«1

Comments

  • Reply 1 of 28
    auxioauxio Posts: 2,752member
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    rinosaurwatto_cobra
  • Reply 2 of 28
    Is not this like saying someone can burglarized your house once they are physically inside your house? /s
    edited February 2021 mwhitewatto_cobra
  • Reply 3 of 28
    zimmiezimmie Posts: 651member
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    sudo is not at all simple, and it has reached the level of complexity where it's basically impossible to confidently reason about it. The OpenBSD team made something simpler (doas) a while ago. Maybe this is the kick people need to finally adopt it more broadly.
    randominternetpersonasdasdwatto_cobra
  • Reply 4 of 28
    DAalsethDAalseth Posts: 2,955member
    I’m very surprised that Macs would be impacted. OS-X/macOS forked off from BSD a very long time ago. This exploit must really go back into the dark ages.
    randominternetpersonwatto_cobra
  • Reply 5 of 28
    glennh said:
    Is not this like saying someone can burglarized your house once they are physically inside your house? /s
    Not at all. It's a bit like saying someone can burglarize your house with ease if they manage to get into your gated community. It's definitely a Bad Thing. For example, it means that if you download and run malware, the malware wouldn't have to go through an authentication dialog to get administrative access.

    DAalseth said:
    I’m very surprised that Macs would be impacted. OS-X/macOS forked off from BSD a very long time ago. This exploit must really go back into the dark ages.
    No, about 10 years.

    Just because OS X forked off FreeBSD (and NetBSD, which for some reason most people don't realize was a big part of the code base too) a long time ago doesn't mean it doesn't inherit bugs that are much much newer. It keeps up-to-date (or at least not more than a year or three old, sigh) versions of almost all the open-source code it uses, which is a huge part of the OS. And that's good! Older-version bugs are usually more dangerous than newer-version ones.

    It may be that Apple hasn't patched it already because some genius there said to himself "hey, we don't even ship sudoedit, so we're not vulnerable!" That of course misses the point that an unprivileged attacker can just create a sudoedit link to sudo. I expect they'll get this fixed soon. It's egregious and easily corrected.
    elijahgwatto_cobra
  • Reply 6 of 28
    Hickey said he notified Apple of the security flaw earlier on Wednesday. Although the Cupertino tech giant declined to comment while it investigates the issue, the company will probably issue a patch sooner than later.

    Nice of him to give Apple an hour or two heads up before he went public.  Not that big a deal in this case (since the Linux exploit was publicized so the question of what it affects Mac OS was an obvious next question), but still.

    watto_cobra
  • Reply 7 of 28
    asdasdasdasd Posts: 5,686member
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 
    dewmeRayz2016watto_cobra
  • Reply 8 of 28
    asdasd said:
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 
    True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
    watto_cobra
  • Reply 9 of 28
    DAalsethDAalseth Posts: 2,955member
    DAalseth said:
    I’m very surprised that Macs would be impacted. OS-X/macOS forked off from BSD a very long time ago. This exploit must really go back into the dark ages.
    No, about 10 years.

    Just because OS X forked off FreeBSD (and NetBSD, which for some reason most people don't realize was a big part of the code base too) a long time ago doesn't mean it doesn't inherit bugs that are much much newer. It keeps up-to-date (or at least not more than a year or three old, sigh) versions of almost all the open-source code it uses, which is a huge part of the OS. And that's good! Older-version bugs are usually more dangerous than newer-version ones.

    It may be that Apple hasn't patched it already because some genius there said to himself "hey, we don't even ship sudoedit, so we're not vulnerable!" That of course misses the point that an unprivileged attacker can just create a sudoedit link to sudo. I expect they'll get this fixed soon. It's egregious and easily corrected.
    I am surprised that Apple would keep current with the OS packages. I figured once they split, they would keep things in house and proprietary. 
    watto_cobra
  • Reply 10 of 28
    DAalseth said:
    DAalseth said:
    I’m very surprised that Macs would be impacted. OS-X/macOS forked off from BSD a very long time ago. This exploit must really go back into the dark ages.
    No, about 10 years.

    Just because OS X forked off FreeBSD (and NetBSD, which for some reason most people don't realize was a big part of the code base too) a long time ago doesn't mean it doesn't inherit bugs that are much much newer. It keeps up-to-date (or at least not more than a year or three old, sigh) versions of almost all the open-source code it uses, which is a huge part of the OS. And that's good! Older-version bugs are usually more dangerous than newer-version ones.

    It may be that Apple hasn't patched it already because some genius there said to himself "hey, we don't even ship sudoedit, so we're not vulnerable!" That of course misses the point that an unprivileged attacker can just create a sudoedit link to sudo. I expect they'll get this fixed soon. It's egregious and easily corrected.
    I am surprised that Apple would keep current with the OS packages. I figured once they split, they would keep things in house and proprietary. 
    Why wouldn't they keep things up-to-date? The kernel is the primary thing that was forked, and at this point the macOS kernel (which is also used in all their other operating systems) is basically an Apple one-off. But, it produces a more-or-less standard Unix system call framework, threading and process model, and network stack. So, Unix and most Linux stuff can be compiled just fine. And, that stuff isn't Apple's differentiator. It is the graphical application layers that are Apple's differentiator. 

    That said, Apple doesn't do that great of a job of keeping their open source Unix/Linux utilities all that up-to-date. They don't view them as a competitive differentiator, so they don't go out of their way to keep them forked and modified for their own purposes. But, they also don't seem to go out of their way to keep them up-to-date either. But that seems more of an attention issue than anything related to ideological or business motives. 
    watto_cobra
  • Reply 11 of 28
    auxioauxio Posts: 2,752member
    asdasd said:
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 
    Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

    But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.
    edited February 2021 watto_cobraAlex1N
  • Reply 12 of 28
    auxioauxio Posts: 2,752member
    zimmie said:
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    sudo is not at all simple, and it has reached the level of complexity where it's basically impossible to confidently reason about it. The OpenBSD team made something simpler (doas) a while ago. Maybe this is the kick people need to finally adopt it more broadly.
    I agree that Apple should be paying attention to what the OpenBSD community is doing.  That said, every developer I've ever met thinks that recreating the world in their own image is better than trying to fix what already exists.  Right up until the point where they no longer have the time/desire to maintain the world they created, and the next developer who comes along has the same attitude.  Given that it's no small undertaking to integrate new, low level tools, I'm sure Apple (and others) don't want to spend the effort to change, just to have to change again.  They'll wait for a level of maturity, maintenance, and acceptance before changing.
    edited February 2021 watto_cobraasdasdrandominternetperson
  • Reply 13 of 28
    tronald said:
    DAalseth said:
    I am surprised that Apple would keep current with the OS packages. I figured once they split, they would keep things in house and proprietary. 
    Why wouldn't they keep things up-to-date? The kernel is the primary thing that was forked, and at this point the macOS kernel (which is also used in all their other operating systems) is basically an Apple one-off. But, it produces a more-or-less standard Unix system call framework, threading and process model, and network stack. So, Unix and most Linux stuff can be compiled just fine. And, that stuff isn't Apple's differentiator. It is the graphical application layers that are Apple's differentiator. 

    That said, Apple doesn't do that great of a job of keeping their open source Unix/Linux utilities all that up-to-date. They don't view them as a competitive differentiator, so they don't go out of their way to keep them forked and modified for their own purposes. But, they also don't seem to go out of their way to keep them up-to-date either. But that seems more of an attention issue than anything related to ideological or business motives. 
    Good explanation, and it's true, they get lazy about keeping up-to-date, which can be really aggravating. However, I am often pleasantly surprised by what they do update when I install a new release. So while they're lazy, they're not terminally lazy. Stuff does get synced. Sometimes their changes even get merged upstream.

    auxio said:
    Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

    But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.
    Not so. The faulty change is about a decade old. It just required a lot of trickiness to exploit, and nobody noticed it until now.
    watto_cobraAlex1N
  • Reply 14 of 28
    auxioauxio Posts: 2,752member

    auxio said:
    Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

    But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.
    Not so. The faulty change is about a decade old. It just required a lot of trickiness to exploit, and nobody noticed it until now.
    A decade is recent when one is talking about tools which are around 40 years old.  A thorough security audit would catch these kinds of holes, which I assumed would have happened at some point in 40 years.  But it may have done before this change.
    edited February 2021 watto_cobra
  • Reply 15 of 28
    zimmiezimmie Posts: 651member
    auxio said:
    zimmie said:
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    sudo is not at all simple, and it has reached the level of complexity where it's basically impossible to confidently reason about it. The OpenBSD team made something simpler (doas) a while ago. Maybe this is the kick people need to finally adopt it more broadly.
    I agree that Apple should be paying attention to what the OpenBSD community is doing.  That said, every developer I've ever met thinks that recreating the world in their own image is better than trying to fix what already exists.  Right up until the point where they no longer have the time/desire to maintain the world they created, and the next developer who comes along has the same attitude.  Given that it's no small undertaking to integrate new, low level tools, I'm sure Apple (and others) don't want to spend the effort to change, just to have to change again.  They'll wait for a level of maturity, maintenance, and acceptance before changing.
    TedU is great at fixing things which already exist, and when he decides it's time to start over, I'm inclined to believe him. It's like if John Carmack says you really should use a new game engine.

    The sudoers manpage alone is 2871 lines long. It opens with a "quick guide to Extended Backus-Naur Form", which is a language for defining the grammar of formal languages. That's gratuitously complicated. sudo's source tree has 374 C-language files in it right now.

    In comparison, the whole of doas is ~1400 lines of code, including manpages for doas itself and its config file, doas.conf. A program that small is possible to reason about effectively.
    watto_cobrarandominternetperson
  • Reply 16 of 28
    Thankfully, I am just not important enough for anyone to want to physically access my Mac and hack it. Even if they did, nothing much to see here. Dissidents from places like Saudi Arabia, Iran or China might want to be more careful ... 
    watto_cobra
  • Reply 17 of 28
    rcfarcfa Posts: 1,124member
    DAalseth said:
    I’m very surprised that Macs would be impacted. OS-X/macOS forked off from BSD a very long time ago. This exploit must really go back into the dark ages.
    No, not necessarily, because the utilities are not intrinsic to the kernel, and Apple largely follows FreeBSD, except where they need Apple-specific things.
    watto_cobraasdasd
  • Reply 18 of 28
    dewmedewme Posts: 5,658member
    asdasd said:
    auxio said:
    Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
    They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 
    True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
    Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers. 

    The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time. 
    watto_cobraAlex1N
  • Reply 19 of 28
    auxio said:

    auxio said:
    Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

    But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.
    Not so. The faulty change is about a decade old. It just required a lot of trickiness to exploit, and nobody noticed it until now.
    A decade is recent when one is talking about tools which are around 40 years old.  A thorough security audit would catch these kinds of holes, which I assumed would have happened at some point in 40 years.  But it may have done before this change.
    I am old enough to remember. But sudo is not that old.
    watto_cobra
  • Reply 20 of 28
    bulk001 said:
    Thankfully, I am just not important enough for anyone to want to physically access my Mac and hack it. Even if they did, nothing much to see here. Dissidents from places like Saudi Arabia, Iran or China might want to be more careful ... 
    Physical access is not required. You just need "local access". That means you need to be able to run code, or get a shell, and then you have root. It's one half of the holy grail- the other half is gaining non-privileged local access.

    Of course with catalina and big sur things are more complicated because of the protected boot volume. So it's harder to be persistent. But not by much.

    watto_cobra
Sign In or Register to comment.