techwiz is not in the sudoers file. This incident will be reported.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Root Access Sudo Bug Found to Affect macOS Big Sur
- Thread starter MacRumors
- Start date
- Sort by reaction score
It would have meant a delay in 11.2, which might have been okay for many but I haven't been able to render a web page or restart reliably since 11.0. So I'll be happy with with that supplemental patch issued shortly that you mention.
Except this bug is more like:
You: "sudo give me complete control of your system, even though I'm not in /etc/sudoers"
Computer: "okay"
... But for single-user computers it's not such a big deal, IMNSHO.
”Users” in UNIX operating systems are different from ”users” in our language. Apart from your own accounts, there are system accounts and service accounts (which you may have never heard of), like root and nobody. Sudo vulnerability works on all accounts, including service accounts.
Not Apple's fault. macOS is built on an open source foundation with an open source kernel and boot loader. There are many more security issues for sure. As long as they patch quickly that's all we can expect of them.
On another tech website I frequent, a few commenters who help maintain Linux distros have noted that they weren't informed of the exploit until less than a week before it was publicly disclosed, which is a MASSIVE break from the standard practices of responsible disclosure that give vendors 90 days to patch these sorts of issues before going public. Moreover, the maintainers for a number of Linux distros weren't informed of the exploit at all, so they found out with the rest of us when the news exploded on Twitter.
From the sounds of things, Qualsys—the company that disclosed the exploit—is now taking a lot of heat for how they went about disclosing this issue. While it looks like they gave the sudo project sufficient time to put a fix together, that means nothing if you don't give vendors the chance to responsibly patch their products. Unfortunately, instead of giving those vendors a chance to patch sudo and safely test things to ensure they aren't introducing new bugs, they're forcing everyone to push out poorly tested updates.
For Apple's part, it would have been irresponsible for them to hastily rush a sudo patch in an update that was practically already out the door, so they made the right call by waiting. Unless there's evidence of widespread exploitation, waiting a few days so you can do your due diligence is almost always the right call.
From the sounds of things, Qualsys—the company that disclosed the exploit—is now taking a lot of heat for how they went about disclosing this issue. While it looks like they gave the sudo project sufficient time to put a fix together, that means nothing if you don't give vendors the chance to responsibly patch their products. Unfortunately, instead of giving those vendors a chance to patch sudo and safely test things to ensure they aren't introducing new bugs, they're forcing everyone to push out poorly tested updates.
For Apple's part, it would have been irresponsible for them to hastily rush a sudo patch in an update that was practically already out the door, so they made the right call by waiting. Unless there's evidence of widespread exploitation, waiting a few days so you can do your due diligence is almost always the right call.
They don’t HAVE to have physical access, the attacker just has to find a user that’s still trying to install the latest version of Flash.
For a security conscious... actually, even security aware user though? Physical access is likely the best vector.
Qualsys obviously really REALLY wanted to get their name out there, and now it is. Hope it was worth it for them
Or what about any installation of a tool from, say Github / or poison a LibreOffice mirror?They don’t HAVE to have physical access, the attacker just has to find a user that’s still trying to install the latest version of Flash.
For a security conscious... actually, even security aware user though? Physical access is likely the best vector.
Why? I run a non-admin account on my mac precisely to avoid priv. escal. bugs.
Essentially, this can only be done remotely if the user takes steps to make it happen.
When you take that into account (that you have a user that will help you to exploit them) there are far easier ways for malicious actors to get to them. It could be as simple as a call from “Apple” asking a user to download and install this software for your protection.There are SO many other social engineering vectors guaranteed to be more effective than this one.
Not if this is payload put into any of a dozen utilities that a lot of ppl install (e.g. Zoom, Spotify, Chrome plugin, Firefox plugin), but I think that this is a major security issue, regardless.Essentially, this can only be done remotely if the user takes steps to make it happen.
There are SO many other social engineering vectors guaranteed to be more effective than this one.
No, but still their responsibility to fix.
In any OS distribution, there should be a single vendor taking responsibility for stuff like this.
Apple (mostly, entirely?) takes this stuff seriously, so we should get a patch soon.
Or Windows or macOS, yes. If it ends up in trusted software from a trusted location, that could be problem. However, no malware developer is going to try to work the code into those known code bases. Why? Because it’s far easier (and far far more successful) to try to get a user to download Zoom from www.bestsiteforzoom.foreals via an email, for example. And again, at that point, you’re right back to “getting the user to help you to exploit them” via social engineering.
Any exploit that requires the user to allow you to run it is far less serious than an exploit that does NOT require user intervention. Is it serious that someone can just poison the milk in a person’s fridge? Yes. But, basic security measures (lock on the front door and leaving it closed most of the time) means they don’t have to ALSO put a lock on the milk, on the fridge, and on the kitchen door. It would be much easier for someone to convince this person to just add this “brain enhancement supplement” to their milk for them. LOL
And they do fix it. It's already patched. Just wasn't public. You know, process.No, but still their responsibility to fix.
In any OS distribution, there should be a single vendor taking responsibility for stuff like this.
Apple (mostly, entirely?) takes this stuff seriously, so we should get a patch soon.
Binary packages for all sort of Linux distro and also MacOS. I didn’t tried it myself and it looks it installs Sudo command in /usr/local/bin instead of /usr/bin so I guess you should remove the original one or modify paths...
www.sudo.ws
Download Sudo
Sudo is distributed in source and and binary package formats. For information on how the binary packages are built, see building packages. All source distributions and binary packages are signed with Todd’s PGP key. For .rpm and .deb packages, the signature is embedded in the package file...
www.sudo.ws
Modifying the path would be no protection against a bad actor running the vulnerable version of sudo if it's still on disk.Binary packages for all sort of Linux distro and also MacOS. I didn’t tried it myself and it looks it installs Sudo command in /usr/local/bin instead of /usr/bin so I guess you should remove the original one or modify paths...
Download Sudo
Sudo is distributed in source and and binary package formats. For information on how the binary packages are built, see building packages. All source distributions and binary packages are signed with Todd’s PGP key. For .rpm and .deb packages, the signature is embedded in the package file...
and we only need to look at the lead - Federighi playing his best hits all over again - 2ND and possibly 3rd major Sudo screwup! Every build should be fully checked going forward.
Oh I thought this was first occurred in Catalina/Mavericks.High Sierra all over again.