> There is a vulnerability in the SoCs that I discovered and reported where cache snooping bypasses CTRR at the AMCC level. You can "write" to read only memory ranges and, as long as those writes remain in snoopable cache, they are effective even though AMCC will block them and panic when they are written back. I didn't get any money for that one because the way I exploited it didn't apply to normal macOS (I used it to patch DCP code from m1n1), but now a nation state figured out how to use it for a real exploit chain. "Whoops".
So the problem is unified memory? CPU and GPU uses the same RAM but the GPU doesn’t have proper MMU protections in place, which lets an attacker write to RAM it shouldn’t be allowed to by doing it through the GPU instead of the CPU?
It's literally broken! It didn't work. The complaint is that the path from discovery of the hole to working exploit is longer. And... that's probably true. But that's optimizing the wrong side of the equation. An open system would have surfaced this bug long ago, possibly years ago (it's not clear how old this mistake is, but the claim seems to cover multiple Apple SOCs), and the vulnerable systems would have been limited to one version of the hardware that could feasibly have been replaced via warranty coverage or whatever. Now we're all stuck trying to patch around a fundamental hole in tens (hundreds?) of millions of phones.
> An open system would have surfaced this bug long ago, possibly years ago (it's not clear how old this mistake is, but the claim seems to cover multiple Apple SOCs), and the vulnerable systems would have been limited to one version of the hardware that could feasibly have been replaced via warranty coverage or whatever.
How long did it take for Spectre and Meltdown to be discovered? Some vulnerabilities are easy to spot in an open design, but the more novel the exploit, the longer the vulnerability can hide in plain sight.
I see this very often where encryption experts and FOSS advocates pooh-pooh obfuscation and opaqueness. "It's not REAL security", they say. And they are right.
This is like those Chinese outfits that laser off the part markings on ICs so others can't copy the design as easily. Eventually someone will find out what part number it is and the mitigation will be nullified. But it IS effective for a period.
In the same way obscurity provides a time bonus that must be worked through before exploitation can begin.
Hackers tend to complain very much about this obscurity stuff "all it does is waste people's time and it's not secure" which is exactly the point. Surely by now researchers must have realized that creating a 100 percent bulletproof security implementation is very unlikely when compared to how impenetrable any modern encryption system is, due to gotchas and flaws in the implementation details. And this is why obscurity slows down the discovery.
Denuvo DRM for new games is the same way. It is very hated but does work very well for the publisher at mitigating piracy for the initial 2-3weeks after a game launches where the bulk of sales happen.
DRM isn't a relevant comparison because there the explicit intention is to prevent users from accessing data they've already been given. Everyone knows this is not possible in a strong sense, time-wasting through obfuscation is the best DRM can hope for.
The other reason obfuscation makes sense for DRM is the threat actors are individual consumers, who have limited time and resources to devote to untangling the obfuscation, and limited reward for doing so.
Normally we might expect to see many such users combining their resources to fund a solution to their problem at scale (by founding a public business or foundation for de-obfuscating DRM), but the state has made doing this punishable by prison. So DRM is rendered effective not so much through good engineering but through the legal system. This is an adequate solution for companies when the threat actors are simple civilians who want to play video games.
except in this case, the attackers figured it out ages ago and everyone else was left in the dark.
The issue with obscurity is that attackers inherintly have a far higher incentive to try and understand obfuscated, undocumented messes than security researchers.
ELI5 por favor, is this a class of exploits that is a function of Apple's architecture, kind of like how specter was for the whole branch prediction thing IIRC? Or is this something that can be fixed with a software update and no performance impact.
From what I understand, there was an unused hardware register not used by the OS that was the entry way for this attack. It’s been patched with no performance impact and there was an earlier HN submission with more details. It took advantage of 4 or 5 bugs that have been patched. Warning, this has been SCREAMING state actor vs state actor
> Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake.
This appears to be used to direct write cache for testing purposes.
It's not an intentional backdoor.
It's more likely an insider leak of some private headers or something that gave someone the info necessary.
Or Apple left too much stuff in the debug info.
It would not be the first time either has happened.
Remember when someone discovering a powerful vulnerability meant that the community could find a solution and maybe even create a patch for everyone else?
Feels like that reality was far more secure than the current closed-source siloed one.
I absolutely love how this response is "explain this like I am five years old" and "I am out of the loop" -- the people who grew up with BAUD as a nomenclature are going to die.
In the days of BAUD, we danced with time,
Bits twirled and pirouetted, a rhythmic mime.
Modems hummed, a song of distant lands,
A symphony of data in unseen hands.
But now, oh now, we've left those days behind,
Bandwidth's embrace, a treasure we find.
No more the worries of a BAUDish plight,
In the realm of speed, we soar with delight.
Gone are the struggles, the slow and the strained,
Streaming through fibers, our data unchained.
A digital ballet, swift and so grand,
In the era of bandwidth, we boldly stand.
No longer confined to a BAUDish dream,
The internet whispers, a seamless stream.
Pixels paint pictures, words swiftly fly,
In the limitless expanse of the bandwidth sky.
So here's to the days of BAUD, now a tale,
A vintage echo in a high-speed gale.
We've moved beyond, to a faster shore,
In the bandwidth symphony, we dance evermore.
https://web.archive.org/web/20231229025641/https://www.kaspe...
Hector Martin (of the Asahi Linux project) has some nice commentary on it here: https://social.treehouse.systems/@marcan/111655847458820583
> There is a vulnerability in the SoCs that I discovered and reported where cache snooping bypasses CTRR at the AMCC level. You can "write" to read only memory ranges and, as long as those writes remain in snoopable cache, they are effective even though AMCC will block them and panic when they are written back. I didn't get any money for that one because the way I exploited it didn't apply to normal macOS (I used it to patch DCP code from m1n1), but now a nation state figured out how to use it for a real exploit chain. "Whoops".
Oooff
Is this like "micro-code patchable" or hard no?
3 replies →
So it probably also affects Android phones and SBC like RaspberryPi's?
5 replies →
So the problem is unified memory? CPU and GPU uses the same RAM but the GPU doesn’t have proper MMU protections in place, which lets an attacker write to RAM it shouldn’t be allowed to by doing it through the GPU instead of the CPU?
GPUs doing DMA is a problem whether you have unified memory or not. This is why IOMMU exists.
3 replies →
That thread is a more interesting read than the blog post.
> $150k bounty
That’s one heck of a way to fund Asahi
Recent XNU in the KDK also have code to do injection of AMCC errors, ECC errors, and DCS errors for testing purposes.
I bet someone figured you could do the same for the GPU.
[flagged]
The authors' Chaos Communications Congress conference talk about these exploits is up now, it was a great watch:
- https://news.ycombinator.com/item?id=38783112
Thanks! Macroexpanded:
4-year campaign backdoored iPhones using advanced exploit - https://news.ycombinator.com/item?id=36151220 - June 2023 (31 comments)
Others?
Older posts from the initial announcements:
- https://news.ycombinator.com/item?id=36151220
1 reply →
> This is no ordinary vulnerability. Due to the closed nature of the iOS ecosystem, the discovery process was both challenging and time-consuming
Which, ironically, is evidence that "security through obscurity" does work, even though the authors implicitly criticize it in the same post.
Unfortunately, they only thing they obscured was the fix from the victim, it in no way obscured the attack from the attacker. So, yea, it "worked."
It's literally broken! It didn't work. The complaint is that the path from discovery of the hole to working exploit is longer. And... that's probably true. But that's optimizing the wrong side of the equation. An open system would have surfaced this bug long ago, possibly years ago (it's not clear how old this mistake is, but the claim seems to cover multiple Apple SOCs), and the vulnerable systems would have been limited to one version of the hardware that could feasibly have been replaced via warranty coverage or whatever. Now we're all stuck trying to patch around a fundamental hole in tens (hundreds?) of millions of phones.
> An open system would have surfaced this bug long ago, possibly years ago (it's not clear how old this mistake is, but the claim seems to cover multiple Apple SOCs), and the vulnerable systems would have been limited to one version of the hardware that could feasibly have been replaced via warranty coverage or whatever.
How long did it take for Spectre and Meltdown to be discovered? Some vulnerabilities are easy to spot in an open design, but the more novel the exploit, the longer the vulnerability can hide in plain sight.
1 reply →
Once it's sufficiently obscure, we call it a "private key." They're like hipster prime numbers.
Obscurity can add some cost but has no real properties of strength.
I see this very often where encryption experts and FOSS advocates pooh-pooh obfuscation and opaqueness. "It's not REAL security", they say. And they are right.
This is like those Chinese outfits that laser off the part markings on ICs so others can't copy the design as easily. Eventually someone will find out what part number it is and the mitigation will be nullified. But it IS effective for a period.
In the same way obscurity provides a time bonus that must be worked through before exploitation can begin.
Hackers tend to complain very much about this obscurity stuff "all it does is waste people's time and it's not secure" which is exactly the point. Surely by now researchers must have realized that creating a 100 percent bulletproof security implementation is very unlikely when compared to how impenetrable any modern encryption system is, due to gotchas and flaws in the implementation details. And this is why obscurity slows down the discovery.
Denuvo DRM for new games is the same way. It is very hated but does work very well for the publisher at mitigating piracy for the initial 2-3weeks after a game launches where the bulk of sales happen.
DRM isn't a relevant comparison because there the explicit intention is to prevent users from accessing data they've already been given. Everyone knows this is not possible in a strong sense, time-wasting through obfuscation is the best DRM can hope for.
The other reason obfuscation makes sense for DRM is the threat actors are individual consumers, who have limited time and resources to devote to untangling the obfuscation, and limited reward for doing so.
Normally we might expect to see many such users combining their resources to fund a solution to their problem at scale (by founding a public business or foundation for de-obfuscating DRM), but the state has made doing this punishable by prison. So DRM is rendered effective not so much through good engineering but through the legal system. This is an adequate solution for companies when the threat actors are simple civilians who want to play video games.
except in this case, the attackers figured it out ages ago and everyone else was left in the dark.
The issue with obscurity is that attackers inherintly have a far higher incentive to try and understand obfuscated, undocumented messes than security researchers.
They're talking about the analysis and understanding of the malware
ELI5 por favor, is this a class of exploits that is a function of Apple's architecture, kind of like how specter was for the whole branch prediction thing IIRC? Or is this something that can be fixed with a software update and no performance impact.
From what I understand, there was an unused hardware register not used by the OS that was the entry way for this attack. It’s been patched with no performance impact and there was an earlier HN submission with more details. It took advantage of 4 or 5 bugs that have been patched. Warning, this has been SCREAMING state actor vs state actor
No, it's at best a strange debugging feature left accessible by mistake
Fixed by blocking access to its registers, if I'm not mistaken, without performance impacts.
This is no normal vulnerability. Nation state insider?
Nation state backdoor?
From the accompanying article:
> Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake.
This screams backdoor by some powerful actors.
This appears to be used to direct write cache for testing purposes. It's not an intentional backdoor.
It's more likely an insider leak of some private headers or something that gave someone the info necessary. Or Apple left too much stuff in the debug info.
It would not be the first time either has happened.
5 replies →
Remember when someone discovering a powerful vulnerability meant that the community could find a solution and maybe even create a patch for everyone else?
Feels like that reality was far more secure than the current closed-source siloed one.
ELI5/OOL: impact?
Zero-click RCE
I absolutely love how this response is "explain this like I am five years old" and "I am out of the loop" -- the people who grew up with BAUD as a nomenclature are going to die.
Here is a poem by AI:
HOLY FUCK:
https://i.imgur.com/V8HtW03.png
---
In the days of BAUD, we danced with time, Bits twirled and pirouetted, a rhythmic mime. Modems hummed, a song of distant lands, A symphony of data in unseen hands.
But now, oh now, we've left those days behind, Bandwidth's embrace, a treasure we find. No more the worries of a BAUDish plight, In the realm of speed, we soar with delight.
Gone are the struggles, the slow and the strained, Streaming through fibers, our data unchained. A digital ballet, swift and so grand, In the era of bandwidth, we boldly stand.
No longer confined to a BAUDish dream, The internet whispers, a seamless stream. Pixels paint pictures, words swiftly fly, In the limitless expanse of the bandwidth sky.
So here's to the days of BAUD, now a tale, A vintage echo in a high-speed gale. We've moved beyond, to a faster shore, In the bandwidth symphony, we dance evermore.
--
Just wow
iMessage. It's always iMessage.
2 replies →