[HN Gopher] Everything has changed in iOS 14, but Jailbreak is e...
___________________________________________________________________
Everything has changed in iOS 14, but Jailbreak is eternal [pdf]
Author : clubdorothe
Score : 164 points
Date : 2021-08-07 07:53 UTC (15 hours ago)
(HTM) web link (i.blackhat.com)
(TXT) w3m dump (i.blackhat.com)
| gerdesj wrote:
| 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"[!]
| wycy wrote:
| What's disturbing about it? I didn't understand the slides or
| the implications thereof well enough to actually figure that
| out.
| gerdesj wrote:
| 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?
| vitus wrote:
| > 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
| NotPavlovsDog wrote:
| 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...
| iJohnDoe wrote:
| Sounds like a lot of work and effort involved.
| NotPavlovsDog wrote:
| 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.
| solarkraft wrote:
| 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.
| techrat wrote:
| 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.
| fortran77 wrote:
| When will start seeing laws making it illegal to disable the
| scanning for hashes?
| lostlogin wrote:
| I'm all ignorance on this subject - what would making scanning
| illegal prevent?
| dijit wrote:
| 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.
| solarkraft wrote:
| It's about evading the forbidden images scanning, which
| becomes possible when you can modify the software you're
| running.
| vbezhenar wrote:
| 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.
| dane-pgp wrote:
| 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).
| saurik wrote:
| 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. :| :/
| :(
| pshc wrote:
| Hello fellow poster! Line breaks would be lovely for
| comprehension's sake.
| saurik wrote:
| 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).
| orf wrote:
| Splitting your thoughts using sentences and paragraphs are
| powerful techniques that I think you would benefit from
| learning.
| saurik wrote:
| 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.
| hr2016 wrote:
| I see many submissions from blackhat.com are direct PDF links,
| but that does not make me feel very comfortable.
| bradleykingz wrote:
| 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.
| asddubs wrote:
| i prefer to let it download and just use a dedicated viewer,
| cuts down on the sluggishness as well.
| seanp2k2 wrote:
| 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.
| grawprog wrote:
| 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.
| jsploit wrote:
| Isn't that exactly what browser PDF viewers (e.g. PDF.js
| [0]) already do?
|
| [0] https://mozilla.github.io/pdf.js/
| joecool1029 wrote:
| 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.
| jchw wrote:
| I mean, that sounds basically like what PDF.js is. It's
| not static, though.
| Quarrel wrote:
| 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.
| newbamboo wrote:
| Thanks. I was like, "I ain't clickin that." But since you
| vouched for it...
| iJohnDoe wrote:
| Agreed. PDFs are still considered very unsafe from unknown
| sources. Always be cautious. They are constantly used in
| phishing attacks.
| crazygringo wrote:
| 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.
| TechBro8615 wrote:
| "Our users were getting exploited in our PDF viewer, so we
| added a stack"
| saurik wrote:
| 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
| -\\_(tsu)_/-).
| quenix wrote:
| Why?
| haswell wrote:
| I suspect they're concerned about the PDF format, which has
| been used in the past to deliver malicious payloads.
| mirkules wrote:
| If there is concern there, use a reader without javascript
| or an online converter from PDF to another format.
| saurik wrote:
| 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.
| fsflover wrote:
| If you are concerned about harmful files from the Internet,
| consider using Qubes OS.
| mapgrep wrote:
| 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.)
| fsflover wrote:
| > 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...
| etaioinshrdlu wrote:
| 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.
| saagarjha wrote:
| The Secure Enclave runs a custom L4 derivative, rather than
| seL4.
| jl6 wrote:
| ObKnuth:
|
| > Beware of bugs in the above code; I have only proved it
| correct, not tried it.
| smnrchrds wrote:
| Layperson here: what does that mean?
| niea_11 wrote:
| 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
| smnrchrds wrote:
| 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?
| _hl_ wrote:
| 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.
| gregschlom wrote:
| 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.
| nitrogen wrote:
| In addition to the sibling answers, one could have
| verified an algorithm mathematically, but made a typo in
| the code.
| zja wrote:
| It's a joke.
| https://en.m.wikipedia.org/wiki/Formal_verification
| crudbug wrote:
| How does this compare to security features of Android. Any good
| references.
___________________________________________________________________
(page generated 2021-08-07 23:00 UTC)