DNGerousLINK
A Deep Dive into #WhatsApp #0-Click #Exploits on iOS and Samsung Devices
#DNGerousLINK,
#WhatsAppExploit,
#ZeroClick,
#RCEMobile,
#CVE202555177,
#CVE202543300,
#DNGVulnerability,
#ZeroDay,
#SecurityFlaw,
#BufferOverflow,
#WhatsAppSecurity,
#iOSSecurity,
#iPhoneHacks,
#AndroidSecurity,
#SamsungKnox,
#MobileSecurity,
#SmartphoneSafety,
#AppleNews,
#SamsungSecurity,
#CyberSecurity,
#Infosec,
#ITSecurity,
#CyberSicherheit,
#HackingNews,
#DataPrivacy,
#Datenschutz,
#TechNews,
#BreakingNews,
#Tutorial,
#TechAlert,
#CyberAttack,
#OnlineSafety,
#SoftwareUpdate,
#Hacker,
39c3-1700-eng-deu-DNGerousLINK_A_Deep_Dive_into_WhatsApp_0-Click_Exploits_on_iOS_and_Samsung_Devices_webm-hd
The spyware attack targeting WhatsApp, disclosed in August as an in-the-wild exploit, garnered significant attention. By simply knowing a victim's phone number, an attacker could launch a remote, zero-interaction attack against the WhatsApp application on Apple devices, including iPhones, iPads, and Macs. Subsequent reports indicated that WhatsApp on Samsung devices was also targeted by similar exploits.
In this presentation, we will share our in-depth analysis of this attack, deconstructing the 0-click exploit chain built upon two core vulnerabilities: CVE-2025-55177 and CVE-2025-43300. We will demonstrate how attackers chained these vulnerabilities to remotely compromise WhatsApp and the underlying iOS system without any user interaction or awareness. Following our analysis, we successfully reproduced the exploit chain and constructed an effective PoC capable of simultaneously crashing the target application on iPhones, iPads, and Macs.
To deconstruct this critical and stealthy in-the-wild 0-click exploit chain, we will detail our findings in several parts:
1. WhatsApp 0-Click Attack Vector (CVE-2025-55177). We will describe the 0-click attack surface we identified within WhatsApp. We will detail the flaws in WhatsApp's message handling logic for "linked devices," which stemmed from insufficient validation, and demonstrate how an attacker could craft malicious protocol messages to trigger the vulnerable code path.
2. iOS Image Parsing Vulnerability (CVE-2025-43300). The initial exploit allows an attacker to force the target's WhatsApp to load arbitrary web content. We will then explain how the attacker leverages this by embedding a malicious DNG image within a webpage to trigger a vulnerability in the iOS image parsing library. We will analyze how the RawCamera framework handles the parsing of DNG images, and pinpoint the resulting OOB vulnerability.
3. Rebuilding the Chain: From Vulnerability to PoC. In addition, we will then walk through our process of chaining these two vulnerabilities, constructing a functional Proof-of-Concept (PoC) that can simultaneously crash the WhatsApp application on target iPhones, iPads, and Macs.
In diesem Video analysieren wir den kritischen DNGerousLINK WhatsApp Exploit.
A Deep Dive into #WhatsApp #0-Click #Exploits on iOS and Samsung Devices
#DNGerousLINK,
#WhatsAppExploit,
#ZeroClick,
#RCEMobile,
#CVE202555177,
#CVE202543300,
#DNGVulnerability,
#ZeroDay,
#SecurityFlaw,
#BufferOverflow,
#WhatsAppSecurity,
#iOSSecurity,
#iPhoneHacks,
#AndroidSecurity,
#SamsungKnox,
#MobileSecurity,
#SmartphoneSafety,
#AppleNews,
#SamsungSecurity,
#CyberSecurity,
#Infosec,
#ITSecurity,
#CyberSicherheit,
#HackingNews,
#DataPrivacy,
#Datenschutz,
#TechNews,
#BreakingNews,
#Tutorial,
#TechAlert,
#CyberAttack,
#OnlineSafety,
#SoftwareUpdate,
#Hacker,
39c3-1700-eng-deu-DNGerousLINK_A_Deep_Dive_into_WhatsApp_0-Click_Exploits_on_iOS_and_Samsung_Devices_webm-hd
The spyware attack targeting WhatsApp, disclosed in August as an in-the-wild exploit, garnered significant attention. By simply knowing a victim's phone number, an attacker could launch a remote, zero-interaction attack against the WhatsApp application on Apple devices, including iPhones, iPads, and Macs. Subsequent reports indicated that WhatsApp on Samsung devices was also targeted by similar exploits.
In this presentation, we will share our in-depth analysis of this attack, deconstructing the 0-click exploit chain built upon two core vulnerabilities: CVE-2025-55177 and CVE-2025-43300. We will demonstrate how attackers chained these vulnerabilities to remotely compromise WhatsApp and the underlying iOS system without any user interaction or awareness. Following our analysis, we successfully reproduced the exploit chain and constructed an effective PoC capable of simultaneously crashing the target application on iPhones, iPads, and Macs.
To deconstruct this critical and stealthy in-the-wild 0-click exploit chain, we will detail our findings in several parts:
1. WhatsApp 0-Click Attack Vector (CVE-2025-55177). We will describe the 0-click attack surface we identified within WhatsApp. We will detail the flaws in WhatsApp's message handling logic for "linked devices," which stemmed from insufficient validation, and demonstrate how an attacker could craft malicious protocol messages to trigger the vulnerable code path.
2. iOS Image Parsing Vulnerability (CVE-2025-43300). The initial exploit allows an attacker to force the target's WhatsApp to load arbitrary web content. We will then explain how the attacker leverages this by embedding a malicious DNG image within a webpage to trigger a vulnerability in the iOS image parsing library. We will analyze how the RawCamera framework handles the parsing of DNG images, and pinpoint the resulting OOB vulnerability.
3. Rebuilding the Chain: From Vulnerability to PoC. In addition, we will then walk through our process of chaining these two vulnerabilities, constructing a functional Proof-of-Concept (PoC) that can simultaneously crash the WhatsApp application on target iPhones, iPads, and Macs.
In diesem Video analysieren wir den kritischen DNGerousLINK WhatsApp Exploit.
Category
🤖
TechTranscript
00:00Hi everyone, I'm Li Zhongrui, and here are my colleagues Yi Zhe and Kira.
00:29We are all from DarkLevy, and today we're gonna share our research on the recent WhatsApp zero-click attack chain on iOS and Samsung devices.
00:39We will share how we analyze and reproduce the old bugs, as well as how we find some new vulnerabilities in Samsung's image libraries.
00:50And sorry that my English is not very fluent, so I will speak as slowly and clearly as I could.
00:56And for this talk, you can take any pictures if you want, and here we go.
01:03And super apps are apps with huge user bases and many features, like WhatsApp, Signal, WeChat, and iMessage.
01:13Because of their popularities, they are often the major targets for the nation-state attacks.
01:20So here are some zero-click chains in recent years.
01:25Back to 2019, attackers have used bugs in the WhatsApp VoIP stack with only a phone number.
01:34They can compromise a phone remotely.
01:38And later on, many iMessage zero-click attacks have appeared, like the false entry in 2021.
01:45They use malicious PDF files and the blast path using the well-owned web key vulnerabilities.
01:53In 2024, it is reported that some attackers used WhatsApp to target Hamas leader, Haniyeh, get his location and launch an airstrike.
02:05So, we all know that 4-chain attacks are getting harder and harder.
02:10But actually, national-state attacks still happen almost every year.
02:15So, our story starts from an iOS bug, CVE-2025-43300.
02:23And it is very famous. I think most of you have heard about it.
02:27It was fixed in iOS 18.6.2.
02:32And in August, Apple urgently fixed a bug in the ImageIO framework.
02:39And it may have been exploited in an extremely sophisticated attack.
02:45So, we thought this could be a very powerful bug.
02:48And we started analyzing it right away.
02:52We did a bin-diff on the Mac OS between 15.6 and 15.6.1.
02:59And we found that the ImageIO framework did not change a lot.
03:04But the raw camera bundles have changed a lot.
03:07And after a deeper analyze, we found two main functions get security patches.
03:13The one is the DNG loose the unpacker.
03:16And the other one is the loose this JPEG unpackers.
03:20And anyway, it was clear that these patches are mainly about DNG decompression functions.
03:27And so first, before I introduce any security stuffs,
03:31let's have a quick introduction to the DNG format.
03:35So DNG mainly stores raw images.
03:38It is basically an extension of the TIF format.
03:41Image file has three main parts.
03:44A header for byte order and a version.
03:47RFDs, which is the image file directories,
03:50contains metadata like width, height, and compression.
03:54And the data area that stores raw pixels, it is usually compressed.
04:03And an image is made of pixels.
04:05A pixel is the smallest unit, and it is usually not just one number.
04:10It contains some channels.
04:12And samples per pixels.
04:14This metadata means how many channels are in one pixel.
04:19For example, RGB has three samples.
04:22Red, green, and blue.
04:24And this sample means how many bits are used for one channel value.
04:29And one bit is just black and white.
04:32And eight bits is common.
04:33And 16 bits is higher equality.
04:36And actually, data in raw files are huge.
04:40Therefore, the data inside the DNG format are often compressed.
04:45The DNG supports these compression methods.
04:48The one is for uncompressed.
04:50The seven is loosey.jpg.
04:52And the last one is loosey.jpg.
04:54And finally, DNG can also include some opcode lists.
05:00This adds extra processing steps during the parsing logic.
05:05There are three stages.
05:07One after reading the raw data.
05:11And after linear mapping.
05:13And after demo sites.
05:15And there are 30 opcodes in total.
05:17Each with different functionalities.
05:20And it's really easy to make some mistakes in opcode handling.
05:25And we will come back to it later.
05:28And next, let's introduce the attack vector.
05:31And different apps can trigger the same bug in different ways.
05:37For example, the preview goes through the image kit.
05:42And while other apps may go through UI kit.
05:46In the end, they both call image.io APIs to render some images.
05:50Then through the core graphics and the core images.
05:54And finally, we will trigger the bugs in the raw camera implementations.
05:59So back to the raw camera diff.
06:02Apparently, the patches for loosey unpacker was much easier to read.
06:09And loosey list part was much more complex.
06:12So we start with loosey unpacker first.
06:16And the patch was very clear.
06:19In the old version, it multiplies tile width and height.
06:23In the new version, Apple added and checked at each step using 128-bit calculations to detect overflows.
06:33So it looks like that the Apple wanted to eliminate integer overflow here.
06:38So it looks very simple.
06:40So we just tried it right away.
06:43We added a DNG file and made the width and height very large to trigger overflows.
06:49But it was not that simple.
06:52Before reaching that code, there was an earlier check.
06:55The tile width and height cannot be larger than 20,000.
07:00And with that limit, the product won't overflow.
07:03So this did not sound like the real bug.
07:07But we, after several rounds of guessing and randomly playing with the metadata,
07:14we finally triggered a crash.
07:16And that made us very excited.
07:18And the bug was simple.
07:20Just while we played with the DNG metadata,
07:23we found that the unpacker didn't check the product of image width and image height.
07:29We changed them from all very small values to big ones like 0x6000.
07:36So the product became negative.
07:38And we got all the bounce rate and rise finally to trigger a crash.
07:42So is this 0 this?
07:46Unfortunately, no.
07:48This was an old bug fix in 15.4.
07:51But we tested our old Mac OS 15.2.
07:55So we found it my mistakes.
07:58So, but still, ImageIO is a very active attack service anyways.
08:04And so what is the real bug behind this sophisticated attack chains?
08:10On the same day, we found the old bug.
08:13The battery boy posted a short analyze and a working POC for this bug.
08:19He started from a dog photos.
08:22It is a Luzis DNG file from a photo gallery website.
08:27And then he changed only two bits.
08:30The samples per pixel from one to two and the num components from two to one.
08:37And we still don't know how he found this trick,
08:40but it triggered an OOB crash in the Luzis JPEG unpackers.
08:46So, there have been many analyses of these vulnerabilities,
08:50such as the blog post from the Cox lab.
08:53So we just will briefly summarize it.
08:57And this is a simple view of the unpacker functions.
09:00Firstly, it allocates a buffer based on the width times height times samples per pixel.
09:07And to store the decompressed output.
09:12And then it loops over height and width.
09:15So actually, it visits every pixel.
09:17For each pixel, it loops over channels and decompresses the data for the channels.
09:24And the bug is that the real pixel size in the unpacker is the num components.
09:31So for one row, the loop limit should be width times num components.
09:38But actually, it is hard coded as width times two.
09:42So when num components is one, the loop runs about twice as many times as it should.
09:49So here is a simple example.
09:52The original image is two times two DNG with two channels.
09:58So the buffer size is eight.
10:00Each time a pixel is traversed, the two channels of data are decompressed.
10:06But because the width times two x four, the loops will run over eight times.
10:15But the first four times, the writes will exceed the buffer.
10:21So the rest becomes an auto-bounds write.
10:24So it causes an overflows.
10:27So we wonder that, is this DNG bug used in another typical iMessage attack?
10:34The answer was surprising.
10:39On the last day of August, the WhatsApp released a security update.
10:44It was very clear that this bug was used in a real WhatsApp in the wild attacks.
10:52So next, my colleagues Yizhou will introduce how we analyze and reproduce the WhatsApp zero-click attack.
11:00Oh, hi, everyone.
11:06And now I'm going to talk about this CVE-202555177.
11:10And it's the zero-click vulnerability of WhatsApp on iOS, iPadOS, and iPadOS.
11:16Okay, let's start.
11:17Let's first talk about the zero-click attack surface.
11:21The zero-attack surface in WhatsApp can be roughly divided into three parts.
11:27The first one is the protocol handling.
11:30There are some complex protocols like VoIP, RTP in WhatsApp.
11:36There are a lot of states in these protocols.
11:39And there are some attack surfaces.
11:43And then comes the file format parsing.
11:46Something like forms, images, and the documents, all these kinds of attack surfaces.
11:51And finally, it's the message process.
11:54WhatsApp deals with messages it receives.
11:57And if there are some problems like deserialization, error, or improper handling, it may cause vulnerabilities.
12:03And today, the issue we talk about is the last one, that is the improper handling.
12:09Now, let's come back to the advisory.
12:12We can see that this CVE has a very detailed advisory.
12:16And we can see that the vulnerability of WhatsApp is fixed in 21.73 version.
12:23And as a security researcher, of course, I want to check that the last version was this vulnerability and perform some patch analysis.
12:32So I went to the app store.
12:35And we can see the previous version was 20.84, skipping a lot of versions, which means that meta does a lot of inner version iterations.
12:48And there must be a lot of function updates.
12:51And maybe it's difficult to do the patch analysis.
12:54But nevertheless, we can still have a try.
12:57There are two main binaries in WhatsApp.
13:00The first one is the main program, WhatsApp, and the shared library called the shared modules.
13:06As we can see, there are totally about millions of functions in these binaries.
13:11And a certain of them are different.
13:13And it's hard to find the real vulnerabilities without any information.
13:18So the patch analysis approach is not working.
13:22So we turn back.
13:23Since there is a detailed advisory, we are trying to find the vulnerability again.
13:29So let's come back to the advisory.
13:31We can see that there are two interesting points in the advisory.
13:36Firstly, the vulnerability is about the incomplete authorization of linked devices.
13:42Linked devices refer to the WhatsApp devices using the same account.
13:46And secondly, the vulnerability is not about the messages with the image.
13:51It's weird because we know that the subsequent chain uses the DNG parsing vulnerabilities.
13:57But instead, it is about the processing content from arbitrary URL.
14:02And that's very interesting.
14:04So let's quickly take a look at the content of WhatsApp message.
14:09The WhatsApp message is encoded in its own format.
14:12And since there is a web client of WhatsApp,
14:15it can be easy to reverse.
14:17And thanks to WPP Connect team for releasing a lot of tools to do the reversing.
14:22By the way, these screenshots were obtained from the GitHub repository.
14:27We can see that the message is encoded in Protobuf.
14:31And there are many types of messages, such as image messages, document messages, etc.
14:37These message types can also be composed with a lot of components.
14:44And now, let's see how we can turn a URL to an image.
14:49It naturally came to me that URL preview is a very promising entry.
14:54Firstly, when you input some text in WhatsApp client like this,
14:59FDR is a URL in the text.
15:01Then WhatsApp will try to fetch the content from the web page and generate a subnail.
15:07However, this subnail is not generated on the web server or on the receiver.
15:13It's just on the sender.
15:15That means that the sender downloads and passes the image and then it will generate a subnail.
15:20Then you send an extended text message, extended message to the, as you can see in this Protobuf
15:34definition, and the receiver will receive something like this.
15:38The message contains just a subnail instead of the original image.
15:43So, it's not quite the same with the advisory.
15:46Because it says that the URL parsing happens on the target devices instead of the sender.
15:52So, the common URL preview features may not be what we want.
15:56There must be something more interesting.
15:59So, after some attempts, we found this request URL preview message type in the Protobuf definitions.
16:06So, what is this kind of message, and why WhatsApp clients need this?
16:11Let's see.
16:12Because we all know that mobile devices or PC devices, they have their own system libraries
16:18or web views to do the URL preview, and they can generate the subnails themselves.
16:23However, when it comes to web clients, they cannot simply preview the URL and generate the subnail themselves.
16:29So, they need the help of the linked devices.
16:33To check it, there is an easy way that if you input something in your web client and put your forms in the flight mode,
16:41then you will see that your web client cannot preview the URL anymore.
16:46And then, let's see how the whole process works.
16:50Firstly, if you input something in the web client, and it will generate a preview request like this.
16:56You can see that the URL argument is in the request.
17:01This is a peer data operation request, so it will be sent to the linked device.
17:06And the linked device will then fetch the target URL and generate the corresponding subnail.
17:13And you can see, at this time, the linked device does not require any user interaction.
17:19It will automatically pass the image, generate the subnail, and send it back to the web client.
17:26And finally, the web client will send the message with JPEG thumbnail.
17:35We can see that in this process, linked devices act as a server, and it helps to pass the image.
17:41So, it may be the attack target of the zero click chain in the wild.
17:45So, we know that this is a kind of peer message, and it's originally supposed to be sent only to the device logged in the same account.
17:58So, there is a problem that, is this kind of message be able to be sent to other devices?
18:05Let's come back to the message transmission of WhatsApp.
18:08This is just a simple illustration.
18:11The actual transmission process is far more complex, and we are not talking at this time.
18:18So, we can see that, firstly, the sender and the receivers have a per-shared key,
18:24and the sender just used JID, that is the phone number of the Reserpoint's account,
18:29and then encrypt the message with the per-shared key and send it to the server.
18:34The server just forwards the message based on the phone number to the receiver.
18:38And finally, the receiver decrypt the message with the per-shared key.
18:43That's why we say this message is end-to-end encrypted.
18:47So, we know that just knowing the phone number messages can be sent to anyone.
18:55So, if I'm an attacker, I can forge a request URL per-view message and just send to anyone I want to attack.
19:01And the targeted device act as a linked device, and it will try to fetch the malicious URL passing the malicious DNG
19:12and trigger the DNG vulnerability without the user being aware.
19:16Since we know that the message is end-to-end encrypted, the server cannot retrieve the message.
19:22So, the server cannot check the content you send is in the correct format.
19:27Only client-side check can prevent the search messages from being processed.
19:34So, let's see how the client checks the peer messages.
19:39After some reversing, I found the should process payload function.
19:43It determines whether to handle this message or not.
19:48If this message should be handled, it will return true.
19:53Otherwise, it will return false.
19:55The function firstly checks that if this message is posted from peer.
20:01The messages from peer device are always trusted, so it returns true.
20:06And then, if the message is not sent from the peer device, it will check if this is a protocol message.
20:13This function only considers protocol messages, and if it is not a protocol message, it continues the process.
20:23And finally, it will check whether message type is on a whitelist, as you can see on the screenshot showed on the right.
20:32To see what messages types correspond to these numbers, you can refer to the following protobuf definition.
20:39The peer data operation request message types correspond to 16, which is in the whitelist.
20:46Go through the entire process, we can see that the peer messages will always be handled even if it is received from other devices.
20:57Thus, we can forge this kind of messages and send it to anyone we want.
21:02However, there are still some problems when we reproduce the vulnerabilities.
21:09We can see, when WhatsApp clients fetch the image, it sets a range in the HTTP request header, requiring that the image size must be less than the limit.
21:21However, the poke we just created in the previous part was modified on a real DNG image, which is very large, with a size of about several tens of megabytes.
21:34Therefore, we have to generate the DNG files of the appropriate size ourselves.
21:39Then, we patch a third-party client to send a message to trigger the vulnerabilities and reproduce the problems.
21:48Here is the demo.
21:52First, we check the versions of the client on macOS, iOS, and iPadOS.
22:04Then, we log in the attacker's account.
22:07This account is not related to the victim, and it's not added to the contact.
22:12And then, input the phone number we want to attack.
22:15And then, the victim devices fetch the images.
22:19As you can see, the server receives the request, and then, boom.
22:23We can see...
22:25We can see the crash mode.
22:29It has crashed in the image I.O., which proves that we really triggered the DNG vulnerabilities.
22:41Finally, let's see how WhatsApp fixed the problem.
22:46The upper code is before fixed, and the one below is after fixed.
22:52We can see that WhatsApp adds a check for these kinds of messages.
22:57The messages types like pair data operations need additional checks afterwards.
23:02With this patch, WhatsApp clients only process messages of these types from linked devices.
23:11While we are analyzing these vulnerabilities, we also notice that Meta posts a bug report to Samsung about the QRAM image library.
23:24It's Samsung's system library to parse the DNG file.
23:28We wonder that if these DNG vulnerabilities can be triggered in the same way on Samsung.
23:34So, we did a little reversing on WhatsApp.apk.
23:39And we can see that when parsing image, WhatsApp uses the BetMet factory.
23:44And it is built with the LibDNG SDK and will not call the QRAM Lib Samsung uses.
23:52So, the Samsung's exploit chain may not use this vulnerability of the pair message.
23:58This is all my part of WhatsApp's zero-click vulnerabilities.
24:02Next, let's welcome my colleague, Kyra, to introduce our research on Samsung DNG vulnerability.
24:18Hello, hello.
24:20Hello everyone, I'm Kyra, and I will introduce the Samsung part of this story.
24:27First, in September, we first came across this security advisory, and it immediately caught our attention.
24:43In this advisory, Samsung mentioned that they were notified that this vulnerability was already being exploited in the wild.
24:53And they also pointed out that the affected component was the library called lib-image-codec-qram.
25:03So, our very first reaction was that, wait a second, could this be the same vulnerability as the one we saw on iOS last month?
25:17So, naturally, the next thing we did was download the firmware, extracted the library, and run bing-diff on it.
25:30And luckily, Samsung was very generous.
25:35The symbols in this library were still available.
25:39So, that made the bing-diff process extremely clear and easy to read.
25:49What we found was that the differences weren't actually that many.
25:55The number of functions that really differed was pretty limited.
26:02Basically, just the ones you can see here in this picture.
26:11Then, we identified roughly about three major differences.
26:18And the first one shows up in the op-code map table initialize function.
26:27As my colleague, John Ray, mentioned earlier, inside a DNG file, there is something special called op-code.
26:38And when the parser starts processing these op-codes, the first thing it does is initializing how many op-codes exist in the image.
26:53Based on that number, it will allocate a vector to install them.
26:58Here on the slides, you can see the version before the patch on the left and the version after the patch on the right.
27:07The key change is that they added a sanity check.
27:13The op-code count must be less than or equal to one million.
27:20And after that, the rest of the logic stays the same.
27:25It simply creates elements according to the op-code count and pushes them into the vector.
27:36Then, let's move to the second diff.
27:42This check is in the op-code list, especially inside the do-apply function.
27:49This is the place where the op-code actually gets applied.
27:55For example, if an op-code represents a crop operation, the real logic is executed inside this do-apply function.
28:07And again, in the patched function, they added an extra validation.
28:14The op-code type is now required to be less than or equal to 0xd, which means the op-code type must fall between 1 and 13.
28:28In other words, unknown op-code types are no longer allowed to apply.
28:34And here's the third difference.
28:40This one appears during the initialization of an unknown op-code.
28:46What it does is place a limit on the size field of the op-code.
28:54It has to be smaller than a certain value, which is actually still quite large.
29:00And it's roughly about 3 million in hex.
29:08And so if we take a step back, these were the three most obvious patches we saw at that time.
29:18There were also a few smaller changes, but these three really stood out.
29:26And honestly, this is where we got pretty confused.
29:32Because none of these three patches seemed to be directly related to the actual vulnerability.
29:40So while we were still stuck there, we were trying to figure this out.
29:49Someone on X suddenly jumped in and posted a tweet.
29:53They said, this is actually pretty obvious.
29:56The vulnerability is right at that 1 million check.
30:02Do you remember the first patch I just talked about?
30:08And someone else replied and asked, is the out-of-bounds happening because the op-code count is too large?
30:20And they even said, yes, apparently.
30:24But when we actually looked at the code more carefully, his interpretation didn't really hold up.
30:36So what's happening here is that the count is only being used to allocate a vector.
30:45In other words, this check is to limit the capacity of that vector.
30:52So it doesn't directly introduce a vulnerability.
30:57Essentially, it just prevents a DNG image from allocating an excessively large amount of memory.
31:08And if you do the math, one million entries is roughly on the order of a megabyte.
31:17Even if each op-code took a few dozen bytes, you are still only talking about a few tens of megabytes.
31:28Which really isn't that large memory for modern cell phones.
31:35So from our perspective, this check is mainly there to restrict heap spraying.
31:48It looks much more like mitigation against exploitation rather than a fix for the actual vulnerability itself.
31:57And the other two patches fall into the same category.
32:04They are also about limiting the attacker's ability to exploit the bug rather than addressing the true root cause.
32:16So at that point, what can we do next?
32:21We had these three patches, but none of them really look like a real vulnerability.
32:30So honestly, we decided to stop overthinking it and just try debugging something.
32:40The first thing we wanted was to build a POC and see if we could trigger a crash.
32:51Our idea was based on the second patch.
32:55Originally, there was no proper limit on the size field.
33:01So our thinking was, what if we allocate an extremely large size and force the new operation to return a null pointer.
33:15And then we can hit null pointer dereference in the following code.
33:20So that was our initial hypothesis.
33:26So we constructed a DNG that was about two gigabytes in size and fed it into the library to see what would happen.
33:39And yeah, the image was actually constructed and loaded by the library.
33:49Then what happened?
33:53Yeah, as our expected, it did crash.
33:58But if you take a closer look at the crash stack trace, this might be a bit hard to see on the slide.
34:10But there is a line I highlight here in the middle showing the fault address causing the crash.
34:20And that address is something like 0xb4 blah blah blah blah blah, which is clearly a heap address.
34:31So even though the program crashed, it didn't crash in the way we expected.
34:38So the question is why the crash wasn't caused by a null pointer dereference at all.
34:46So we decided to dig much deeper and really debug this issue.
34:52And then we ended up discovering a true zero-day.
35:02That's exactly what the title refers to.
35:06The birth of this zero-day.
35:09And we started by analyzing the crash using the stack backtrace.
35:14As you can see here, the crash happens inside the function qram dng stream get data.
35:22This function is used almost everywhere in the library when it reads a dng image.
35:31Basically, nearly all fire read operations eventually go through this function.
35:39The logic is fairly simple.
35:44It reads a requested size, but internally it processes the data in step of 0x1000
35:54using an intermediate offset to track how much has already been read.
36:01And that's where the problem is.
36:06This offset is stored as an integer.
36:10Each iteration adds about 0x1000 to it.
36:17And because it's a 32-bit integer, once it reaches around 0x7FFF,
36:27it overflows and it becomes negative.
36:32So at that point, the code ends up performing a memory copy to a very large negative offset,
36:42which is an obvious heap out-of-bounce access.
36:47And that's what caused the crash.
36:52At that point, we still didn't really know what this vulnerability actually was.
36:58So we just kept testing.
37:00And as we continued testing, we hit another crash.
37:05And this is the birth of another zero day.
37:09This happened when we tried to reuse an existing POC for the DNG vulnerability on iOS.
37:22Our initial idea was very simple.
37:26We would like to just take the iOS DNG sample and run it on Samsung.
37:33But that didn't work at all.
37:35The fire wouldn't even load at first.
37:38So we tried to adapt the iOS vulnerability DNG into a version that Samsung would accept just to see how it behaved.
37:53And yes, it did crash again.
37:57But this time when we look at the stack backtrace, something felt off.
38:04The crash was happening inside an OP code called fix bad pixels constant.
38:12That immediately raised the red flag.
38:17Why would it crash here?
38:19So once again, we went back and did a deeper analysis.
38:24And sure enough, we had found yet another zero day.
38:28And in the end, these two zero days had different outcomes.
38:34One of them was rated as higher severity by Samsung, while the other one was marked as a duplicate.
38:45And we later confirmed that this duplicate was collided with Brandon from Project Zero.
38:55He has been finding quite a lot of issues in Samsung's QRAM library recently.
39:03And as far as we understand, this particular issue may not be fully pastured yet, according to some official information.
39:16And it's expected to be disclosed maybe next week.
39:22So let's take a step back and recap the whole story.
39:33First, back in August, Apple and Meta released the patches to fix the zero-click vulnerability chain.
39:43Then, if we look at the Samsung timeline, the vulnerability was actually reported much earlier.
39:56In September last year, Samsung stated that they had received a report from Meta.
40:05However, the issue wasn't fixed until more than half a year later, around April this year.
40:15And interestingly, the CVE ID itself wasn't assigned until this September.
40:26Then, about two weeks ago, on December 13th, Project Zero published a blog post that went into very detail about how this vulnerability was exploited in the wild.
40:44So, let me briefly summarize what this bug actually looks like.
40:51The one natural question is that why didn't we catch it during our earlier BINDIF analysis?
41:02The reason is that the patch was extremely subtle.
41:07It only added a single multiplication.
41:14In the BINDIF results, the similarity score was 0.99 to the naked eye.
41:24The two versions looked almost identical, basically the same.
41:30So, we ended up overlooking it at that time.
41:36As for how the exploit works, the attacker somehow needs to get the victim to save a malicious DNG image onto their device.
41:52On Samsung devices, there's a service called IP service.
41:57This service periodically scans images stored on the phone and performs analysis on them, most likely for AI-related features.
42:09During this analysis process, it naturally passes DNG images.
42:17And that's exactly where the attack happens.
42:22While passing the malicious DNG, the IP service gets compromised by the attacker.
42:29What's also interesting is that there's actually another change in this whole story.
42:40If you look at Samsung's advisory from September, you can see that the CVE IDs are consecutive.
42:51One is 210.42 and the other is 210.43.
42:58This indicates a completely new exploit chain, meaning Samsung was attacked again in this year.
43:09But if we go back to the chain that was fixed in April, Samsung never stated in their advisory that it was being exploited in the wild.
43:22And on top of that, the CVE ID for that issue wasn't even assigned until this September.
43:31So from the CVE numbering alone, you can already tell that these issues are closely related.
43:40As for us, we started our analysis after Apple released their advisory.
43:47And during that process, we reported two vulnerabilities ourselves and the managers to reproduce the iOS chain.
43:59At the same time, Project Zero was independently analyzing and reporting similar issues.
44:06They've reported many DNG-related vulnerabilities to Samsung so far.
44:12And most of those were finally patched in the most recent advisory released this December.
44:20So in reality, the story still has a lot of unanswered questions.
44:29And honestly, that's the part we find most fascinating.
44:34In Samsung's exploit chain, how exactly the zero-click part was achieved.
44:44No one really knows how that step worked.
44:48And it also raises another question.
44:52Were there actually two different zero-click vulnerabilities?
44:57One used last year and another one used this year?
45:02Or was it the same bug?
45:04We seemingly don't know.
45:07Even though Project Zero published a detailed blog post,
45:12they analyzed the WhatsApp vulnerabilities they discovered.
45:19But they still were not sure whether the bug corresponds to the zero-click entry point in the exploit chain.
45:31So in the end, the story is far from over.
45:36There's still a lot left to uncover and a lot more to dig into.
45:44And finally, let's take one last look at Samsung's history with the zero-click vulnerabilities.
45:52About five years ago, one of the earliest Samsung zero-click attacks was demonstrated by Project Zero's Juro,
46:04who built a demo targeting Samsung's MMSS service.
46:11That attack exploited Samsung's specific image format called QImage.
46:24Now, fast forward five years, and we are looking at the same vendor and the same image parsing library.
46:34At first, I wanted to compare the two chains in detail and analyze how they differed.
46:43But in the end, I realized that that wasn't even necessary because Project Zero already summarized it perfectly.
46:54The conclusion was that except for some ASLR bypassing tricks and a little bit of JLP,
47:03no mitigations posed a significant hurdle for the attackers.
47:10So when you look at this, even after five years, there hasn't been a fundamental change for zero-click attacks like this.
47:24The overall status hasn't really evolved that much at all.
47:29So let's take a final look at the history of zero-click exploit chains.
47:38Last year, also at the CCC conference, Boris disclosed the operation triangulations,
47:47which exploit vulnerability in TrueType font parsing.
47:54And the year before that, we analyzed the libwebp vulnerability, which was a bug in webp image parsing.
48:03And going even further back, there was the PDF parsing vulnerability in iOS.
48:11And this year, we believe that there were at least three different exploit chains, all targeting the DNG image parsing.
48:22So what has actually changed in terms of mitigations?
48:28If we look at the applications like WhatsApp, many modern protections such as PAC, the BTI, CFI are largely absent.
48:39These defenses tend to be more thoroughly deployed in first-party system applications, like iMessage, where security is given a much higher priority.
48:54But for third-party applications, they are still developed by the device vendor themselves.
49:04They are not developed by the vendor themselves.
49:08So these protections still lag behind.
49:12And the same goes for the sandboxing.
49:15And finally, we have MTE.
49:19Google has already introduced the MTE since Pixel 8.
49:23But rolling it out broadly and effectively across the whole ecosystem will still take a significant amount of time.
49:33So as security researchers, we still have a long road ahead of us.
49:40There's plenty of work left for us to do.
49:44And that's all.
49:45Thank you for listening.
49:46Awesome.
49:47Thank you for those interesting insights.
50:03Can you please wait a little bit?
50:07Be quiet if you go outside.
50:09Let's have a look to the stage management.
50:10Do we have some time left?
50:12Yes.
50:13We have ten minutes for questions.
50:16If you have questions, we have placed microphones in the middle, right in the front here and in the back there.
50:24If you are not able to stand up and want to ask a question, give us a sign.
50:30We pass your microphone.
50:32Can the rest be quiet, please?
50:34Yes.
50:37Okay.
50:38Questions?
50:39No?
50:40Okay.
50:41Do we have questions from the internet?
50:55We have questions.
50:56Oh, microphone number two.
51:01Yeah.
51:02Wonderful speech.
51:03Thank you so much.
51:04Very interesting work.
51:05I have a question about this Samsung library.
51:07Is this library specific to Samsung or is it a part like also for Android open source project,
51:12OSP?
51:13project are OSP. It's specific for Samsung only. It's developed by the third party provider for
51:25Samsung. So actually in Samsung's cell phones they had two image passing libraries. The one is the
51:39default for Android which is hwui and another is this libqram. Thank you. Thank you so much. Thank you.
51:54Okay more questions? Any questions from the internet?
52:09Okay. Okay. I think that's it. Thank you so much. That was really awesome.
Be the first to comment