Extract full photos/videos database from any locked Google Pixel phone

A vulnerability affecting the latest Pixel devices on the latest software allowed full forensic extraction of the entire photos and videos library, including images/videos currently in the trash. It retrieved original files with the original metadata.This vulnerability also affected every Android phone shipped in the last ~5 years with Google Play Services (which preinstalls Android Auto).Since this is considered “extraction of data protected by Titan M2” (user data), Android VRP guidelines show that such exploits are worth up to $500k. Other OEMs show similar bounties (Samsung offers up to $400k).The report was initially rated low quality (despite providing all possible information including all possible patches of the vulnerability over 100 comments in the span of a few months), then closed as WAI (working as intended) & then closed as duplicate of a report which was submitted 3 months after mine, and 2 months after it was already reproduced & triaged. Android VRP refused to adjust it further.The Android VRP rules say that only if a report is not reproduced can a duplicate report be considered instead. My report was reproduced & triaged in early June, the “duplicate” was submitted at the end of July.Android security team refused to answer whether the duplicate report mentioned device extraction, or was just another unrelated bug that just happened to also fix this issue as well.Android security team also claims that they developed the fix thanks to the “better explained duplicate report”, which was submitted days before the first update that fixes the bug was shipped, in contradiction to what they mentioned saying that updates take weeks to develop and test before being released (so, an update fixing this bug was issued before the other report was even triaged).The August/September patch provides a hotfix, while the final fix is released in the November patch.I used to laugh at Cellebrite employees (why don’t they just submit the bugs to vendors?) but now they are the ones laughing at me :(

Apr 04 2024 — Report sent

Jun 03 2024 — Reproduced & Triaged as High severity, Low quality

Aug 06 2024 — Awarded $3000 as low quality

Sept 06 2024 — Changed to WAI (Intended behavior)

Sept 28 2024 — Changed to Duplicate of (report sent two full months after mine was reproduced and triaged)

Oct 03 2024 — Android VRP manager joins the conversation, confirms that report had a fair assessment

November 2024 — Android VRP refused to change report quality & closes report, missed out on a life changing bounty

Back in March, I was in an Uber and my phone was very low on battery, so I asked the driver for a charger cable. As a security conscious person, it was the first time ever doing something like that. He gave me a cable that was connected directly to the car.

After plugging in, I was shocked to find that “setup Android auto” showed on my phone, even though my usb connection setting is set to “No data transfer” instead of “File transfer / Android Auto” and my phone was locked. I tried twice, to make sure.

Going back home, I memorised this event and decided to investigate further after a few days.

Android emulator provides a tool called DHU emulator. It is indended to debug/test Android Auto devices/apps via USB Debugging, but it can also be used to turn your computer into a full Android Auto head unit. Plugging your phone in will have the same effect as plugging it into a real car.

When you plug your phone into a USB accessory, the phone is switched to Accessory Mode. It then looks for a compatible app installed on the phone. If it exists, then it will be launched, and a communication channel will be opened between the phone and the accessory connected.

Android Auto makes use of this feature.

If the Android Auto app is disabled, then the bug is mitigated. However, it comes pre-installed and enabled on every shipping Android device in the last ~5 years worldwide.

When you plug in a USB device, the USB service first checks the current USB setting. If “No data transfer” is set (which is default), then the phone only charges via USB.

The problem was that Accessory Mode starts even when the device is locked and in “No data transfer” mode, because the USB service doesn’t perform that check when connecting a USB accessory, as it does when connecting a regular USB device.

Since Android Auto makes use of accessory mode, this is why the connection was established despite not choosing the File Transfer/Android Auto usb mode.

After playing around with the DHU emulator, I found out that if there is a severe connection instability, the device will slowly re-establish connections after being disconnected, and if the connection is very unstable one of the connections will be a usb PTP mode.

So if you plug in an Android phone with default config (even if USB mode is set to “no data transfer” and it was never connected to android auto before) and constantly quit and reopen the DHU Emulator (phone thinks it’s an android auto car), then the phone will slowly reconnect, disconnect, reconnect, and the last reconnect will be in PTP mode. You can now simply download all pictures and videos (including ones in trash), with the original metadata and everything else.

The Android security team said that switching to PTP is expected behavior when the connection is unstable, as this behavior is intended to “optimize the connection between your phone and your car’s infotainment system for a seamless Android Auto experience.”

(note how it is called a security issue in the first sentence, then they contradict that statement)

After the initial report, there were 2 months of silence. In June, the Android security team rated it as High severity and Low quality.

I was a bit confused, so I asked why this is. They responded saying that it’s because my report lacks information about why the issue is occuring, and what Android source code file should be patched to fix it.

I explained that the cause is that Android Auto/Accessory mode is bypassing “Charging only”, and I mentioned it in the original report. I explained that this is because when connecting a usb device, the usb service checks for the current usb mode before establishing a connection, but it doesn’t perform that check when connecting an accessory, so that is why Android Auto starts.

I then suggested that UsbDeviceManager.java should be the patched file, and that there should be a check that doesn’t start accessory mode on lock screen/while having a screen lock.

I also provided a bit more context regarding Android’s accessory mode, the fact that it isn’t blocked while device is locked, which Android source code is responsible for handling such connections, which Android source code file should be patched to prevent Accessory Mode from starting on a secure lock screen (as it doesn’t serve any purpose other than being an attack surface). I also suggested that usb data lines should be completely blocked while device is locked (currently they allow alternative modes including Accessory Mode which is enabled when connecting Android Auto).

The Android security team said that they are investigating the information provided.

In August, they decided to reward it as a low quality report.

(rewards may also be higher if you are the manager’s friend, apparently)

In September, I woke up to a surprising email. The report status was changed to Intended Behavior. The Android security team explained that Android Auto switching to PTP mode is intended behavior, and so is it bypassing Charging only, as it is just a “mislabel”. Please note that I mistakenly referred to “No data transfer” as “charging only” across the comments and the report, as this is how it’s called on Samsung phones (and I never noticed the different label). I’m not sure why they didn’t correct me before saying it was a mislabel.

I responded that even if that is intended, the picture leak still happens and it bypasses the screen lock confirmation that occurs when plugging in a device in PTP/MTP mode (no files are accessible until the user unlocks device).

After a few days, the report status was changed to Duplicate, which was even more surprising.

The problem is that, the “duplicate” was submitted 3 months after my report, and 2 months after my report was reproduced and triaged.

Tony, Android VRP manager joined in and explains that:

This report does not constitute “exfiltrating data from the secure element”This report is correctly assessed as a duplicate, even though the other report was submitted 2 months after mine was reproducedand triaged and a hotfix was releasedThe report quality will be re-assessed a “fourth” time, which will be the final one.

I responded that:

I was referring to “exfiltrating data protected by the secure element, which is in scope and is different than extracting data from the secure element (which would mean extracting pin/pattern/password and it would count as code execution since there would be no other way to extract it)The rules only mention if a report is not reproduced can a duplicate be considered, but mine was already reproduced and triaged months before the duplicate was submitted

There was a lot of back and forth with the report, but this is the described issue summarized over the months:

If there is a connection instability (connect/disconnect), phone will slowly reconnect. If the connection instability is severe, it will reconnect in PTP mode.This is because Android Auto starts even when in “Charging only” USB mode.The Android security team said that switching to PTP mode when the connection is unstable is intended behavior. So, therefore, the issue is still that it starts on the lock screen and it doesn’t check whether device is unlocked or not before enabling accessory mode, as it does when plugging in a regular usb device

After “duplicating” my report with another report that was submitted two full months after mine was reproduced and releasing a fix before the duplicate report was even triaged/filed, I was very curious what the fix was.

Tony repeatedly said that report quality is necessary for the Android security engineers to understand what the issue is, and specifically mentioned “what Android source code file should be patched”. Understandable. This is why in my early comments, I immediately mentioned disabling accessory mode on lockscreen in UsbDeviceManager.java:

When the November patch was released, I immediately checked the Android security bulletin to check what changes were made.

The “fix” is in UsbDeviceManager.java. https://android.googlesource.com/platform/frameworks/base/+/2457d4e459ee6ffd099b9ff7cce9c83119c3ce66%5E%21/#F0

if (msg.arg1 != 1) {
+ if (mCurrentFunctions == UsbManager.FUNCTION_ACCESSORY) {
+ notifyAccessoryModeExit(operationId);
+ } else {
+ setEnabledFunctions(mScreenUnlockedFunctions, false, operationId);
+ }
}
break;

A whopping two lines, and this fix doesn’t disable accessory mode on lockscreen so it’s worse than my fix which eliminated this entire attack surface! The duplicate report was surely more helpful in thinking of coming up with this patch.

Hopefully, the person who cashed out $150k instead of me (if it was ever awarded for extraction, since they refuse to disclose it despite being “the same issue”) took Tony out for some drinks.

Just like some companies rig their contests to have their friends win them, it seems that Google’s VRP became just another scammy program that does similar things. I have only submitted a handful of reports since 2018 to them, so it’s not like they “rewarded me too many times” either.

Unfortunately, it looks like Google VRP has turned to the dark side of not rewarding researchers and making up excuses like other companies such as Apple (which never rewards any reports, but for another reason, to make people sell to brokers to ensure feds have a large pool of iOS exploits) and Microsoft. I would not take their program seriously anymore.

Also, I submitted a few LPE to System as POC only, if I submitted them as exploits (which I lack the skills for) their reward would’ve been 10x higher, so it’s not like they didn’t get “a good deal” out of my reports either.

However, this shouldn’t downplay the work that their engineers put into Pixel devices. They are the most secure consumer hardware and I would never use other devices because of this. Google is the only company who puts effort in securing the world (Chrome compared to other browsers, Android compared to every other desktop/mobile OS, etc).

They were the first to ship a MTE enabled platform (Pixel 8). They also implement “random chrome/android asan” where a small percentage of Chrome/Android users get “software MTE” which if it detects memory corruption, then the app/site crashes and so sites/apps hosting exploits can be discovered easily. No other company does this because of pressure from the feds which leads to other companies to submit to their demands (e.g. Apple).

If you want the only secure mobile experience available, get a Pixel and install GrapheneOS.

As said multiple times across the comments, I really think Android VRP should remove/change the so called “special bounties”, if they are never rewarded. The highest awarded bounty in the history of Android VRP is listed by them on the bughunters site and it does not exceed $200k, proving that none were ever rewarded. They were surely submitted before, as exploit brokers don’t care about this class of bugs (device data extraction).

(me) #4 Apr 5, 2024 02:35AM
I attached the video. It took me 3 tries, and also the terminal app just hanged instead of exiting (like before) so in-between tries i pressed ctrl+c (to end it) then up arrow and enter and so on, so you may need to do the same if the app doesn't exit by itself.The root cause is related to the connection - when you connect to Android Auto, the hud switches the phone to Accessory Mode and communicates with it even though you chose "charging only" before. It overrides every time, even if you manually set it to charging only between tries.When you connect it normally it stays in PTP (MTP but only for images/vids) mode and it prevents pictures from being leaked, but if you switch between the two quickly it gets "confused" and you get a few "ping backs" from the phone from the past connection tries, until it connects the last time and actually displays the pictures/vids.But even so, this is incredible. You can literally do this to any Pixel 8 (and probably more Android phones are affected).You could easily build a raspberry pi "pixel hack tool" which plugs into any phone, runs this PoC automated and extracts the user's picture library, without their passcode.But what is crazier is that it also displays the pictures currently in the trash. (...)As for the mitigation, I suggest disabling "accessory mode" while the phone is locked.(...)This may be considered a partial lock screen bypass considering you get access to the full photo library from a fully "secured" device, without any interaction from the owner.(...)Sequence 01_1.mp4
611 MB
Download(me) #7 Apr 7, 2024 02:40AM
Hi. Do you have a timeline for fixing this bug? I believe it requires an urgent fix. Anyone with physical access can extract the entire photo library of locked Pixel phones.ps...@google.com<ps...@google.com> #8 Apr 9, 2024 01:13PM
Hello,Thank you for your inquiry. We are currently investigating this question and will respond with additional information when available.Best Regards,Android Security Teamps...@google.com<ps...@google.com> #9 Jun 3, 2024 06:57PM
Hello,The Android security team has conducted an initial severity assessment on this report. Based on our published severity assessment matrix (1) it was rated as High severity and Low quality.This issue has been assigned to the appropriate team for remediation. We will provide an update on remediation status as it becomes available. We ask for your continued confidentiality as we proceed with our standard investigation and remediation process.Thank you,Android Security Team.(1) Severity Matrix: https://source.android.com/security/overview/updates-resources#severity(me) #10 Jun 3, 2024 07:07PM
Hi. Why is it considered a low quality report? I know that the steps of reproduction are weird and it does not have a 100% success rate, but that's because of the bug and not the way the report is written. I'm a bit confused. The only "improvement" to the reproduction steps was if i were to create an app which automates the behavior of closing and reopening the DHU app, but it would still require physical interaction with the device multiple times.
ps...@google.com<ps...@google.com> #11 Jun 3, 2024 11:34PM
Hello,To receive a high quality rating, your report must contain a root cause analysis with information about why the issue is occurring and what Android source code should be patched to fix it. Your report received a low quality rating because no root cause analysis was present.Thanks,Android Security Team
(me) #12 Jun 4, 2024 09:11AM
After disabling the Android Auto app, the issue stops happening, so the picture leak seems to be related to that instead of the "overriding usb charging only" setting. The app is closed source so providing the exact root cause is impossible.So basically there are two issues:The AOSP issue which, if you plug in usb accessory mode, it overrides "charging via usb only";The issue in the Android Auto app (which is built in to every Pixel phone) which causes the picture leakThe suggested patch (disabling accessory mode when device is locked) will solve both these issues.
(me) #13 Jun 4, 2024 09:18AM
Also, I thought that providing a patch is optional and only if you want to participate in the patch rewards, doesnt affect report quality.
(me) #14 Jun 4, 2024 10:15AM
I think that in frameworks/base/services/usb/java/com/android/server/usb/UsbDeviceManager.java at line 461:private void startAccessoryMode() {
if (!mHasUsbAccessory) return; int operationId = sUsbOperationCount.incrementAndGet(); mAccessoryStrings = nativeGetAccessoryStrings();
boolean enableAudio = (nativeGetAudioMode() == AUDIO_MODE_SOURCE);
// don't start accessory mode if our mandatory strings have not been set
boolean enableAccessory = (mAccessoryStrings != null &&
mAccessoryStrings[UsbAccessory.MANUFACTURER_STRING] != null &&
mAccessoryStrings[UsbAccessory.MODEL_STRING] != null);you could add a thing which checks if the keyguard is secure
(me) #15 Jun 4, 2024 10:32AM
Probably like this (i don't know anything about coding so i hope this is not a waste of time):private void startAccessoryMode() {
if (!mHasUsbAccessory) return; int operationId = sUsbOperationCount.incrementAndGet(); mAccessoryStrings = nativeGetAccessoryStrings();
boolean enableAudio = (nativeGetAudioMode() == AUDIO_MODE_SOURCE);
// don't start accessory mode if our mandatory strings have not been set
boolean enableAccessory = (mAccessoryStrings != null &&
mAccessoryStrings[UsbAccessory.MANUFACTURER_STRING] != null &&
mContext.getSystemService(KeyguardManager.class).isDeviceSecure(userHandle) != true &&
mAccessoryStrings[UsbAccessory.MODEL_STRING] != null);

(me) #18 Jul 12, 2024 08:38PM
Is there an estimated fix timeline?

The bug can be remediated quicker by first fixing the Android Auto photo leak (which can be sent out via play store app update), followed by the AOSP fix related to the accessory mode starting on screen locked devices and bypassing "charging only".Also, will the report quality rating be reconsidered?Thanks.ps...@google.com<ps...@google.com> #20 Jul 18, 2024 06:20PM
Hello,Could you please provide more details on Charging only" USB setting for further review.Best,Android Security Team
(me) #21 Jul 19, 2024 09:38PM
When using the charging only USB setting, AOSP doesn't disable the usb data lines (or alternative usb modes, or Accessory Mode).In future releases, I highly recommend disabling USB data lines at a driver/kernel level when using "charging only", and when the device is locked regardless of usb preferences, to prevent issues like this.
(me) #22 Jul 19, 2024 09:45PM
(Note - I'm referring to implementing that on Pixel phones, because I'm not sure it can be implemented in software alone without device-specific modifications, but AOSP can be hardened by the previous recommendation of disabling Accessory Mode on secure lock screen)sp...@google.com<sp...@google.com> #24 Aug 6, 2024 08:56PM
** NOTE: This is an automatically generated email **Hello,Android & Google Device Vulnerability Reward Program panel has decided to issue a reward of $3000.00 for your report. Congratulations!Rationale for this decision:
Congratulations! The rewards committee decided to reward you USD $3,000 for reporting this High severity vulnerability. We are paying for the bug report (Low Quality), and proof of concept. Please note rewards are substantially higher when researchers submit higher quality reports.
(...)(me) #25 Aug 6, 2024 09:10PM
I wish I could've provided a "high quality" report, but I believe I provided all the details I could about the issue, the root cause, along with suggested patch. I don't know what I could have provided more. I added details about how the android system behaves with the "charging only" setting like you asked me to. Very disappointing.
(me) #26 Aug 6, 2024 09:19PM
The Android Auto app puts the phone in ptp mode which causes the picture leak, but that's because the Android OS first starts accessory mode while "charging only" is enabled and phone is locked (otherwise it wouldn't happen). Who is at fault? The accessory mode for starting while device is locked and in "charging only".
(me) #27 Aug 6, 2024 09:26PM
Issues like these arise from the fact that Android does not block usb data line connections, even while "charging only" and locked. So I suggest disabling usb data lines at a kernel/driver level while device is locked and/or is in "charging only".(me) #29 Aug 8, 2024 07:25PM
More info which "explains" the background of the issue in more detail (even though it doesnt add any information to the report)Android OSThe Android OS supports various usb connections, including accessory mode. When connecting such a device, it tells the android os to start accessory mode and look for a "related app" of the usb device.A usb accessory device can have an assigned "related app" that it works with. Android Auto is a system app included on all Android phones, allowing all devices to use this feature when connecting to Android Auto head units. If the app wasn't installed, accessory mode would still be triggered but there would be no app to launch.When connecting an usb accessory, accessory mode starts (in UsbManager.java) and a communication channel (FileDescriptor) is opened via usb.ParcelFileDescriptor fd = usbManager.openAccessory(accessory);
FileInputStream inputStream = new FileInputStream(fd.getFileDescriptor());
FileOutputStream outputStream = new FileOutputStream(fd.getFileDescriptor());The "related app" of the usb accessory can communicate to the accessory this way.byte[] buffer = new byte[1024];
int bytesRead = inputStream.read(buffer);
outputStream.write(buffer, 0, bytesRead);
...(me) #31 Aug 11, 2024 08:41PM
Also, the reason accessory mode starts while in charging only is that, when connecting a normal usb device, UsbDeviceManager.class first checks the usb preference, to ensure it respects "charging only". However when an accessory is connected, it does not check that and this is why it overrides charging only. It is probably intentional however.
(me) #32 Aug 11, 2024 08:44PM
(also in comment #29 i meant to say UsbDeviceManager.java instead of UsbManager.java, and in comment #31 .java instead of .class)

(me) #35Aug 31, 2024 12:31PM
Also, while I understand the report quality criteria, I still don't agree with the low quality assessment of this particular report, I believe it should be at least Moderate or High quality given the detail/information provided. Other reports had similar amount of detail/information and they were all rated high quality.

(me) #36Aug 31, 2024 12:34PM
If you have suggestions on improving report quality, I'd love to receive them.
(me) #37Aug 31, 2024 06:32PM
Due to the nature of bug hunting, duplicates and etc, providing all the information in the original report is not always possible. When I created the original report, I did not know about the picture leak and the other details. I added them separately, as soon as I learned about them. Apologies for the "looks" of the report.ps...@google.com<ps...@google.com> #40Sep 6, 2024 11:05PM
Hello,Thank you for your patience while we investigated the security issue you reported.After further review, we've determined that the reported UI label might be confusing for advanced users who adjust their phone's USB settings. However, it's important to clarify that Android Auto itself doesn't directly switch your phone to PTP (Picture Transfer Protocol) mode. This behavior is intended to optimize the connection between your phone and your car's infotainment system for a seamless Android Auto experience.Based on this clarification, we've revised the report's severity and no longer consider it a security vulnerability. Additionally, per the Android Security Rewards Program rules (1), CVEs are typically not assigned for issues categorized as Not a Security Issue.As a result, this report is now closed and will no longer be actively monitored. However, as a token of our appreciation for your research and contribution, the reward for this report has already been processed and is on its way to you.We appreciate you bringing this to our attention.Sincerely,Android Security Team(1) https://www.google.com/about/appsecurity/android-rewards/11:05PM
11:05PM
-Hotlist:​1111693(me) #41Sep 6, 2024 11:13PM
Thanks, but I'm a bit confused.Regardless of the "cause" of this issue, the end result is that users' full photo library can be accessed from a locked device set to "charging only".Even if "charging only" was a "mislabel", it still bypasses the requirement to "allow" a computer to access the files on the internal storage while locked.(me) #42Sep 6, 2024 11:21PM
If you set the USB connection mode to PTP or MTP, lock the device and connect your phone to a computer, it will show up as "empty storage" until you unlock the phone. However this bypasses that.
(me) #43Sep 6, 2024 11:34PM
What is the point of a secure lock screen if strangers who take your phone can still access all the info on it? What security does a phone have where this is intended behavior?(also, you know bug bounty is over if even Google pulls things like these :( i need a new hobby asap)
(me) #44Sep 7, 2024 01:31PM
Also, please note that this allows full photo library extraction, not just being able to view the photos.It extracts the full library with the original files, metadata and even deleted photos and thumbnails. It can be considered a "forensically sound" extraction since it retrieves the original image files without any modification, as they are stored on the phone.This makes a difference because Cellebrite is a multi million dollar company whose only business is selling such capabilities to governments. They must be valuable then. Pixel devices with Titan M2 are the only Android devices in the world which cannot be bruteforced/extracted, until bugs like these show up. Also, I agree that "charging only" was misleading because like I said, it still allowed for accessory mode/android auto, so it didn't fully disable the data lines. I hope you will improve USB hardening.
(me) #45Sep 7, 2024 02:00PM
Android Auto itself doesn't directly switch your phone to PTP (Picture Transfer Protocol) mode. This behavior is intended to optimize the connection between your phone and your car's infotainment system for a seamless Android Auto experience.so the DHU (car) was switching the phone to ptp mode? was it happening only when the connection was "unstable"?
(me) #46Sep 7, 2024 02:03PM
so an accessory can switch the phone to a different usb mode? meaning that it could also switch to mtp instead and do a full "internal storage" extraction?
(me) #47Sep 7, 2024 08:24PM
Also, in the latest firmware the phone no longer "pings back" with connections when it gets "overwhelmed" (so it cancels the pending ones), but it still starts Android Auto when you chose "no data transfer" usb setting. I assume the full fix is not released yet?
(me) #48Sep 7, 2024 08:34PM
And as I mentioned, regardless of the cause, this report is about full picture library extraction (original files with metadata and even deleted pictures and thumbnails) from a device that is locked with a passcode and has never been "trusted" to any computer.Basically, a forensically sound extraction of the entire photos library.(me) #50Sep 22, 2024 10:37AM
If the switch to PTP happens when the android auto connection is unstable, and it doesn't check whether the screen is locked or not before giving access to the picture library (like it does if you choose ptp mode in usb settings), then isn't it still a bug because it bypasses that check?ra...@google.com<ra...@google.com> #52Sep 28, 2024 12:01AM
Status: Duplicate of 353712853
12:01AM
Status:​Assigned Duplicate of 353712853
Hello,Thank you for this report.The fix for this is included with the fix for another bug and we are marking this as a duplicate. As this is still a valid report, you are already rewarded for the report and will be credited on CVE-2024-43085 of the fixed report.The duplicate issue is being tracked by the Android ID reflected in the status of this ticket.Thanks,
Android Security Team
12:01AM
Message last modified on Sep 28, 2024 12:04AM(me) #53Sep 28, 2024 07:17AM
Hi,Sorry, but I'm still very confused.Dupe checking is finalized about a month after the report is submitted, before it is "triaged" (severity decided).At the beginning you triaged this as high severity and low quality. I disagreed with the quality rating. If switching to ptp while connection is unstable is intended, then the root cause is that accessory mode starts while device is locked (correctly stated at the beginning).You then revised it saying that this is intended behavior which I disagreed with because it bypasses ptp/mtp screen lock check, so it is a security bug. It is to note that this is a full photos extraction bug, not just "view some pictures without unlocking". Since cellebrite is a multi million dollar company whose sole purpose is to discover and sell such bugs, I assume they are valuable.Now, you said that it is a valid bug, but actually a duplicate. I believe that dupe checking would've happened back in May, not only now after a fix was deployed.Sorry, but I don't believe that this report had a fair assessment. Bug bounty is over.
(me) #54Sep 28, 2024 07:22AM
Also, all my report ids have consecutive numbers (based on time of submission). This report has an "older" ID (332824993) than the one it is supposedly a duplicate of (353712853). How would it duplicate an older report?, and wouldn't the other report be a duplicate of this one, since this one was submitted first?
(me) #55Sep 28, 2024 07:24AM
Based on the report id, the other report was submitted at the end of July, whilw this one was submitted at the beginning of April.
(me) #56Sep 28, 2024 07:28AM
Also, please note that this bug affected every Android device released in the last ~5 years that has google play services (which pre installs Android Auto). This was an impactful bug.
(me) #57Sep 28, 2024 07:30AM
(Correction for comment #54 - "how would it duplicate a newer report?")
(me) #58Sep 28, 2024 07:35AM
If you're not comfortable as a company with the payout for high impact bugs like these, you should revise the severity table instead.
(me) #59Sep 29, 2024 10:55PM
I mentioned this before, but take note of the forensic value of this bug. It is able to extract original image files, along with all their metadata, and even photos currently in the trash (along with their metadata too).It is also easy to execute, and essentially all Android phones sold worldwide in the past ~5 years are vulnerable.
(me) #60Sep 30, 2024 01:37AM
Also, I never do public disclosures but I feel like it's warranted for this report. I don't understand how it went from accepted/low quality to intended behavior to duplicate of a newer report in the span of 1 month, and I feel weird about it. I will show you the draft before posting.I am also confused on what exactly you mean by root cause - could you pls elaborate? There must be some confusion here. I view this report as a valuable universal extraction exploit.an...@google.com<an...@google.com> #61Oct 3, 2024 12:08PM
12:08PM
+CC:​an...@google.com
Hey (me),It's Tony from the Android security team. Let me see if I can clear up some confusion regarding this report.Payments
Most importantly I wanted to ensure that you received your reward of $3000. Please let me know if there are any issues regarding payments.Regarding quality
A High Severity vulnerability is eligible for a reward of up to $7000.Our team considers the following factors that they already mentioned. I've simplified it in my own words here.An accurate and detailed description of the issue including the device name and version
A root cause analysis and where in Android source code the bug exists or what logic should be changed to fix it (different than actually submitting a patch)
A proof-of-concept such as video recording, debugger output, etc.
Steps to reproduce
Quickly scanning this report I think the root cause analysis is what most contributed to the quality rating. You raise a good point here and I will consider adding examples of High quality reports to our Rules page.Duplicates
Now let's address the issue of duplicates. You were the first submitter of this issue. However, our team was unable to reliably replicate the issue using the information provided in your report. A similar issue was submitted around the same time but with a more reliable proof of concept. Our engineers relied on the detail in that subbmission to develop the fix. You are therefore a co-finder of the vulnerability and can be credited for the CVE. I see you opted to remain "Anonymous" and that's how it will be credited unless you requested to be acknowledged differently.Following up
There was a lot of back and forth in this report and it's possible I missed a point of concern. If you have any additional questions, I will do my best to answer them.Thanks again for taking the time to submit these issues. They do help make our ecosystem more secure.Cheers, Tony12:08PM
Message last modified on Oct 3, 2024 12:10PM(me) #62Oct 3, 2024 12:37PM
Root cause
In the original report I said that the problem is Android Auto/accessory mode starts while device is locked and in "charging only" mode.The team said that it is intended behavior, and also switching to ptp mode in certain situations while using Android Auto is intended behavior.I mentioned that it still bypasses the screen lock check that happens when using ptp/mtp mode, so it is still a bug.Low quality is usually only provided for reports where there is no information on reproduction, for example, GrapheneOS submitted a full filesystem extraction issue but did not know the specific bug that caused it, only knew that it happened via fastboot mode. Their report received a low quality rating and $3000.https://x.com/GrapheneOS/status/1765872460765806645Duplicate
On June 3, the report was triaged, meaning that it was reproduced.
Any report submitted from now should be a duplicate of mine.Around the end of July the report it's a duplicate of was submitted, based on the report number.
I can't be a "co-finder" of an issue that was submitted 2 months later, when mine was already reproduced.Rewards
Device extraction bugs are worth way more than the max $7000 for high severity reports. Full data extractions are worth up to $250k, partial extractions like these are probably worth around/up to $100k judging by several OEM guidelines.Also, pls note that videos were also extracted by this exploit, so an entire category (photos/videos)Samsung says that a full data extraction in AFU is $200k and in BFU $400K.https://security.samsungmobile.com/securityPostDetail.smsb/189Fairness
As stated previously, I believe this report did not have a fair assesment, in order to not reward the high bounty it would've received. As I said before, if you are uncomfortable with such payouts, you should adjust the severity/reward table and everyone will be happy.
(me) #63Oct 3, 2024 12:42PM
It should have received at least Moderate quality, since it has nothing to do with low quality reports (where the issue or steps to reproduce are not even revealed or are unknown to the reporter)
(me) #64Oct 3, 2024 12:48PM
If you were unable to reproduce you would've said so and asked for more info. But since the report was triaged at the beginning of June, there is no way that a report submitted at the end of July would've been more helpful and you would've waited 2 months to start developing a fix.The real reason is probably that the duplicate reporter had no idea of the extraction part of the bug and did not mention it therefore it will receive a standard bounty.
(me) #65Oct 3, 2024 12:51PM
Android security patches are developed months prior to the release (Aug/Sept patches fix this issue so there's no way that the duplicate report submitted at the end of July already had a fix in these patches while mine submitted in April didn't)
(me) #66Oct 3, 2024 01:55PM
Small correction - the other report was submitted 3 months after this one, and 2 months after it was triaged and reproduced successfully.I believe that after such a long time a fix was already developed, since device extraction bugs have higher priority to fix.
(me) #67Oct 3, 2024 01:56PM
Also, the extraction severity is hinted in your severity guidelines: "Data secured by a Secure Element: up to $250k"The password protecting the user data is secured by the secure element. This also makes it in line with other OEMs (Samsung offers up to $200k AFU and $400k BFU)
(me) #68Oct 3, 2024 01:59PM
I understand that those are huge bounties. In the end, it matters how/if you value such bugs (extracting user data). But rating this report duplicate of one submitted after 3 months when you already reproduced mine is unfair.
(me) #69Oct 3, 2024 05:15PM
A root cause analysis and where in Android source code the bug exists or what logic should be changed to fix it (different than actually submitting a patch)Provided in comment #31. There is no reason for accessory mode to be enabled on the lockscreen, it only causes security issues like this bug.Disabling it will eliminate every issue that comes with it. Eventually, disable it and if an accessory is connected show a text saying "Unlock to use accessory", similar to the existing "Unlock to use NFC" if nfc is disabled when device is locked.The logic that needs to be changed is disable accessory mode while device is locked, as previously stated.
(me) #70Oct 4, 2024 12:28AM
If the problem is caused by switching to ptp when in Android Auto, and that is intended behavior, then the bug here is Android Auto / accessory mode bypassing "charging only" USB setting and starting on the screen locked lock screen, which was correctly stated in the original report.an...@google.com<an...@google.com> #71Oct 4, 2024 11:36AM
Hey (me),I understand your frustration with the timeline and overall experience. I'm not sure if there's anything I can say to remedy that. Personally, I consider my primary responsibility at Google to always advocate what's best for our researchers. For example on your other report we discussed yesterday, the team went out of the way to ensure that you received the highest reward that it was eligible for.I can only give you my word that this was triaged and rewarded fairly. While uncommon, it does occasionally happen where a later report better explains the root cause analysis backed by code, documentation, and proof of concepts with high reproduction rates. The quality of a report directly ties to our team's ability to isolate and remedy the issue in a timely manner. Here is an example of one such instance.I do believe there is a slight misunderstanding about the Secure Element's role in this issue. I checked online and couldn't find any researchers that have publicly disclosed their research in this space unfortunately. This vulnerability in particular doesn't enable arbitrary code execution at that processing level.The main thing to keep in mind regarding credit, is that we reward for the information that results in finding the bug in a large and complex codebase and also results in issuing a fix. I don't have any direct high quality reports to share yet but here are some resources that may better clarify a various spectrum of quality.How to submit a complete bug report applicable to Android from our Bug Hunters site
This is a Google VRP example
This is how Microsoft explains it to their researchers
In the future, I will ensure the team is doing a better job explaining that quality rating is backed by standardized metrics and is not arbitrarily handled.Best, Tony
(me) #72Oct 4, 2024 01:49PM
The example report
The "high quality report" linked just explains the fix you already deployed, it was not included in the original report.The first thing that surprised me when I first looked at this commit was the number of files changed. I previously thought that this bug would only have a simple one-liner fix, removing the incorrect line of code responsible for triggering an unlock. But it was not that simple:After reading the commit message and the code changes, I think I was able to get a rough picture of what happened under the hood.This shows that the reporter actually had no idea about the root cause.In my report, I showed the piece of code responsible for launching accessory mode, communicating with the device, and also showed that it does not check usb preferences before launching on secured lock screen/charging only setting.PoC improvement
in comment #10 I mentioned that since this report was about inducing connection instability, then there wouldn't be much improvements possible in the PoC, since it still required physical interaction with the phone. However, as you have seen in the PoC, it takes 4 minutes to reproduce. Is that really that bad that it "disqualifies" my report?Exfiltration of Secure Element / Titan M2 protected data
This vulnerability in particular doesn't enable arbitrary code execution at that processing level.Because this is data exfiltration of data protected by a secure element, not code execution on a secure element.Also, since other OEMs have special bounties for data exfiltration, I assume you do too, and this is specified on the rules page:Data exfiltration reward amountsHigh value data secured by Pixel Titan M Up to $500,000High value data secured by a Secure Element Up to $250,000I would like to make a small correction now. While I previously said that the second category would match this bug (partially), I actually believe the first one does since the user data is secured by Titan M, not another secure element.Titan M2 devices are the only Android phones that cannot be bruteforced by Cellebrite, because it successfully throttles attempts. The user data is secured by Titan M2. However, this bug causes it to be revealed even without authentication. Therefore, it is a bypass, because it exfiltrates data protected by Titan M2.The problem with the special bounties is that the report has to be high quality. If the report is high quality it receives up to $500k. If the report is "low quality" (which I still disagree with), it receives a measily $3k (compared to up to $500k).As I said before, if you are uncomfortable with these high payouts, or you feel like my report "doesn't deserve it" because it's not technical enough (like the previously linked report was), you should adjust the severity/reward table so report submitters have correct expectations.Duplicate report
I want to ask an important question - did thr "duplicate report" (submitted 2 months after mine was reproduced/triaged) mention data exfiltration? Or it didn't and it will be awarded just a normal bounty (max $7k)?Also as said previously,my report was submitted in April and triaged in May
the other was submitted in early August (or end of July)
we are assuming it also took a few weeks to triage
the fix was deployed in the update that was pushed in early August and early September
Did a report which just came out cause the fix to be made? Or was the report fixed based on my report? Why would the Android security team wait 3 months then suddenly develop a fix days after a "better report" is sent? Did they just wait without investigating/developing a fix 3 months and right before the update was pushed? Also, Security Updates are developed at least 1 month before they are released so this doesn't add up.Sorry, but this report was assessed unfairly. You should update the guidelines and remove the data exfiltration reward amounts if you feel uncomfortable paying such bounties, but this was a valid report and it should've been awarded according to the guidelines.Disclosure
For transparency, I will publicly disclose this issue (including comments) in a week, since the issue is fixed. If you disagree or want to wait more let me know.
(me) #73Oct 4, 2024 01:55PM
The "example high quality report" is a writeup and explanation of the fix you already deployed. The original report did not contain a root cause analysis at all.You can actually view the original report here: https://feed.bugs.xdavidhu.me/bugs/0016It just contained steps of reproduction and a PoC video.
(me) #74Oct 4, 2024 02:17PM
If you want to have both accessory mode on a secure lock screen and android auto's ptp switching behavior, you can add a check that checks if the device is unlocked before switching to ptp to improve connection. I provided all the possible ways to fix this bug.an...@google.com<an...@google.com> #75Oct 4, 2024 03:05PM
Status: Assigned (reopened)
03:00PM
Status:​Duplicate of 353712853 Assigned
Hi (me),You mistook my first link as an example of a High quality report. If you revisit my previous comment, you can see I did not claim that. That was an example where a second report or "duplicate" of an issue was actually what led to the understanding and remediation of a vulnerability. In that example the second report is what led to a fix even though someone else reported a bug first. This determination is made by the team that issues the fix. There will be no change regarding this determination.This report does not qualify as exfiltration of data from the secure element. No change will be made to this decision.Regarding the quality of the report, I will ask another engineer to review the entire submission and offer a fourth opinion. Please understand that this decision will be final.Regarding disclosure, we do not grant or deny permission to disclose issues. We do appreciate you letting us know about your disclosure plans. If possible, it is preferred to coordinate disclosure. We anticipate tentatively releasing the fix for this issue in our November security bulletin.Despite the disagreement on the report quality rating, I do hope some of this dialogue proves helpful for any future submissions. I do truly appreciate you taking the time to help secure the Android ecosystem.Regards, TonyOn behalf of the Android Security Team03:05PM(me) #76Oct 4, 2024 03:15PM
You did not answer, does the duplicate report mention data extraction or is it an unrelated report that just happens to fix this as well?This report does not qualify as exfiltration of data from the secure element. No change will be made to this decision.It is not "exfiltrating from the secure element", it is exfiltrating data protected by the secure element. There is a huge difference.It is not extracting the pin/pattern/password that is stored in the secure element, it is extracting user data which is protected by the secure element.Your guidelines specifically mention "data protected by the secure element", not "data stored by the secure element". For the latter, it would count as code execution on the secure element, as there is no other way to exfiltrate it without having code execution on it first.In that example the second report is what led to a fix even though someone else reported a bug first. This determination is made by the team that issues the fix. There will be no change regarding this determination.I do not believe that you did not develop the patch after my report and just waited 3 months until another report came and then instantly released a patch.The issue may not be "fully patched" until November but currently it's impossible to reproduce on the current update. The current update ia developed months prior to release (as said by you in the linked report's comments), so there is no logical way that you instantly released a fix days after another report was filed, while my report did not help you and you did not start developing a fix based on it.
(me) #77Oct 4, 2024 03:17PM
I will ask another engineer to review the entire submission and offer a fourth opinion. Please understand that this decision will be final.As if they wouldn't be fired afterwards for "incorrect quality rating" kekwan...@google.com<an...@google.com> #78Oct 4, 2024 03:19PM
I'm not at liberty to disclose the details of someone else's report at this time.I will still have the report reviewed. If the quality is changed or gets upgraded I will let you know.-Tony
(me) #79Oct 4, 2024 03:27PM
It's not disclosing the details, it's disclosing whether it mentions data extraction or not, which is relevant. Since both are about the same issue (supposedly), I don't see why it shouldn't happen.
(me) #80Oct 4, 2024 03:30PM
Again, my issue is about creating a connection instability in order to make the device switch to PTP which is intended, but it shouldn't have happened while device is locked. I don't see how the other report would be more helpful in any way, or have a more reliable PoC since mine took 4 minutes to execute. It would still involve physical device access and creating a connection instability.
(me) #81Oct 4, 2024 03:33PM
I understand that device extraction is worth a huge bounty. I understand that you may not feel comfortable awarding such bounties. However, you should change the rewards table and remove the entries instead of pulling things like these.
(me) #82Oct 4, 2024 04:45PM
Also, the rules say that only if a report is not reproduced, then duplicates will be rewarded instead. You reproduced mine two months before the "duplicate" was submitted.So you just chose which report to reward from the "pool" of duplicates submitted, even though my report caused a fix to start being developed first.
(me) #83Oct 4, 2024 04:55PM
This is again in contradiction to the rules.You should modify them saying: "we will reward (what we percieve as) the highest quality report, even if we received and were able to reproduce it prior".But this did not exist when I submitted my report. When I submitted it, it only mentioned rewarding the first report where you are able to reproduce it. You reproduced it first with mine, so it should be the "original" report, not duplicate.ps...@google.com<ps...@google.com>Oct 4, 2024 07:02PM
Status: Duplicate of 353712853
07:02PM
Status:​Assigned Duplicate of 353712853
07:02PM
+Hotlist:​5893992
07:06PM
-Hotlist:​1111693(me) #84Oct 5, 2024 09:46PM
I will publish it the day the "official" November patch is released, even though it is already fixed (and will show that as well).(me) #85Oct 5, 2024 09:53PM
Also, I think you should remove the data exfiltration categories from the rule page, since they are very misleading.
(me) #86Oct 6, 2024 01:26AM
So I have a very important thing to mention (not sure why you didn't correct me on this earlier).I checked the PoC video, and this is how the USB settings looked like (attached image).The options are: "No data transfer", ... , "File transfer / Android auto"."No data transfer" was set.This is crucial because it confirms that Android Auto starting in "no data transfer" is indeed a bug.The root cause provided earlier (USB service doesn't check for current USB mode setting before starting Accessory mode) is valid, as the USB service does check for the current USB mode when plugging in a non-accessory.I was referring to it as "charging only" all this time because this is how it is on Samsung phones (I'm a long time Samsung user and I never noticed the different label). So it is not a mislabel, Android Auto starting when "File transfer / Android Auto" is not checked is indeed the bug.Screenshot 2024-10-06 at 01.19.35.png
315 KB
View
Download(me) #87Oct 6, 2024 01:32AM
So the final summary is:Bug - Android Auto starts in "No data transfer" mode which leads to the photos/videos library leak due to unstable connection (which is intended behavior).Root cause - USB Service does not check the current USB mode before starting accessory mode when an accessory is connected. (It does check when connecting a regular USB device)Mitigation - Disable accessory mode on the lock screen as it serves no purpose other than being an attack surfaceThis was all provided in the above comments and the original report. I was extremely confused by this report, but I did provide this information in the original report and shortly after in comments.
(me) #88Oct 6, 2024 01:41AM
This proves that the "duplicate" report is just an unrelated report whose fix just happens to also fix this bug.ps...@google.com<ps...@google.com>Oct 8, 2024 12:34AM
12:34AM
+Hotlist:​1307511
sa...@google.com<sa...@google.com>Oct 8, 2024 05:14PM
05:14PM
-Hotlist:​1111693(me) #89Oct 18, 2024 11:58AM
I made the disclosure draft, if you want to add anything you can tell me.(me) #90Oct 18, 2024 12:04PM
(correction: doesn't check whether device is unlocked or not before enabling Accessory mode, not PTP mode)Even though this issue is partially fixed and cannot be reproduced anymore, I will post it the day the November update is released to Pixel devices.ps...@google.com<ps...@google.com> #91Oct 21, 2024 09:53PM
Hello,Thanks for sharing the disclosure draft.Best,Android Security Team09:53PM
09:53PM
-Hotlist:​1111693(me) #92Nov 5, 2024 02:50AM
The November bulletin is out, this is the patch: https://android.googlesource.com/platform/frameworks/base/+/2457d4e459ee6ffd099b9ff7cce9c83119c3ce66%5E%21/#F0It adds a whopping TWO lines of code (and a changed word from an existing line) in the same source code file I originally said needs to be patched; that comment was made months before the duplicate report was submitted.With such a complex fix, the duplicate report was surely more helpful than my report in understanding the issue.