This is the equivalent of a negative research result that looked into whether there's anything more to explore here to produce the really juicy result like a true compromise, but instead shows that there's nothing that a set of highly qualified researchers can prove, at least. I applaud more of this, although it is not an infrequent practice among the top security engineers, I feel it sets a precedent for research broadly.
Nothing to be found here as far as we know, is still a result that deserves publishing. Let's make it more of the norm.
Having been in this silly industry of hacking for 20yrs, I really wish publishing negative results became more normalized. There are orders of magnitude more unpublished info regarding stories of not finding vulns there are about finding vulns. It just goes to show how much the industry really is flashy/stunt hacking.
p.s. Samuel who published the research OP posted is one of the best hackers I've ever met, he helped me code our interview challenge test that we still use (it's that good!)
Security researchers sometime publish informative blog posts from time to time that don't deal with a specific vulnerability; this is one of them. Of course, being Project Zero usually these deep dives often turn up a bug or two (for example, this document on Apple's PAC implementation, which is probably one of the best resources describing it, stumbles upon a bug fixed by Apple while it was being written: https://googleprojectzero.blogspot.com/2019/02/examining-poi...), but this case it does seem like they just happened to not find anything. Whether that is because they couldn't probe very deeply due to the complete rewrite, or because the new architecture and use of a memory safe language upped the bar a bit (or a combination of both) is not clear but the thing I wanted to say here is that these blog posts are useful regardless of whether there is an exploit PoC attached. People may not want to write them, but they certainly stand on their own as good reference material.
I suspect that they wanted to use conditional expressions
or something without having to use a "real" programming language with loops or I/O, which risks freezing the interpreter and leaking data.
Interesting! Is it actually a dialect of Scheme or just a LISP syntax custom language? s-expressions are a fairly nice way to create small custom rules languages or configuration languages as they are very easy to parse.
I vaguely remember that some settings / control-panel-thingy was written in Scheme on Windows. That was at least 20 years ago, though, so it’s probably gone by now.
> However, it is worth noting that while the high level control flow logic is written in Swift, some of the parsing steps still involve the existing ObjectiveC or C implementations. For example, XML is being parsed by libxml, and the NSKeyedArchiver payloads by the ObjectiveC implementation of NSKeyedUnarchiver.
> Historically, ASLR on Apple’s platforms had one architectural weakness: the shared cache region, containing most of the system libraries in a single prelinked blob, was only randomized per boot, and so would stay at the same address across all processes.
Historically ASLR on Apple’s platforms has had many weaknesses, mostly stemming from poor randomization across many different subsystems :P
What I’m also really curious to know is what the performance implications will be of isa PAC…
Even if it turns out to be a bit slower, it is the pursuit of speed at the expense of bounds checking that has brought us here, although other ill fated OSes proved that it didn't had to be that way.
There isn't a "popular" CPU architecture that is 100% PIC for all of the allowed address ranges. There are "optimizations" the compiler can choose for limited addresses "reaches". Please consider independently compiled libraries that are aggregated into something larger, specifically languages that permit subclassing and inheritance. How can they be moved within an address space?
If there is a hierarchy of address availability this means that ASLR cannot be implemented in a pure way - it must involve runtime fix-ups if the base address changes. If the length of an instruction must change because of the addressing mode, what happens? How can you do ALSR? Do you rewrite all instructions (is there space? was space allocated?) or always use the most expensive address mode?
Slap, slap, slap. I do not think you did a complete or accurate analysis.
Randomization is NOT free. Randomization either requires that the values are pre-computed before install (which means delivering and pre-computing N different versions) or it is computed it on device.
If the randomization is computed on-device how to you validate that the binary or a library has not been "substituted" - persistent malware, APT?
The "compute on device" was a feature of very old macOS versions - it was annoying and took quite a lot of resources.
"TOTAL ASLR" depends on a CPU arch if it fully endorses over all addresses position independent code and data (Q: homework for ARM, x86_64...). If the ABI allows violations of this you cannot glide / slide all code and data addresses without significant runtime costs. This will likely result in a compromise.
> In July and August 2020, government operatives used NSO Group’s Pegasus spyware to hack 36 personal phones belonging to journalists, producers, anchors, and executives at Al Jazeera. The personal phone of a journalist at London-based Al Araby TV was also hacked.
> The phones were compromised using an exploit chain that we call KISMET, which appears to involve an invisible zero-click exploit in iMessage. In July 2020, KISMET was a zero-day against at least iOS 13.5.1 and could hack Apple’s then-latest iPhone 11.
The attacker in this situation already has the ability to deny service to the recipient, except they’ve also had the ability to utilize the crashes as an ASLR oracle too. The backoff attempts to prevent this from being possible.
That caught my eye too. I guess you would need a way of reliably being able to crash the service but that seems like a relatively low bar. Presumably the impact would also depend on how much work the service does.
Well the attacker could probably DOS the victim anyway by rapidly sending crashing messages. The update just means the attacker only has to send the message every 20 minutes.
Open source aside, it would be great if any developer could do this on iOS. Unfortunately -- in contrast to macOS -- Apple keeps the XPC API on iOS private, so that it is impossible for "normal" app developers to properly sandbox the more critical and exposed parts of their application.
Only Apple can provide the described security for their messenger, but other messengers which face similar challenges (rendering untrusted content) cannot protect themselves.
I'm no admin but wanted to ask for you to refrain commenting like this, it's probably against the site's guidelines and brings nothing to the discussion.
Per the guidelines: "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."
HN upvotes what HN wants to see. Apple is one of the biggest companies in the world with products that a large majority of HN commenters use, and this blog post is in-depth technical praise / validation written by a representative from one of their biggest competitors. It feels like classic top-post material to me.
190 upvotes isn't "only". Things can be at the top with 20 upvotes if they come in fast enough, and all younger submissions that could outcompete it are at noticably lower numbers.
At some point we would expect that the world would experience a zero day worm that works its way through the entire iMessage ecosystem, because a majority of the users are all on the latest version...
[+] [-] snoshy|5 years ago|reply
Nothing to be found here as far as we know, is still a result that deserves publishing. Let's make it more of the norm.
[+] [-] IncludeSecurity|5 years ago|reply
p.s. Samuel who published the research OP posted is one of the best hackers I've ever met, he helped me code our interview challenge test that we still use (it's that good!)
[+] [-] saagarjha|5 years ago|reply
[+] [-] philshem|5 years ago|reply
https://en.wikipedia.org/wiki/Series_of_Unsurprising_Results...
https://www.cbc.ca/radio/asithappens/as-it-happens-thursday-...
discussed on HN (2019): https://news.ycombinator.com/item?id=19968679
[+] [-] ogre_codes|5 years ago|reply
I disagree, it's a fantastic, approachable disection of what Apple did to mitigate some nasty security holes. Worth the price of entry by far.
[+] [-] rat9988|5 years ago|reply
[+] [-] kccqzy|5 years ago|reply
[+] [-] 1f60c|5 years ago|reply
I suspect that they wanted to use conditional expressions or something without having to use a "real" programming language with loops or I/O, which risks freezing the interpreter and leaking data.
[+] [-] danpalmer|5 years ago|reply
[+] [-] jes|5 years ago|reply
[+] [-] pjmlp|5 years ago|reply
One of the key points.
[+] [-] saagarjha|5 years ago|reply
> However, it is worth noting that while the high level control flow logic is written in Swift, some of the parsing steps still involve the existing ObjectiveC or C implementations. For example, XML is being parsed by libxml, and the NSKeyedArchiver payloads by the ObjectiveC implementation of NSKeyedUnarchiver.
[+] [-] saagarjha|5 years ago|reply
Historically ASLR on Apple’s platforms has had many weaknesses, mostly stemming from poor randomization across many different subsystems :P
What I’m also really curious to know is what the performance implications will be of isa PAC…
[+] [-] pjmlp|5 years ago|reply
[+] [-] szc|5 years ago|reply
There isn't a "popular" CPU architecture that is 100% PIC for all of the allowed address ranges. There are "optimizations" the compiler can choose for limited addresses "reaches". Please consider independently compiled libraries that are aggregated into something larger, specifically languages that permit subclassing and inheritance. How can they be moved within an address space?
If there is a hierarchy of address availability this means that ASLR cannot be implemented in a pure way - it must involve runtime fix-ups if the base address changes. If the length of an instruction must change because of the addressing mode, what happens? How can you do ALSR? Do you rewrite all instructions (is there space? was space allocated?) or always use the most expensive address mode?
[+] [-] szc|5 years ago|reply
Randomization is NOT free. Randomization either requires that the values are pre-computed before install (which means delivering and pre-computing N different versions) or it is computed it on device.
If the randomization is computed on-device how to you validate that the binary or a library has not been "substituted" - persistent malware, APT?
The "compute on device" was a feature of very old macOS versions - it was annoying and took quite a lot of resources.
"TOTAL ASLR" depends on a CPU arch if it fully endorses over all addresses position independent code and data (Q: homework for ARM, x86_64...). If the ABI allows violations of this you cannot glide / slide all code and data addresses without significant runtime costs. This will likely result in a compromise.
[+] [-] ondrek|5 years ago|reply
> In July and August 2020, government operatives used NSO Group’s Pegasus spyware to hack 36 personal phones belonging to journalists, producers, anchors, and executives at Al Jazeera. The personal phone of a journalist at London-based Al Araby TV was also hacked.
> The phones were compromised using an exploit chain that we call KISMET, which appears to involve an invisible zero-click exploit in iMessage. In July 2020, KISMET was a zero-day against at least iOS 13.5.1 and could hack Apple’s then-latest iPhone 11.
[+] [-] nonane|5 years ago|reply
[+] [-] withinboredom|5 years ago|reply
[+] [-] saagarjha|5 years ago|reply
[+] [-] remus|5 years ago|reply
[+] [-] tedunangst|5 years ago|reply
[+] [-] Thorrez|5 years ago|reply
[+] [-] grandinj|5 years ago|reply
Now if only there was a nice open-source, cross-platform way to do this..... hint..... hint......
:-)
[+] [-] HHad3|5 years ago|reply
Only Apple can provide the described security for their messenger, but other messengers which face similar challenges (rendering untrusted content) cannot protect themselves.
[+] [-] saagarjha|5 years ago|reply
[+] [-] swiley|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] opendysphoria|5 years ago|reply
[deleted]
[+] [-] Krasnol|5 years ago|reply
[deleted]
[+] [-] piva00|5 years ago|reply
Per the guidelines: "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."
[+] [-] robin_reala|5 years ago|reply
[+] [-] detaro|5 years ago|reply
190 upvotes isn't "only". Things can be at the top with 20 upvotes if they come in fast enough, and all younger submissions that could outcompete it are at noticably lower numbers.
> ridiculous 12 comments
irrelevant for ranking.
[+] [-] eecc|5 years ago|reply
[+] [-] Krasnol|5 years ago|reply
Not bad
[+] [-] thedg|5 years ago|reply
[+] [-] mensetmanusman|5 years ago|reply
I wonder when that will happen
[+] [-] spzb|5 years ago|reply
[+] [-] ogre_codes|5 years ago|reply
Security is vastly better than it used to be and good zero day exploits are guarded jealously. Making a big worm is a quick way to expose a zero day.
The people who have access to these zero day exploits keep them tight for targeted attacks where they are less likely to be discovered.