Security Researchers Warn of a 'New Class' of Apple Bugs (techcrunch.com) 30
Since the earliest versions of the iPhone, "The ability to dynamically execute code was nearly completely removed," write security researchers at Trellix, "creating a powerful barrier for exploits which would need to find a way around these mitigations to run a malicious program. As macOS has continually adopted more features of iOS it has also come to enforce code signing more strictly.
"The Trellix Advanced Research Center vulnerability team has discovered a large new class of bugs that allow bypassing code signing to execute arbitrary code in the context of several platform applications, leading to escalation of privileges and sandbox escape on both macOS and iOS.... The vulnerabilities range from medium to high severity with CVSS scores between 5.1 and 7.1. These issues could be used by malicious applications and exploits to gain access to sensitive information such as a user's messages, location data, call history, and photos."
Computer Weekly explains that the vulnerability bypasses strengthened code-signing mitigations put in place by Apple on its developer tool NSPredicate after the infamous ForcedEntry exploit used by Israeli spyware manufacturer NSO Group: So far, the team has found multiple vulnerabilities within the new class of bugs, the first and most significant of which exists in a process designed to catalogue data about behaviour on Apple devices. If an attacker has achieved code execution capability in a process with the right entitlements, they could then use NSPredicate to execute code with the process's full privilege, gaining access to the victim's data.
Emmitt and his team also found other issues that could enable attackers with appropriate privileges to install arbitrary applications on a victim's device, access and read sensitive information, and even wipe a victim's device. Ultimately, all of the new bugs carry a similar level of impact to ForcedEntry.
Senior vulnerability researcher Austin Emmitt said the vulnerabilities constituted a "significant breach" of the macOS and iOS security models, which rely on individual applications having fine-grain access to the subset of resources needed, and querying services with more privileges to get anything else.
"The key thing here is the vulnerabilities break Apple's security model at a fundamental level," Trellix's director of vulnerability research told Wired — though there's some additional context: Apple has fixed the bugs the company found, and there is no evidence they were exploited.... Crucially, any attacker trying to exploit these bugs would require an initial foothold into someone's device. They would need to have found a way in before being able to abuse the NSPredicate system. (The existence of a vulnerability doesn't mean that it has been exploited.)
Apple patched the NSPredicate vulnerabilities Trellix found in its macOS 13.2 and iOS 16.3 software updates, which were released in January. Apple has also issued CVEs for the vulnerabilities that were discovered: CVE-2023-23530 and CVE-2023-23531. Since Apple addressed these vulnerabilities, it has also released newer versions of macOS and iOS. These included security fixes for a bug that was being exploited on people's devices.
TechCrunch explores its severity: While Trellix has seen no evidence to suggest that these vulnerabilities have been actively exploited, the cybersecurity company tells TechCrunch that its research shows that iOS and macOS are "not inherently more secure" than other operating systems....
Will Strafach, a security researcher and founder of the Guardian firewall app, described the vulnerabilities as "pretty clever," but warned that there is little the average user can do about these threats, "besides staying vigilant about installing security updates." And iOS and macOS security researcher Wojciech ReguÅa told TechCrunch that while the vulnerabilities could be significant, in the absence of exploits, more details are needed to determine how big this attack surface is.
Jamf's Michael Covington said that Apple's code-signing measures were "never intended to be a silver bullet or a lone solution" for protecting device data. "The vulnerabilities, though noteworthy, show how layered defenses are so critical to maintaining good security posture," Covington said.
"The Trellix Advanced Research Center vulnerability team has discovered a large new class of bugs that allow bypassing code signing to execute arbitrary code in the context of several platform applications, leading to escalation of privileges and sandbox escape on both macOS and iOS.... The vulnerabilities range from medium to high severity with CVSS scores between 5.1 and 7.1. These issues could be used by malicious applications and exploits to gain access to sensitive information such as a user's messages, location data, call history, and photos."
Computer Weekly explains that the vulnerability bypasses strengthened code-signing mitigations put in place by Apple on its developer tool NSPredicate after the infamous ForcedEntry exploit used by Israeli spyware manufacturer NSO Group: So far, the team has found multiple vulnerabilities within the new class of bugs, the first and most significant of which exists in a process designed to catalogue data about behaviour on Apple devices. If an attacker has achieved code execution capability in a process with the right entitlements, they could then use NSPredicate to execute code with the process's full privilege, gaining access to the victim's data.
Emmitt and his team also found other issues that could enable attackers with appropriate privileges to install arbitrary applications on a victim's device, access and read sensitive information, and even wipe a victim's device. Ultimately, all of the new bugs carry a similar level of impact to ForcedEntry.
Senior vulnerability researcher Austin Emmitt said the vulnerabilities constituted a "significant breach" of the macOS and iOS security models, which rely on individual applications having fine-grain access to the subset of resources needed, and querying services with more privileges to get anything else.
"The key thing here is the vulnerabilities break Apple's security model at a fundamental level," Trellix's director of vulnerability research told Wired — though there's some additional context: Apple has fixed the bugs the company found, and there is no evidence they were exploited.... Crucially, any attacker trying to exploit these bugs would require an initial foothold into someone's device. They would need to have found a way in before being able to abuse the NSPredicate system. (The existence of a vulnerability doesn't mean that it has been exploited.)
Apple patched the NSPredicate vulnerabilities Trellix found in its macOS 13.2 and iOS 16.3 software updates, which were released in January. Apple has also issued CVEs for the vulnerabilities that were discovered: CVE-2023-23530 and CVE-2023-23531. Since Apple addressed these vulnerabilities, it has also released newer versions of macOS and iOS. These included security fixes for a bug that was being exploited on people's devices.
TechCrunch explores its severity: While Trellix has seen no evidence to suggest that these vulnerabilities have been actively exploited, the cybersecurity company tells TechCrunch that its research shows that iOS and macOS are "not inherently more secure" than other operating systems....
Will Strafach, a security researcher and founder of the Guardian firewall app, described the vulnerabilities as "pretty clever," but warned that there is little the average user can do about these threats, "besides staying vigilant about installing security updates." And iOS and macOS security researcher Wojciech ReguÅa told TechCrunch that while the vulnerabilities could be significant, in the absence of exploits, more details are needed to determine how big this attack surface is.
Jamf's Michael Covington said that Apple's code-signing measures were "never intended to be a silver bullet or a lone solution" for protecting device data. "The vulnerabilities, though noteworthy, show how layered defenses are so critical to maintaining good security posture," Covington said.
Bullshit threats, are bullshit. (Score:2)
You can "warn" that greedy humans running companies don't give a shit about security all you want. Until it is proven in the wild, no one but idiots has a reason to believe you.
This article screams of "justified" responses via anti-malware solutions that hardly provide any real security. Stop selling threats and prove they exist instead. Your corrupt and greedy history, demands it.
Where's the beef? (Score:4, Insightful)
Emotions when reading article:
Title: omg it's the poxaclypse we're fucked forever. .. .. so?
First paragraph:... omg omg
Middle: ok..
Ending: this a nothing burger!
Fucking waste of time. That said, may spend a day or two researching/looking at code/reading more about it for curiosity's sake.
Re: (Score:3)
IMHO, security exploits really are only newsworthy when they break something in a way that the company can't easily fix by pushing out an update, or when the company is made aware of the exploit and responds with something along the lines of: "Whatever. We'll eventually fix it at some point between now and the heat death of the universe. Probably closer to the latter."
Re: (Score:3)
I don't guess about critical security or not. My critical data is never on a computer on a networked device.
Paranoid? No. Just realistic in knowing the Dark Triad guys who have tried to take me down.
A friend who does critical munitions targeting for a military contractor goes even further: into an isolated, electronically locked down room.
There are ways that work and then there is everything else subject to pilfering.
For malicious purposes or used for a jailbreak? (Score:5, Insightful)
Apple patched the NSPredicate vulnerabilities Trellix found in its macOS 13.2 and iOS 16.3 software updates, which were released in January. Apple has also issued CVEs for the vulnerabilities that were discovered: CVE-2023-23530 and CVE-2023-23531. Since Apple addressed these vulnerabilities, it has also released newer versions of macOS and iOS. These included security fixes for a bug that was being exploited on people's devices.
(emphasis mine)
I wonder if the vulnerability was being used as a means of jailbreaking, as Apple never makes the distinction in their bugfix notes (as close as you'll get to that is when they credit the discovery to a hacker or group known for releasing jailbreak software)? Apple basically considers you breaking into a device you own to be an equally serious security flaw as if it were a bad actor exploiting the device. It's basically exactly the situation we were warned about [youtube.com], all those years ago.
Re:For malicious purposes or used for a jailbreak? (Score:4, Informative)
Re: (Score:3, Insightful)
If you can use it to jailbreak the device, a malicious actor can use it to hack in too. Why would you want Apple to ignore jailbreak vectors and leave your device vulnerable with a documented vulnerability that has a code example?
Heart of the matter (Score:5, Informative)
"In reality the syntax of NSPredicate is a full scripting language. "
According to Apple documentation, NSPredicate was introduced in macOS 10.4, so... 2005 or so. Not exactly new code here. And they're just seeing this as a new class of exploit? It's kind of terrifying how many pieces of code like this exist in a modern OS, and how many lurking exploits undoubtedly still exist.
Pretty much every time some complex scripting system, or even a relatively complex file parser is introduced, exploits are almost guaranteed to fall out of it. How long did it take to really lock down Javascript? Java in the browser... never really got locked down at all. ActiveX was, of course, an unmitigated security disaster, as was adding powerful scripting to Office documents. There was Flash, where a new critical exploit was found every month or so. We eventually had to put PFD readers in a browser and sandbox the damned things to be safe. Almost every file format parser has needed critical bug fixes (images, zip, etc). And on and on and on...
I'm not sure there's a silver bullet here. Moving to memory safe languages will help with some classes of bugs / exploits, but not everything, of course. More knowledge of proper fuzz testing would also help, as there are some very good directed fuzz testing kits available now. Maybe being a bit aware that we now live in a world where you can't just throw it out there as soon as it "works"? I don't know...
Re:Heart of the matter (Score:5, Interesting)
In 10.4 it was still sane, it only became insane in 10.5, so 2 years later.
I just don't understand why though ... why does a query language have to be able to do arbitrary Objective-C method invocation of every library the process has access to? WTF? Who was using this for anything not inherently obfuscated?
Re: (Score:3)
How else are you going to query something? If you want to search for something, like say, someone called "Doe", you either have to build a search engine that is able to understand various file formats and index them, or you hand off the functionality to a delegating function wh
Re: (Score:3)
So you can jam all your user's data into CoreData and then do a query across it for something that isn't simple to express in something vaguely like SQL. No built in predicate has the ability to for example search for "colors in the P3 gambit that are not in NTSC". The built in predicates are also more or less lim
Re: (Score:2)
Every single parser.
We can't even write a JPEG parser without walking off the end of a buffer.
Re: (Score:2)
Well to be fair on macOS ImageIO is a service that operates inside a sandbox that literally has only permission to do local computations and communicate only on channels opened before it enters the sandbox. So it isn't exactly like macOS/iOS folks doing image decode actually have much reason to make sure the JPEG/PNG/JBIG parsers don't walk off the end of the buffer...
Re: (Score:2)
Interesting, I wasn't aware that's how images were loaded in the Apple ecosystem. Overall, that does seems like a sane way to handle image file parsing / loading, which has proven to be pretty dangerous, historically speaking. Still, I'd still advocate defense in depth with safe parsers, just in case someone figured out a way to poke their way out of the sandbox - which has been known to happen from time to time. No need to give the bad guys any crack at all.
Re: (Score:2)
Bugs were found, Apple patched them.
There is much more to it than that. The news is that Trellix just discovered these vulnerabilities only now and made it public.
Market for zero-day exploits [wikipedia.org]:
As a result, both national security agencies and criminals hide certain software vulnerabilities from both users and the original developer.
Governments face a trade-off between protecting their citizens' privacy through the reporting of vulnerabilities to private companies on one hand and undermining the communication technologies used by their targets—who also threaten the security of the public—on the other. The protection of national security through exploitation of software vulnerabilities unknown to both companies and the public is an ultimate resource for security agencies but also compromises the safety of every single user because any third party, including criminal organizations, could be making use of the same resource.
Not a 'New Class' (Score:2)
CVSS scores (Score:4, Interesting)
The vulnerabilities range from medium to high severity with CVSS scores between 5.1 and 7.1.
Question to the crowd here: Has anyone ever found the CVSS scores useful? Whenever I've looked, I found no correlation between CVSS score and real-world impact, and the calculation is a random jumble of terms, many of which are ignored in practice.
I don't have a better answer, I'm just wondering if these scores do more harm or more good.
Re: (Score:2)
Re: (Score:2)
Only if your ISMS dude was silly enough to include them in the policy. Which, I hope, in an age where the new 27001:2022 puts a stronger focus on repeatability and proven effectiveness, nobody does anymore. Well, I can dream, can't I?
Seriously, yes, I can see that happening. People are looking for metrics and will take any silly thing with a few big names behind it. So in that sense, it "works".
But yes, I meant in the real world.
Re: (Score:2)
"Boss, this is a 9.7 out of 10! You need to authorize a fix!"
All the World is a stage.
Re: (Score:2)
The score is a relative ranking of the severity of a flaw. However, actual real-world impact depends heavily on configuration that may mitigate the issue.
For example, let's
Re: (Score:2)
The score is a relative ranking of the severity of a flaw.
Is it? Is there any evidence for this? Independent review? Or is it just something people use because everyone uses it? This is the question at the core - does CVSS actually rank severity or is it more or less arbitrary and the results are no better than if someone eyeballed things?
Applying some formula to something does not automatically mean the result is any good.
Basically the score is - if you have to go through them, you should start with the ones closest to 10, then down the scores.
Provided the ranking actually does a good ranking. That's my question. Is there any evidence that it does? I have yet to see one. AFAIK no seri
Bugs already fixed by Apple (Score:2)
Re: (Score:3)
According to Trellix (formerly FireEye and McAfee Enterprise) in section The Vulnerabilities [trellix.com]:
There were also vulnerabilities of this class in services that could be accessed by any app, with no entitlements necessary. The first of these we found was in OSLogService, an XPC service that can be used to read potentially sensitive information from the syslog. More significantly an attacker can exploit an NSPredicate vulnerability in UIKitCore on the iPad. By setting malicious scene activation rules an app can achieve code execution inside of SpringBoard, a highly privileged app that can access location data, the camera and microphone, call history, photos, and other sensitive data, as well as wipe the device.
Buy Apple (Score:2)