Animesh Jain (via David Smith, Hacker News):
Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host.
[…]
In other words, set_cmnd()
is vulnerable to a heap-based buffer overflow, because the out-of-bounds characters that are copied to the “user_args” buffer were not included in its size (calculated at lines 852-853).
In theory, however, no command-line argument can end with a single backslash character: if MODE_SHELL
or MODE_LOGIN_SHELL
is set (line 858, a necessary condition for reaching the vulnerable code), then MODE_SHELL
is set (line 571) and parse_args()
already escaped all meta-characters, including backslashes (i.e., it escaped every single backslash with a second backslash).
In practice, however, the vulnerable code in set_cmnd()
and the escape code in parse_args()
are surrounded by slightly different conditions[…]
jeffbee:
All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includes no tests. There is no reason anyone should believe this fix is effective or complete, or that it does not introduce new defects.
Update (2021-02-05): Patrick Wardle:
macOS (including 11.2) appears to be vulnerable to the sudo heap-overflow bug (CVE-2021-3156) 🍎🐛 🤨
Hartley Charlton:
With some minor modifications, Hickey found that the sudo bug could be used to grant attackers access to macOS root accounts, and the discovery has now been verified by Carnegie Mellon University vulnerability analyst Will Dormann.
Bug C Programming Language Exploit Linux Mac macOS 11.0 Big Sur Parser Programming sudo Testing
Hector Simpson (via Ryan Jones):
Ultra high-resolution wallpapers, inspired by an OS X classic — available in several wide-gamut color editions, with easy installation on macOS, and a collection available for mobile devices.
The desktop versions of Aqueux support 6K resolution and P3 color spaces, switch based on system appearance, and include a package for macOS that installs them directly, complete with thumbnails.
These are nice. I like to have a different color for each space to help show where I am.
Previously:
HEIF Mac Mac OS X 10.4 Tiger macOS 11.0 Big Sur Spaces Wallpaper
Apple:
Xcode 12.4 includes SDKs for iOS 14.4, iPadOS 14.4, tvOS 14.3, watchOS 7.2, and macOS Big Sur 11.1. The Xcode 12.4 release supports on-device debugging for iOS 9 and later, tvOS 9 and later, and watchOS 2 and later. Xcode 12.4 requires a Mac with Apple silicon running macOS Big Sur 11 or later, or an Intel-based Mac running macOS Catalina 10.15.4 or later.
There’s no direct download yet, but apparently it hasn’t changed from the release candidate.
Previously:
Update (2021-01-28): The direct download is up and identical to the release candidate. See Xcode Releases for more links.
Mac macOS 11.0 Big Sur Programming Xcode
Corellium (tweet):
While we have previously supported virtual iPhone and iPad devices for Enterprise accounts, our Individual accounts only offered virtual Android devices. Now, both individuals and enterprises can virtualize both iOS and Android device models.
[…]
One of the other considerations we faced in introducing iOS-based devices for individual accounts is continuing our efforts to limit the use of our software for malicious purposes. We have always vetted our customers, and we have not only declined sales, but also revoked customer accounts for violating our terms. In this regard, we wanted to ensure we would be able to use the same vetting process for individuals that we already use for enterprises.
Previously:
Corellium iOS iOS 14 Virtualization
Chris Liscio:
Looking at the crash logs, I noticed that invoking -[AVAudioEngine mainMixerNode]
would fire some kind of internal exception. The API does not return any kind of error, nor is it documented that an exception could get raised. Theoretically, failure at this stage should be impossible!
Unfortunately for me, I had written the high-level engine management code in Swift (as was common/prescribed at the time), so I couldn’t even attempt to handle this exception to patch this behavior.
[…]
Just as last time, a 10.14.x update re-introduced the bug, but in a slightly different way.
[…]
Fast-forward to macOS 11, and the AirPods issue is back. In fact, it’s even worse now because there’s no workaround. […] If you’re listening to the Music app, everything’s running at full quality. Then, you load a project in Capo and your already-playing music now sounds like garbage.
Colin Cornaby:
AVAudioEngine has always struck me as a API with good intentions (doing what CoreAudio does in Obj-C/Swift) with questionable execution and missing features.
It’s just so strange that Apple would take their extremely impressive and feature rich audio toolbox and replace it with... well... this.
Update (2021-01-28): Simone Manganelli:
This has happened over and over and over with APIs throughout macOS in the past decade. PDFKit is a good example.
This is just another symptom of Apple’s annual software update cycle and a lack of commitment to fixing anything.
Francisco Tolmasky:
The Swift/ObjC relationship is like taking the traditional design of a game engine written in C++ with Lua scripting hooks and flipping it on its head, such that you instead wrote the game engine in JavaScript and provided the scripting interface in Haskell.
You can use an Objective-C wrapper to catch exceptions, but be careful trying to make a generic wrapper solution because it’s not safe to throw exceptions through Swift stack frames.
Chris Liscio:
Great news: I have found a resolution to the (latest of the) AVAudioEngine issues I’ve been seeing with AirPods in Big Sur.
[…]
I am still unable to work around the problem in my code and stop the error for my users. These are in-the-field configuration issues that I am powerless to resolve with a simple software update.
AVAudioEngine is still too limited in its feature set for me to consider (or advise) adopting it for a “pro audio” stack like that which powers something like GarageBand or Logic.
Chris Liscio:
I put together a sample project called CrappifyAudio that demonstrates the problem in a minimal way.
Update (2021-02-05): Chris Liscio (tweet):
AVAudioEngine
doesn’t give me an opportunity to state my “intentions” for using the engine explicitly on macOS. There is no API that lets me specify that I am building an output-only engine, and don’t require its input abilities.
The previous workaround was to pull the AUAudioUnit
instance out of the outputNode
and set its deviceID
to override the default device selection behavior. Unfortunately, this workaround no longer works because the aggregate device now appears to get created (activated?) when I call outputNode
.
[…]
This is the crux of the problem I’m dealing with here, and why I don’t want anything to do with this API anymore. It’s simply too magical for my tastes.
Audio Bug Capo Core Audio Mac Mac App macOS 10.13 High Sierra macOS 10.14 Mojave macOS 11.0 Big Sur Programming Swift Programming Language