Everything has changed in iOS 14, but Jailbreak is eternal [pdf] | Hacker News Reader

Everything has changed in iOS 14, but Jailbreak is eternal [pdf]

i.blackhat.com

191 pointsclubdorothe64 comments

Here’s a thing about jailbreaking.

As a user I like my device being safe from outside attackers (NSO & co).

But I definitely do not want my device to be protected against me. It’s absurd that I have to use the methods of an attacker to gain modification privileges on a device I own.

That's why Apple needs to unclench and give up its need for absolute control and just allow bootloader unlocking. Users who modify will always want to be able to modify and the only way to have that and have security as well is to allow specific ways for it to be done... not to force modders to rely on exploits.

Unfortunately, it's now vital to child safety that iPhone users never be allowed to jailbreak their phones. Apple's recently-announced CSAM photo detection feature relies on Apple being sure that the real NeuralHash machine-learning model, not a fake that produces random data indistinguishable from a non-matching photo, is running on everyone's devices.

So I'd say the odds of them loosening their grip here are pretty slim.

Details on that technology https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni...

The EU is pretty resistant to Apple bullcrap. They will order Apple to switch to server-side scanning on unlocked devices.

The client will just never send the images, if someone writing it doesn't wants that.

Great write up and very well presented. All in all a bit disturbing but that's what you should get from Blackhat.

"Started macOS/iOS security from the second half of 2019"[!]

What’s disturbing about it? I didn’t understand the slides or the implications thereof well enough to actually figure that out.

A bright lad with a few years experience finds a way around the mitigations for a flaw found in the previous version. Bear in mind Apple is a $T1 organisation and he ... isn't.

Not only does he perform a rather well polished dance but he writes it up in an entertaining and well presented way. I suspect english is a second language too which makes the whole thing even more impressive.

Just to reiterate: he waltzes around a key aspect of the security in iOS 14 - that is disturbing to me. If he can do that, what do you think a well funded nation state bunch of noddies gets up to?

> A bright lad with a few years experience

A few years experience specifically working with iOS. That doesn't say anything about how much existing experience he has in the security space.

Here's a Java critical patch update from 2017 that references someone of the same name (probably him):

https://www.oracle.com/security-alerts/cpujul2017.html

When I was his age, I had trouble finding my arse with both hands. He manages an attractive presentation of a pretty dry subject in a foreign language and presents it to an all star audience.

I suspect he'll do all right.

By the way, iOS devices also run a completely different OS on the secure enclave: https://sel4.systems/About/seL4-whitepaper.pdf

The SEL4 kernel is different because it has actually been "proved correct" and "proved secure" according to the authors.

The Secure Enclave runs a custom L4 derivative, rather than seL4.

ObKnuth:

> Beware of bugs in the above code; I have only proved it correct, not tried it.

Layperson here: what does that mean?

It’s a joke. https://en.m.wikipedia.org/wiki/Formal_verification

It's a comment from a correspondence between Donald E. Knuth and Peter van Emde Boas (meant as a joke I think).

You can find it in this pdf at the end of the 7th page : https://staff.fnwi.uva.nl/p.vanemdeboas/knuthnote.pdf

Knuth mentions it in his FAQ (at the end) : https://www-cs-faculty.stanford.edu/~knuth/faq.html

I got that part. The part I don't understand is this: what does it mean for a program to be proven correct but still not work?

It means that the correctness properties that were formally proved are not necessarily what you would intuitively understand as "correct". E.g. you can formally prove that a buggy factorial(n) always outputs (n - 1)! by incorrectly defining what you want to prove. The function behaves according to what you proved, it's just not the expected behaviour.

More pointily: "correct" is not a formal property of a program, so you can't actually prove it in the first place. Rather you have proved some actual formal properties of the program (eg, always terminates, does not branch dependent on cryptographic secret data, etc[0]), which may, or may not, have any relevance to it's actual intended behviour.

0: Strictly speaking, even those are only English-language descriptions of formal properties, and you still need to worry about whether the formalization actually means what you think it means.

It's a joke. You'd expect that a proof of correctness to be the Holy Grail. Nothing could be wrong, since it's proved correct. And yet, after running it, you could still find a bug in it, because you may have made a mistake in your proof.

In addition to the sibling answers, one could have verified an algorithm mathematically, but made a typo in the code.

To the other comments here I have to add - proofs (in math, science, computer science, any subject area..) never reflect absolute reality, but rather just your view of reality or the parts of reality that you have chosen to model.

So the reality of your "proven" program will never 100% match the reality of it running on hardware or some other software context than you anticipated. Let's call this the Hacker's Postulate...

As for math specifically I think this is a very deep and interesting philosophical tangent to go down.

How does this compare to security features of Android. Any good references.

for those looking for a TLDR:

- Result: run unauthorized code on iOS 14

- 14 is the most secure toy phone OS to date, with kernel heap hardening, data PAC, userspace PAC hardening, tfp0 hardening, ipc_kmsg hardening

- Exploit took advantage of multiple bugs, concentrating on PAC (Pointer Authentication Code, cryptographic signature on the pointer value, designed to resist memory disclosure attacks, for more context see [1])

- Multiple steps and dependencies, chaining vulnerabilities and exploits

- Code on https://github.com/pattern-f

I really commend Zuozhi Fan (@pattern_F_)for publishing the code with the report.

Additional resources:

[1] https://googleprojectzero.blogspot.com/2019/02/examining-poi...

Sounds like a lot of work and effort involved.

Yes. There are graphics in the presentation towards the end giving an overview. I'm impressed with how much knowledge the researcher acquired in a relatively short time.

Good summary.

As the owner of my device though, I would say the result is that it lets me run authorized code because I am the authority, not Apple.

By jailbreaking, I am asserting my legal authority as the owner.

But that's not the phone's defaults. Anything not approved by the monopoly is unauthorized, making the initial statement correct and the phone a toy from general computing criteria.

The fact that Apple clearly cares a lot about software security from at least two angles--both securing the device for the user from external attackers (I know they truly care about this, even though they frankly seem to focus only on users in the west and have been known to throw people from the east under the bus without a fight: see their attempt to downplay Google Project Zero's critical discoveries a few years ago) as well as (sadly, but critically, as it establishes increased direct incentives) securing the software running on the device written by themselves and other content providers from the ostensible "owner" of the hardware (whether for digital rights management or anti-competitive purposes)--and has a centralized dedicated team that can learn from experience (to avoid making the same mistakes over and over across different releases, which was the norm at companies like Samsung for a long time) made up of incredibly smart people (including mercenary turncoats from the jailbreak community who either cared more about working on fun problems than fighting for the user or simply needed the cash so much the morals had to lose out) that has been staring at this problem now for well over a decade and who are on the cutting edge of deploying "mitigations" throughout both their software and hardware even if said mitigations cause multi-percent loss of performance for the user and even if it requires changes to some or all (omg) existing software AND YET--even if they have certainly made progress (the jailbreak ecosystem has been severely affected... I have given much longer talks on the status--such as the final segment of my "Hindsight can be 50/50" talk from 360|iDev a couple years ago, but the important thing to appreciate is that the time from having high-quality exploits for specifically-modern devices to when the vulnerabilities they rely on have been patched has gone from averaging months to averaging negative months as of a few years ago)--it SOMEHOW is STILL the case that people continue to find ways (even if they are highly costly to pull off and even if the resulting abilities are "limited": you really don't need much to do a denial of service or exfiltrate data... we focus a lot on what is required to build a high quality easy to use software modification stack, due to alternatives to the App Store like my Cydia, but that is "overkill" to someone merely trying to be malicious) to hack and slash through all of these defenses (even remotely!! the yearly iMessage exploit has almost become a trope) should be taken as a visceral demonstration that our industry simply seems incapable of developing secure software, and we either need an industry-wide "come to Jesus" moment whereby we reboot the entire thing with higher/safer abstractions written by fewer/smarter developers working in languages and with tools that allow us to prove the security of what we build (and no: Rust isn't enough... I give lectures at both college courses and hackathons on how real world jailbreak exploits have worked for both iOS and Android, and part of what makes it fun even for beginning developers is how many of the bugs are "conceptual"... it is absolutely true that memory safety helps, but we need to be striving for near-perfection here as the stakes are so high, and yet, somehow, we often manage to develop software that fails to provide safety for users without even a single incorrect use of memory storage primitives) which is going to require groundbreaking research that honestly might simply prove the impossibility of the task, or, maybe, we just need to give up and make sure that everyone everywhere lives in the same constant and healthy state of fear that every single computer we are surrounded by is a liability that could turn on us at any moment as those of us who "know better" do... and one day, it is going to happen: it isn't going to be a freedom fighter like Charlie Miller who figures out how to remotely disable the brakes on every Jeep Cherokee on the road simultaneously with a remote exploit--a true story that I believe every software developer should be taught in school in the same way that physicists are routinely taught about tragic historical mistakes in the handling of radioactive materials, to make sure no one casually deploys something that puts people's safety so directly tied to bugs in centralized servers--but it is going to be a "rogue nation state", "terrorist group", or, at this rate and with our luck the last few years, someone we might best describe as a "supervillain" (a movie where someone like George Hotz is the antagonist would be absolutely amazing: if anyone writes that script and needs a science advisor to help with making the technical details ridiculously accurate, hit me up) that gives civilization a serious and deadly lesson in cyber-security. :| :/ :(

Hello fellow poster! Line breaks would be lovely for comprehension's sake.

That would probably involve breaking it into multiple sentences, and I just really didn't want to today :/. I have been having to explain the same thing over and over again now for over a decade, and you just have to have fun with it sometimes, you know? I highly recommend reading this one out loud, beginning to end: I carefully optimized the cadence of it over the course of numerous read-throughs, and I am quite proud of the result. If you want a more readable version of the same thought, I probably said the same thing in a different format somewhere every single day for the past few thousand days (and it doesn't seem to matter, lol).

Splitting your thoughts using sentences and paragraphs are powerful techniques that I think you would benefit from learning.

FWIW, reading the other responses first to make sure you aren't leaving duplicate commentary is a powerful technique that I think you would benefit from learning ;P.

When will start seeing laws making it illegal to disable the scanning for hashes?

I’m all ignorance on this subject - what would making scanning illegal prevent?

Other way around.

If you root your phone and disable its ability to spy on you then that’s obviously against the desired effect. The whole point of the hash scanning is that, you, the user, cannot disable it.

Meaning there would probably be laws to force us not to tamper with that functionality.

Similar to how printer manufacturers have to look for “the yellow dots” on bank notes and refuse to print/scan.

I imagine there will be a class action suit to get it disabled on the basis that it costs me money (even if a small amount, it adds up), with no way to turn it off and it literally can do nothing good for you. In the worst case it puts you in jail for something you didn’t do and in the best case, it costs you money.

It’s about evading the forbidden images scanning, which becomes possible when you can modify the software you’re running.

If scanning works on filesystem-level, just storing images in any non-standard format would be enough, you don't need root for that. Most likely even storing images in an sqlite would make them inaccessible for those scanners. Trying to force all apps in the world to use some scanning API for their images is unrealistic. Also you can use web apps with some website hosted in a free country with canvas drawing.

They'll just use mass-bombing by targeting most popular apps and services and that's about it. It's unrealistic to expect 100% solution, because 99% solution will be good enough.

> targeting most popular apps and services

If a competing photo storage site doesn't offer the same "feature" of scanning the files you upload, might Apple decide to prevent iOS devices from accessing it? I'm sure Apple would love to claim that the anti-trust authorities don't care about the children.

There's no precedence for any browser to censor any website outside of malicious website feature. So technically you're right, Apple surely could do that, but that will be another level of fence around garden.

Or illegal to reverse engineer the scanning code, to work out how to distort the images so the hashes no longer match (or distort innocent images so that they do match, and then send them to someone else's phone).

I see many submissions from blackhat.com are direct PDF links, but that does not make me feel very comfortable.

Why?

I suspect they're concerned about the PDF format, which has been used in the past to deliver malicious payloads.

If there is concern there, use a reader without javascript or an online converter from PDF to another format.

The most famous exploits in Apple's PDF stack (notably not present in Adobe's renderers) came from bugs in freetype (a software font rendering stack also used by a lot of Linux systems), specifically in the VM (seriously: it is an interpreter for a stack machine) used to run the embedded bytecode truetype fonts use to "hint" their fit to the pixel grid.

If you are concerned about harmful files from the Internet, consider using Qubes OS.

Qubes is wonderful. I read HN and surf the web/social in a dvm - disposable vm, so if you are exploited, not only is it contained to the vm, it’s contained to the vm until you close it, at which point all changes are discarded.

(Modulo any Xen exploits that make it through and affect Qubes. no security is perfect.)

> Modulo any Xen exploits that make it through and affect Qubes

By the way, thanks to the clever Qubes design, quite few Xen exploits affect Qubes OS [0]. Especially after 4.0 with VT-d hardware virtualization [1].

[0] https://www.qubes-os.org/security/xsa/

[1] https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/#fully...

It's a conference.

The presentations get published.

Isn't this totally normal?

I mean, sure it'd be totally blackhat to publish a brand new pdf exploit this way, but blackhat as a conference went way beyond those roots a long time ago.

Thanks. I was like, “I ain’t clickin that.” But since you vouched for it…

Me too.

My guess is that my brain has subconsciously tuned out engaging pdf content because of how difficult it is to use in-browser... Especially when dealing with text sizes and zooming sigh. It's even worse with pdfs on mobile :(

Also the sudden break from "website" to "pdf" format is often jarring.

i prefer to let it download and just use a dedicated viewer, cuts down on the sluggishness as well.

Just amusing that after all these decades this is still not a solved problem. Why can’t the browser just translate the PDF into HTML and display it normally in a “virtual” webpage? Make it pdf:// or whatever.

I thought of making something like this once. Then I started to look into the PDF standards and realized it's one of those things that you're thinking, why has nobody done this? Then you start looking into it and you realize why nobody's done it. The task would be monstrously difficult if you want to cover all the things that can be in a PDF.

PDF is a beast. It's a ridiculous file format. There's a reason why even after all these years, reading PDFs still kinda sucks.

Isn't that exactly what browser PDF viewers (e.g. PDF.js [0]) already do?

[0] https://mozilla.github.io/pdf.js/

iOS solved this in like version 3 (well more specifically, safari did). For all the bitching HN does about safari at least they managed to get pdf viewing right on mobile.

On android I have to use a firefox fork called iceraven to be able to install pdf.js extension to use mozilla's own pdf.js to load pdf's in my tabs. Afaik, there's no other way to do it.

I mean, that sounds basically like what PDF.js is. It’s not static, though.

Agreed. PDFs are still considered very unsafe from unknown sources. Always be cautious. They are constantly used in phishing attacks.

All phishing attacks require you to click on a link embedded in the PDF, right?

On the one hand, you'd think anyone technologically savvy wouldn't do that.

On the other hand, accidentally clicking on links in PDF's is the bane of my existence. I constantly consume academic books and papers as PDF's on my iPad in the built-in Books app, tap somewhere with my Apple Pencil for any number of reasons (to pan, to zoom, to highlight), and bam I'm transported 100's of pages away and with no back button.

If I could ask for any PDF reader feature, it would be to improve link handling. If it's an internal link, for the love of god include a back button. And if it's an external link for a web browser, for the love of god require a confirmation dialog first. I should never be led to a malware URL because of an accidental click.

I mean, multiple jailbreaks merely required you to open the PDF: it isn't just phishing attacks that have made me wary of PDF files. (But we also have seen jailbreaks that rely only on JavaScript that can be run in the browser, so ¯\_(ツ)_/¯).

“Our users were getting exploited in our PDF viewer, so we added a stack”

Reply on news.ycombinator.com