[HN Gopher] Blasting Past WebP - An analysis of the NSO BLASTPAS...
___________________________________________________________________
Blasting Past WebP - An analysis of the NSO BLASTPASS iMessage
exploit
Author : el_duderino
Score : 210 points
Date : 2025-03-27 12:49 UTC (10 hours ago)
(HTM) web link (googleprojectzero.blogspot.com)
(TXT) w3m dump (googleprojectzero.blogspot.com)
| cedws wrote:
| It's always codecs.
|
| I don't always buy into the $safelanguage cargo cult but come on,
| it's apparent that memory unsafe languages are not appropriate
| for this purpose and desperately need replacing.
| oguz-ismail wrote:
| skill issue+no serious alternative
|
| What's the point of WebP anyway?
| adzm wrote:
| Alpha channels in a lossy image? Animated lossy image?
|
| Regardless, things like this really help explain the
| hesitation behind adopting jpegxl.
|
| I'm a big fan of AVIF files though.
| oguz-ismail wrote:
| >Alpha channels in a lossy image?
|
| Why?
|
| >Animated lossy image?
|
| It's called a video
| londons_explore wrote:
| There are loads of uses for alpha channels. Anything you
| want layered with other graphics without being surrounded
| by an ugly black square...
|
| There are loads of uses for lossy images. Pretty much any
| image is probably best transmitted lossy, because the
| saved ram, CPU, bandwidth, load time is huge compared to
| the usually unnoticeable quality degregation.
|
| So it stands to reason there are lots of uses for lossy
| alpha images.
| oguz-ismail wrote:
| >usually unnoticeable quality degregation
|
| Dunno I think it'd be too messy
| IshKebab wrote:
| Only if they implement jpegxl decoders in C/C++. I would
| _really_ hope that isn 't the case.
|
| Seems like they agree:
| https://github.com/mozilla/standards-positions/pull/1064
| dlachausse wrote:
| No serious alternative? Apple could easily make a safe image
| handling library in Swift.
| ChocolateGod wrote:
| Swift is underrated, I wish it had more traction outside
| Apples ecosystem.
|
| Easy to learn, fast and memory safe without a GC.
| cosmic_cheese wrote:
| It's very slowly starting to get a bit of traction
| outside of Apple now that the language has filled many
| gaps and Foundation is being re-written to be Swift-first
| and open source. I expect growth of adoption to continue
| to be slow for the time being though.
| necubi wrote:
| Automatic reference counting is a form of GC, and
| optimized versions of it end up very similar to tracing
| GC: https://web.eecs.umich.edu/~weimerw/2012-4610/reading
| /bacon-...
|
| (except that ARC can't handle cyclic graphs)
| IshKebab wrote:
| And it's more deterministic without random pauses.
| pebal wrote:
| The reference counting also causes pauses when freeing
| large object graphs. Fully concurrent GC does not cause
| any pauses and it's more efficient. It also has less
| memory overhead per object.
| actionfromafar wrote:
| https://github.com/google/wuffs <-- DSL created explicitly
| for wrangling fileformats safely
| jonatron wrote:
| Thank you, I spent a few minutes failing to google this.
| actionfromafar wrote:
| I always do that, sometimes I succeed, sometimes I fail!
| :-D
| internetter wrote:
| Written in C? Unless I'm missing something this isn't
| better than other unsafe options
| codetrotter wrote:
| From the Wuffs readme:
|
| > Wuffs the Language is safe with respect to buffer
| overflows, integer arithmetic overflows and null pointer
| dereferences. A key difference between Wuffs and other
| memory-safe languages is that all such checks are done at
| compile time, not at run time. If it compiles, it is
| safe, with respect to those three bug classes.
|
| > [...]
|
| > Wuffs code is hermetic and can only compute (e.g.
| convert "compressed bytes" to "decompressed bytes"). It
| cannot make any syscalls (e.g. it has no ambient
| authority to read your files), implying that it cannot
| allocate or free memory (and is therefore trivially safe
| against things like memory leaks, use-after-frees and
| double-frees).
| yjftsjthsd-h wrote:
| And -
| https://github.com/google/wuffs/blob/main/doc/std/image-
| deco... _with a webp implementation_.
| tedunangst wrote:
| From after this exploit was found.
| yjftsjthsd-h wrote:
| Oh, you're right; I managed to miss that the vuln was
| from 2023. I do wonder how widely used the wuffs version
| is now that it exists, though.
| tedunangst wrote:
| wuffs has the same story as rlbox in firefox. They made
| the tool, they proved it could work with one library, and
| then proceeded to ignore it for all the other libraries.
|
| https://hacks.mozilla.org/2020/02/securing-firefox-with-
| weba...
| nxobject wrote:
| I wouldn't be surprised if some security team at Apple was
| cooking up a bespoke DSL as well - NIH seems to happen once
| in a while.
| pcwalton wrote:
| They have some kind of safe dialect of C that they use
| for iBoot. Also they're increasingly using Swift for
| things.
| greenavocado wrote:
| JPEG-XL is the future everything else is forced/shilled to
| the extreme without considering its merits. Don't even get me
| started how some website will show a URL to a JPEG and when
| you try to save it, it tries to save a WebP.
|
| WebP suffers from excessive generation loss for a modern
| codec.
|
| https://www.youtube.com/watch?v=qc2DvJpXh-A
| dev1ycan wrote:
| Yeah but Google goes out of their way to kill jpeg-xl, they
| really deserve to lose chrome
| latexr wrote:
| I find it curious how the AVIF deterioration resembles an
| old physical photograph. I wonder why that is. Do you know
| of more comparisons like this? I'd like to observe the
| effect further but don't have the availability right now to
| pursue it.
| derf_ wrote:
| It looks like a straight-up bug in chroma quantization.
| libaom has never had good chroma RDO tuning.
| jeroenhd wrote:
| JPEG-XL works in even fewer programs than WebP does,
| though, which is almost impressive given WebP's reputation.
| voidUpdate wrote:
| Good compression for web images. I converted the images on my
| website to webp and saw a huge reduction in filesizes with
| virtually no loss in quality, but it still keeps an alpha
| channel unlike jpg
| oguz-ismail wrote:
| >Good compression for web images
|
| Storage is cheap, bandwidth is cheap, so who cares?
|
| >alpha channel
|
| Share an example from your website. I really want to see
| what it looks like
| voidUpdate wrote:
| Depending on where you are and what mobile data plan you
| have, bandwidth is not always cheap. And I don't see the
| problem in trying to reduce the amount of data sent,
| which is one of the reasons I don't fill my website with
| megabytes of javascript libraries
| yjftsjthsd-h wrote:
| > Storage is cheap, bandwidth is cheap, so who cares?
|
| That may be true sometimes, but it isn't true all the
| time. Even if it's "cheap", smaller files load faster.
| web007 wrote:
| > Storage is cheap, bandwidth is cheap, so who cares?
|
| This is a ridiculous assertion.
|
| They're both cheap in the commercial sense, but neither
| cheap nor infinite in the UX sense. Time and space matter
| in the real world.
|
| Google wouldn't have created WebP if there was no
| tangible, measurable cost benefit to using it over some
| alternative. Same goes for H.264 or HEVC or AV1, at scale
| bandwidth and storage are far from cheap. See the article
| on the FP today about Google's double-digit EXAbyte
| storage clusters with 50TB/s read volume each as a real-
| world example, there's nothing cheap about that.
| 01HNNWZ0MV43FF wrote:
| Well the principle reason to use Rust is that it has good
| tagged unions
|
| But I don't even buy into the cargo cult cargo cult
| https://www.righto.com/2025/01/its-time-to-abandon-cargo-cul...
| junto wrote:
| There always been an issue here with files reporting to be one
| thing but being another.
|
| Trusting the file extension is amateur to say the least.
|
| 'Magic strings' in the header of the file is the usual way, but
| even then, you can't really trust it.
|
| What we really need is some way to guarantee that the contents
| are in a valid format as defined by the header, and haven't
| been tampered with and signed as such, and embeds that in the
| file itself. Then I can take the contents of the file after the
| header, hash it and compare it with the embedded sig.
|
| Back porting this to standard formats though would be a
| nightmare.
| klabb3 wrote:
| So an attacker should sign their malicious webp or jpeg files
| beforehand? That doesn't help at all.
|
| No, I agree very much with parent here. I think compile time
| safety and rust fanatism has been oversold, _but_ let's face
| it _this_ is the perfect use case, a match made in heaven.
|
| Decoding in C/C++ has a Dunning Kruger deceitful appeal.
| People think they can do it, but time and time again, we find
| critical holes, even when written by 10x wizard Nobel
| laureate engineers.
|
| At the same time, decoding needs to be crazy performant. So,
| this is the moment to shine for languages like Rust. I am
| 100% in support of this.
| TheDong wrote:
| It feels so ridiculous to me that a total stranger can send an
| iMessage message to me, including some attachment, and my phone
| will process that message in the kernel.
|
| How hard would it be for apple to have a setting of "Only receive
| messages from mutual contacts", and require the stranger to first
| "request to be added to contacts" (a message which is tightly
| controlled, and obviously doesn't include a pdf file or webp or
| whatever), and have the apple imessage server drop all other
| messages from them until I accept.
|
| Signal has "message requests". iMessage doesn't have "message
| requests", and receives messages in a unique path which goes
| through the kernel.
|
| Like, sure the attacker could hit my Mom with a wrench and
| iMessage me a PDF exploit that way, but I feel like requiring
| physical access to one of my contact's phones raises the bar
| significantly over the current state of affairs.
| yjftsjthsd-h wrote:
| I wonder if "Filter messages from unknown senders" (
| https://support.apple.com/guide/iphone/block-filter-and-repo...
| ) skips any processing.
|
| Also, I really thought there was an option to somehow restrict
| media in messages, but I can't seem to find docs for that.
| TheDong wrote:
| I'd feel much safer if the message was filtered at the
| server, not on my device.
|
| It's not clear how much or little of the message is
| processed, but it's clear attacker controlled data lands on
| my device.
|
| > an option to somehow restrict media in messages
|
| "LockdownMode", which removes attachments, but also turns off
| JIT in your browser, and removes the ability to install
| configuration profiles, among other things.
|
| For some reason apple has a security setting that restricts
| iMessage media, but to opt into that, you also have to make
| your web browser useless and have GPS stripped from your
| photos, idk, apparently "enable" toggles are expensive and
| they could only afford a single one for like 10 unrelated
| security features.
| larfus wrote:
| If Apple advertised a toggle that protects you completely
| but let the users decide the mitigations, it would severely
| damage its standing as a secure phone when it would
| inevitability get exploited. (Targeted) Apple users are
| usually not technical.
| madeofpalk wrote:
| _About Lockdown Mode_ https://support.apple.com/en-
| gb/105120
|
| _Harden your iPhone from a cyberattack with Lockdown
| Mode_ https://support.apple.com/en-
| gb/guide/iphone/iph049680987/io...
| TheDong wrote:
| You're saying that having "enable full lockdown mode",
| but _also_ having a toggle in iMessage settings for
| "Disable automatic display of media attachments" would be
| less secure?
|
| The poster two above me couldn't find the setting because
| they looked in iMessage settings for an iMessage security
| feature, not for lockdown.
|
| And I would turn on the imessage security feature in a
| heartbeat if it didn't break my browser, and a custom
| font I have to install via a configuration profile.
|
| I feel like these are both good counter examples to
| "adding options obviously means people won't use it"
| toast0 wrote:
| If the message is filtered at the server, it adds a lot of
| requirements you might not actually want:
|
| 1) the server needs to have your contact list, in a form
| where it can query if user X is in user Y's contacts, in
| order to do filtering.
|
| 1a) If you really meant mutual contacts, the server needs
| to process contact lists from both parties together. If you
| are ok with getting a media message from someone who
| doesn't have you in their contacts but you have them in
| yours, this one is skipped.
|
| 1b) The server needs to know who the message is from and
| who it is to at the same time.
|
| 2) If you're ok with a text message, but not a media
| message, the server needs to know the difference between
| text and media messages.
|
| 3) I'm not familiar with the details of iMessage, but often
| messengers use a pattern where a media message is really a
| link to a media file on some blob server, optionally with
| some text. If you want the server to remove the link to the
| file, but allow the text, the server would need to be able
| to see and process that.
|
| Again, I'm not familiar with how iMessage operates, and
| some of these may already be aspects of the service, but
| they're not strict requirements of a messenger service, and
| the less the server knows about messages and contacts, etc,
| the more privacy users have from the service.
| instagib wrote:
| I have been running lockdown mode for a while now and it
| can be painful for shopping but usable. You can disable it
| on a per site basis in Safari. Stolen device protection
| mode on also.
|
| To do it and enable side loading you need to do two resets
| to enable developer mode. I am able to enable a
| configuration profile also without a problem. It was
| installed and enabled pre-lockdown and re-enabled in
| lockdown mode. I just enabled location services for camera
| and it correctly gps tagged my photo.
|
| The only pain points I have are if someone texts me
| something other than a picture which is a lockdown feature.
| For some reason usps tracking webpage fails on all browsers
| except on Firefox/Firefox focus browser. A few heavily
| tracked apps or shopping websites don't like it but
| tolerate it. Pain: You cannot search your iMessages. I can
| turn lockdown off on a per app basis excluding iMessage
| also but have not needed to.
| aeontech wrote:
| I believe enabling lockdown mode disables media previews in
| messages to prevent exactly these kinds of attacks, among
| other mitigations.
| kevin_thibedeau wrote:
| That doesn't solve the core problem that untrusted data from an
| external source can compromise the system. Any person in your
| contacts can suffer from an exploit that lets an attacker
| target you. You don't want data from them to be whitelisted.
| TheDong wrote:
| I want to respond to the strongest interpretation of your
| comment, but no matter how I read it, all I'm getting is
| "defense in depth is meaningless".
|
| Do you also think apple shouldn't have bothered building
| blastdoor sandboxing, since all the code running in the
| sandbox should just be flawless code with no security issues
| anyway? Is ASLR not worth it since the core problem is that
| there are memory safety bugs, and so we should instead just
| write it all in rust and not do ASLR or such?
|
| I'm not saying we shouldn't fix security issues, just
| suggesting a defense in depth mechanism that in practice
| seems like it'd make most people a lot safer.
| kevin_thibedeau wrote:
| This is all a fuckup by the responsible vendor Apple who
| isn't comprehensively using commercial static analyzers
| that can easily detect this sort of buffer overflow. They
| both have billions in cash to pay for dedicated engineering
| teams to do this work.
| CharlesW wrote:
| Are you saying it's bad that Apple's using an open source
| solution, or that Clang Static Analyzer (built into
| Xcode) is bad specifically?
| https://www.youtube.com/watch?v=jajgCfkLNdk
| galad87 wrote:
| But the initial security issue was in libwebp, which is
| made by Google, and surely Google had already fuzzed it
| and run all the available static analyzers in the world.
|
| Static analyzers are nice to have, but they can't warn of
| every issue out there.
| astrange wrote:
| The initial security design failure was inventing
| lossless WebP, which is a completely different format
| from lossy WebP, which means the library has double the
| code for double the attack surface.
|
| I am skeptical inventing any kind of WebP was a good
| idea, but I know the inventor and he got mad at me last
| time I said that, so I won't.
| yapyap wrote:
| I mean yeah but the real problem is ACE through iMessage
| nneonneo wrote:
| It's not being processed in the kernel - BlastDoor is a
| heavily-sandboxed user process. This attack chains together a
| bunch of exploits - including an _encrypted BlastDoor sandbox
| bypass_ - in order to gain full control over a device.
| JoshTriplett wrote:
| And this is one of many reasons why analyses like this
| provide so much value. It's fascinating that the actual
| sandbox bypass in this case is so carefully protected. If
| that sandbox bypass code could be decrypted and reverse-
| engineered, it could point to the actual vulnerability being
| exploited, which could then be fixed.
| tialaramex wrote:
| I can already guess without looking that the sandbox is
| excellent except that oops there's a few edge cases that
| were MUST FIX, so, we had to cut a small hole in it. The
| people who understand how difficult this is to do properly
| built the actual sandbox which will be fine, the ragged
| hole cut in it (and exploited) was implemented by somebody
| for whom the sandbox is just another annoying thing they
| need to work around to get their job done and they don't
| care that they made it worthless.
| chatmasta wrote:
| I'm sure they care that they spent all that time working
| around an annoying thing -- they don't want to waste time
| finding a new workaround when this one is patched. And
| they'd like to re-use it in other exploit chains, so why
| not obfuscate it to the best of their ability?
|
| You do highlight an important difference between the
| mindset of an attacker and a defender. The attacker only
| needs to be right once, and then they can move onto the
| next phase of the attack. That's why they don't bother
| "understanding it properly" beyond the perspective of
| attacking it. A medieval siege unit understands the weak
| points of castle walls, and how to operate a catapult,
| but they don't care about the intricacies of stone
| masonry beyond what's necessary for knocking down a wall.
| gus_massa wrote:
| Here in Argentina it's somewhat common to recibe social
| engineering attacks to steal the WhatsApp account. When they
| success, they send money request to all the contacts [1]. So
| once you add your Mom, they only need to convince her to give
| them access to her account, not the physical device.
|
| [1] I got one 2 weeks ago. More details in
| https://news.ycombinator.com/item?id=43361556
| conradev wrote:
| A total stranger can send radio waves at you and your phone
| will process them on a processor close to the kernel:
| https://googleprojectzero.blogspot.com/2017/09/over-air-vol-...
| ls612 wrote:
| I'm pretty sure that the modem on modern iPhones can only
| access a small memory address range and that this is
| cryptographically enforced by the Secure Enclave. So an
| exploit in modemland doesn't allow reading unencrypted info
| (since everything today is encrypted at the application
| level).
|
| I'll see if I can find the citation in the Platform Security
| document when I get home.
| bri3d wrote:
| I don't think there's anything cryptographic about the
| baseband communication on an iPhone, or that they're
| connected through the Secure Enclave. I think they're just
| PCIe endpoints with IOMMU (which is fine as long as the
| IOMMU is configured correctly). My understanding is that
| for most iPhones, a repair shop can replace the baseband
| hardware itself without the phone noticing, which also
| suggests that there's no pairing or hardware trust model /
| key exchange between the AP and baseband.
|
| Post-boot communication with the host processor on
| Qualcomm-baseband iPhones (iPhone 12-16 non-E) is the usual
| Qualcomm QMI/QMUX over PCIe (CommCenter uses
| libPCITransport to send messages).
|
| The Platform Security document just says "On devices with
| cellular access, a cellular baseband subsystem performs
| additional secure booting using signed software and keys
| verified by the baseband processor" and "Each network
| processor is on its own isolated PCIe bus. An Input/ Output
| Memory Management Unit (IOMMU) on each PCIe bus further
| limits the network processor's DMA access to only memory
| and resources containing its network packets and control
| structures."
| conradev wrote:
| The Secure Enclave is nowhere between the AP and the
| Broadcom chip.
|
| The application processor has an IOMMU and the kernel uses
| it to restrict what the Broadcom chip has access to, and
| the linked article series discusses exploiting the IOMMU.
| There is more detail in the Project Zero write-up than
| Apple's own PDF.
|
| The actual solution here is to remove the insecure Broadcom
| chip entirely, which is what Apple ultimately did. PCI-e
| and MMIO are quite risky, but ultimately necessary for
| performance. I think PinePhone series talks to their
| Broadcom chip over USB, which is a lot more secure, but the
| performance is worse.
| bri3d wrote:
| Qualcomm, not Broadcom, and the linked article series
| doesn't discuss the IOMMU at all - it's not related to
| this exploit as far as anybody knows.
|
| Maybe you're thinking of the "Operation Triangulation"
| exploit chain, which used write access to a bizarre
| mapped area that seems to relate to cache debugging, in
| order to patch the page table.
| conradev wrote:
| No, it should be there. From the link:
|
| > Lastly, in the final blog post we'll explore the
| iPhone's host isolation mechanisms, research the ways in
| which the Wi-Fi chip interacts with the host, and develop
| a fully-fledged exploit allowing attackers to gain
| complete control over the iOS kernel over-the-air,
| requiring no user interaction.
|
| Which is referring to this link:
| https://googleprojectzero.blogspot.com/2017/10/over-air-
| vol-...
|
| That link is the one I am summarizing:
|
| > Sufficient isolation for DMA-capable components can be
| achieved by partitioning the visible memory space
| available to the peripheral using a dedicated hardware
| component - an I/O Memory Management Unit (IOMMU).
|
| Apple uses Qualcomm chips for cellular modems, and they
| use Broadcom for Wi-Fi.
|
| edit: I might have linked the original post incorrectly,
| there are many volumes and parts
| Scramblejams wrote:
| _Signal has "message requests". iMessage doesn't have "message
| requests", and receives messages in a unique path which goes
| through the kernel._
|
| Signal's message request, notably, also shows me the
| requester's avatar image. I don't know if that hits the kernel
| but it certainly hits code that as a category has suffered lots
| of security issues over the years. Which is to say: There's
| room for improvement all over!
| jakub_g wrote:
| Semi-relatedly: How does this look like for Whatsapp and
| Telegram? Can a stranger send me an attachment? Never saw this
| happen, I always receive short messages from scammers like
| "Hello" w/o attachments, but I wonder if this is possible.
| botanical wrote:
| NSO Group are a terrorist group for hire. This 0-click, 0-day
| exploit was found targeting civil society. Any one can pay to
| target journalists, NGOs, politicians. This is why open-source is
| paramount to security, and having code out in the open.
| jsheard wrote:
| Supposedly NSOs products are classed as restricted weapons
| exports by the Israeli government, and all sales have to be
| approved by the Ministry of Defense, so they have their own
| share of the blame when it falls into the wrong hands.
| myth_drannon wrote:
| Well, people are going to be targeted anyway. It's better to
| keep a trail of who is doing what, and that's the purpose of
| all those offensive cyber startups.
|
| Do they make it easier for actors to perform those activities?
| Not sure. I was never shopping for 0-day exploits. And some
| argue it's similar to gun laws in US, if it's easier to buy
| firearms, someone is more likely to use it. I just don't buy
| this comparison.
| bri3d wrote:
| How does one of these points relate to the other in any
| capacity?
| acdha wrote:
| Your conclusion is not connected to the first. Open source
| software has had many issues over the years and reading the
| technical details in this post should make it clear that
| there's no magic solution to an adversary with this level of
| resources.
| ipython wrote:
| I'm sure nobody would think of targeting the national security
| apparatus of the USG with such an exploit to gain access to... I
| dunno, their Signal messages?
| mrguyorama wrote:
| One of the members of that group was accessing it _from Moscow_
| to meet with Putin.
|
| Our adversaries don't have to hack anything at all, they don't
| even seem to have to ask nicely. There's zero chance that Putin
| doesn't let China know anything they want about the Trump
| admin, and Putin himself seems to get to dictate our country's
| policy now.
|
| This has been the case among republicans for decades, and Mitch
| McConnell himself (and 6 others) spent the 4th of July 2018 in
| Moscow for christ's sake.
| nxobject wrote:
| Essentially relying on COTS software with likely exploit
| bounties targeting dozens of high-value targets other than the
| USG - what could go wrong?
| michaelt wrote:
| Do you think _special custom_ software, developed under
| government contract, would be any more secure?
|
| My experience with software procured by the government is
| that it's not winning any awards for best software.
| nxobject wrote:
| At this point, I think Apple's platform security teams have to
| seriously [edit: by default] start mitigating attachment exploits
| in ways that affect UX - _not_ rendering message previews, or
| blacklisting formats by defaults. Given Apple's pro-privacy
| messaging - and acceptance of things like Signal auto delete -
| think Apple's user base might now be comfortable with taking hits
| to UX in the name of security.
| snailmailman wrote:
| Lockdown mode does this. Preventing weird attachment types
| entirely. Preventing most of the "edge case" things. Like you
| also can't be added to an icloud album, or install new
| configuration profiles.
|
| Although it's a bit extreme. It disables almost all web-fonts
| which breaks a lot of websites. (It's easy to toggle this, but
| you have to do so per-site) It's really not designed for the
| average user.
| jeroenhd wrote:
| I think lockdown mode is fine for most people. Yes, some
| websites are broken because they assume their font always
| loads, but I've never really felt bothered by issues like
| that. Then again, I've never really used iCloud, so maybe I'm
| missing out on something there.
|
| Many edge cases covered, like not being able to add
| configuration profile, are fixes to insecure defaults IMO.
| nneonneo wrote:
| This exploit is just wild. There are just so many little tricks
| connected together - using multiple image files with unexpected
| formats, aligning heap chunks to sit on easily-predicted and
| manipulable addresses, deserializing a huge object graph from
| image metadata, the usual NSExpression insanity, PAC bypass via
| unsigned pointers to function-pointer-containing structures, etc.
| etc. I thought the last exploit (where they built an entire
| virtual CPU out of image decompression commands:
| https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...)
| was crazy, but that involved a lot fewer "tricks" than this
| exploit.
|
| Many of these tricks are non-public, meaning that NSO would have
| had to spend a huge amount of time and effort researching every
| single one of these. They probably have many more tricks they
| know about and haven't used. And, Apple could patch every one of
| them in a future update and roll back all of that work.
|
| There's a good reason why these exploits are expensive and only
| sent to a limited number of high-value targets. NSO this time
| around also worked to "protect their IP" using encryption to hide
| part of their exploit chain, presumably in a bid to avoid losing
| yet more of their precious zero-days to researchers.
|
| What they're doing is pretty gross (particularly the whole
| spying-on-journalists bit), but you have to admit the level of
| technological sophistication and persistence here is pretty
| impressive.
| danilonc wrote:
| Would Lockdown Mode mitigate any part of this exploit chain?
|
| If so, which aspects would it block? The Apple support page
| mentions that most message attachment types are blocked, *except*
| for certain images, videos, and audio. Given this, would Lockdown
| Mode have prevented this exploit?
|
| https://support.apple.com/en-us/105120
| bawolff wrote:
| > The closest thing to a specification for the PKPass format
| appears to be the Wallet Developer Guide, and whilst it doesn't
| explicitly state that the .png files should actually be Portable
| Network Graphics images, that's presumably the intention.
|
| Lol, that got a chuckle out of me.
|
| Amazing write up by google project zero as always.
___________________________________________________________________
(page generated 2025-03-27 23:00 UTC)