Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Bug

Recent Root-Giving Sudo Bug Also Impacts macOS (zdnet.com) 24

A British security researcher has discovered this week that a recent security flaw in the Sudo app also impacts the macOS operating system, and not just Linux and BSD, as initially believed. From a report: The vulnerability, disclosed last week as CVE-2021-3156 (aka Baron Samedit) by security researchers from Qualys, impacts Sudo, an app that allows admins to delegate limited root access to other users. Qualys researchers discovered that they could trigger a "heap overflow" bug in the Sudo app to change the current user's low-privileged access to root-level commands, granting the attacker access to the whole system. The only condition to exploit this bug was that an attacker gain access to a system, which researchers said could be done by either planting malware on a device or brute-forcing a low-privileged service account. In their report last week, Qualys researchers said they only tested the issue on Ubuntu, Debian, and Fedora. They said that are UNIX-like operating systems are also impacted, but most security researchers thought the bug might impact BSD, another major OS that also ships with the Sudo app.
This discussion has been archived. No new comments can be posted.

Recent Root-Giving Sudo Bug Also Impacts macOS

Comments Filter:
  • Well duh (Score:4, Informative)

    by Anonymous Coward on Wednesday February 03, 2021 @03:32PM (#61024358)
    I'm pretty sure it affects many other Unixes (sp?) as well like Solaris, AIX, etc...
    • Re:Well duh (Score:5, Informative)

      by darkain ( 749283 ) on Wednesday February 03, 2021 @04:37PM (#61024542) Homepage

      Correct. As one of the people helping in the efforts to get an OS patched, yes, it pretty much effects everything it touches.

      Its been a two sided coin too. The closed-door email about the vuln only went out a week before public disclosure. NO WAY IN FUCKING HELL ENOUGH TIME to get any distro to patch, test, and roll out to all CDNs the patch to ensure stability and accuracy, along with auditing and errata notices to go with it. Not only that, but most of the distro maintainers I'm in contact with ONLY found out from retweets of the initial tweet by Qualys, pissing off A FUCKTON of people.

      But, the other side? Now a lot of these distro maintainers are creating their own info mailing distribution lists to help coordinate exploit news, so its not just the few biggest players getting updates. Qualys fucked up so hard, its creating a new sense of unity across distos and OSes. Kinda crazy!

  • Comment removed based on user account deletion
    • Re: (Score:1, Offtopic)

      by bobstreo ( 1320787 )

      I mean, what percentage uses sudo properly, in a way that this vulnerability matters?

      I would surmise that 99% of the world's sudo usage is by users of Ubuntu-based Linux distros who use it to pretend they aren't running their desktop as root, but it those cases, this vulnerability is irrelevant because these systems typically only have one user and a malicious process running as the user can already elevate to root using the user's account by just waiting for the user to invoke sudo and take advantage of the password timeout period.

      Aren't there better ways to delegate privileges nowadays in Unix-based OSs, or are they still not widely adopted?

      Corporate users, generally none have sudo privileges. Systems Administrators may have sudo access, but coupled with logging and TFA, it would tend to make it much more difficult for an exploit like this one.

      Home users, pretty much all have sudo access by default in most of the linux systems I've had at home.

      There also seems like there is a window after a sudo command which doesn't require re-entering the sudo password.

      The good news for home users is that ssh/sshd usually isn't installed by default on home s

      • by darkain ( 749283 ) on Wednesday February 03, 2021 @04:41PM (#61024554) Homepage

        Users dont need to be listed in the sudoers file to exploit this. It doesn't matter what their "access" is, the exploit takes place before any of those checks. Anonymous users (eg: "nobody" user) can exploit this to gain full root access. Any application running in the context of any user can exploit this. That's why its so dangerous.

      • The good news for home users is that ssh/sshd usually isn't installed by default on home systems, so remote access is almost impossible.

        So, that means that users of recent macOS versions (IIRC, from Sierra-onward, at least) are basically immune from remote installation or use of this exploit, right; since ssh is no longer part of the standard macOS build, right?

        • Not really. If really has nothing to do with ssh.

          Your web browser, for example, runs as you. That means any exploit targeting your browser would run as you. Welp, now it runs as root.

          Maybe you open a good old fashioned xls file, a spreadsheet.
          That macro should run as your user. Nope, now the malicious macro does sudo to root.

          *Whatever* network services you might have running under whatever service accounts are suddenly effectively running as root; any exploit of any service becomes a root exploit.

          To see whi

    • by darkain ( 749283 ) on Wednesday February 03, 2021 @04:39PM (#61024552) Homepage

      Properly or not, doesn't matter. This isn't about "users", this is about chained exploits. Imagine a remote code execution vulnerability on a server, but it only runs in the context of that application's user (Apache/Nginx running as "www" for example). Those exploits can now be chained with the sudo exploit effortlessly to gain full root access to the entire system. THATS the issue we're all worried about.

    • by tlhIngan ( 30335 )

      The problem is sudo is quote bloated. It's around 400kloc, which given that 99% of users just use it as a way to run administrative commands, seems to be high on the "bloat" list.

      But that's because sudo can give very fine grained control - you can limit the commands a user can run as root. But almost no one uses those features.

      That's why there are sudo alternatives - and some of the simpler ones are only around 4kloc or so. It lacks all the features other than "authorized user can execute a command as root"

  • I maintain one of the doas ports (for those of you not familiar, it's like a minimal alternative to sudo). This past week I've been getting a lot of e-mails and support requests from macOS users. What I find weird is most of them are switching from sudo to doas in order to improve the security of their system, however they are running systems where the binary and configuration directories (/usr/local/bin and /usr/local/etc/bin) are world-writable. So anyone can add themselves to the sudo/doas configuration
  • by eneville ( 745111 ) on Wednesday February 03, 2021 @07:35PM (#61025180) Homepage

    I've been working on a sudo clone called please. Written in rust to avoid traditional c flaws. I suggest trying it out to get more diversity in the ecosystem. Or not, totally up to you.

    https://gitlab.com/edneville/p... [gitlab.com]

  • This rootkit is from a script-spinach known as Crussifer. His favorite song is "Spinach Castle Magic" and his favorite artist is JJ Kale.
  • Not necessarily a linux fan, but since the start, I've been at odds as to why this has been labeled a linux vulnerability.

    Its a problem/vulnerability with the application, not the operating system. And any Unix (or Unix clone) that has an earlier/non patched version of sudo should be affected.

    Why pick on linux for a sudo problem? Head scratcher here.

  • by nagora ( 177841 ) on Thursday February 04, 2021 @06:23AM (#61026504)

    Sudo is a complicated beast and has more than a whiff of systemd-itis about it. The configuration file is a nightmare (something systemd has taken to almost infinite levels) and the number of options supported means that it must be almost impossible to achieve full test coverage.

    So, I don't use it. I don't use systemd either. And I'm very happy working away on a Linux (desktop) system that has neither.

    Commercial interests (RH, Canonical) have driven the spread of these two horrible programs but those commercial interests are not my interests.

  • Long-term this might wind up being known primarily as a MacOS bug because, unlike Linux, there really isn't a way to upgrade the OS on a discontinued Mac to something that's secure.

    Sure, you could install NetBSD on it, maybe, but that's not something users will do.

    Linux users who are using an old distro lacking patches are far more likely to update to a modern distro (remind them that it'll usually be faster too).

    Even the non-CMOV folks have acceptable options.

    There's even an old Safari sandbox escape that

"Engineering without management is art." -- Jeff Johnson

Working...