Hacker News new | past | comments | ask | show | jobs | submit login

For the recent WebP exploit, IIRC no preview render was even required to trigger it; simply receiving the message was sufficient. The exploit was triggered by a code path in Blastdoor that headlessly rendered the malicious WebP that was embedded within a Passkit attachment.

(But I can't find a source for this atm. I remember reading it somewhere, but maybe I'm confusing it with a previous Blastdoor exploit.)




> For the recent WebP exploit, IIRC no preview render was even required to trigger it; simply receiving the message was sufficient.

It was triggered because the system shows a preview of the image by default.

Devices that had Lockdown Mode enabled no longer show preview images, so were not effected.

>Lockdown Mode is an extreme protection feature for iPhone. Its protections include safer wireless connectivity defaults, media handling, media sharing defaults, sandboxing, and network security optimizations.

https://support.apple.com/guide/iphone/use-lockdown-mode-iph...

> On September 7, 2023, Apple released emergency security updates to fix a buffer overflow vulnerability (CVE-2023-41064) impacting macOS, iOS, iPadOS, and watchOS products that was used in a zero-click exploitation chain by the NSO Group. Shortly after, on September 11, 2023, Google released an update to fix a buffer overflow vulnerability (CVE-2023-4863) in Google Chrome, which was reported by Apple’s Security Engineering and Architecture (SEAR) and Citizen Lab. Both vulnerabilities were nearly identical and listed as actively exploited, leading to confusion across the security community.

Note: Citizen Lab urges all at-risk users to enable Lockdown mode as this has been confirmed by Apple’s Security Engineering and Architecture team that Lockdown Mode blocks this particular attack.

https://arcticwolf.com/resources/blog/cve-2023-4863/


The attack was apparently via PassKit - a separate process entirely, because messages is explicitly hardened (the whole "blastdoor" (tm) thing is to deal with that). I'm not sure what the actual passkit APIs look like but in principle any app that would take an attacker provided image and send that to whatever process handles those passkit things would get the second order part of the attack. But of course some attacker trying to, for example, extract the messages from Signal or suchlike could start from code execution in the signal process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: