This advisory highlights real-world attack paths that our Automotive Penetration Testing services are designed to uncover and validate before they can be exploited.

Product description

This public advisory describes vulnerabilities discovered by PCAutomotive team in Volkswagen MIB3 in-vehicle infotainment unit (IVI) model “MIB3 OI MQB” manufactured by Preh Car Connect GmbH (JOYNEXT GmbH).

This advisory adds new findings to the previous advisory released by PCAutomotive Security Assessment team in 2023, which is available here about vulnerabilities in skoda and volkswagen vehicles.

Originally, the vulnerabilities described in this advisory, were identified in Skoda Superb III car:

This car is equipped with the MIB3 IVI with OEM part number 3V0 035 820:

The IVI has a screen for user interaction. The following image shows the infotainment screen displaying vulnerable software version 0304:

Vulnerabilities described in this advisory apply not only to MIB3 IVI from Skoda cars. PCAutomotive team verified them on the head unit with OEM part number 3G5 035 816, used in Volkswagen cars.
The full list of potentially vulnerable MIB3 unit OEM part numbers is shown in the following table, with part number, on which the vulnerabilities were confirmed, highlighted bold:

infotainment systems with the identified part numbers are used in the following vehicle models (the list is not extensive):

• Volkswagen Passat
• Volkswagen Arteon
• Volkswagen Tiguan
• Volkswagen Polo
• Volkswagen Golf
• Volkswagen Discovery
• Volkswagen T-Roc
• Volkswagen T-Cross
• Škoda Karoq
• Škoda Octavia
• Škoda Kodiaq
• Škoda Superb.

Summary

PCAutomotive team discloses 12 new vulnerabilities in MIB3 infotainment unit. Those vulnerabilities were successfully chained to achieve the following impact on the car:

Once an attacker infected the MIB3 IVI with persistent malicious payload via a 1-time 1-click Bluetooth attack, they were then able to remotely control the IVI functions via a DNS tunnel over the Internet.

Remote control over the IVI allowed the following actions:

A video demonstration of achieved remote controls is available on YouTube.
Identified vulnerabilities are summarized in the table below:

Disclosure timeline

Technical details

DoS vulnerabilities in Picture Handler

Description

The first 2 vulnerabilities were discovered in the picture browser app – the feature of the MIB3 infotainment system that allows vehicle users to browse pictures from an external USB flash drive attached to one of the USB ports of the car. Images stored on the flash drive can be browsed on the in-car touch screen.

The vulnerable binary responsible for image parsing inside the IVI Linux system is: tsd.media.picserver.mib3.app.target.

Supported picture formats include, among others, JPEG. To draw JPEG pictures on the screen, the IVI parses EXIF data stored inside JPEG files.
Integer underflow CVE-2023-28902 was identified in the code responsible for parsing EXIF data.

The following pseudo-code illustrates the issue:

 1. if (JPGDecoder_jpegNextInputBuffer(decompress_struct_ptr, data, 2uLL) )
 2.   {
 3.     … // Error reading EXIF size
 4.     return 0;
 5.   }
 6.   size = (unsigned __int16)__rev16(*(unsigned __int16 *)data) - 2LL;
 7.   if ( !size )
 8.     return 0;
 9.   …
10.   ptr = (char *)operator new[](size);           // size can be -2 so we crash

The code reads 2 bytes, subtracts 2 from it, and uses the subtraction result as the size of a buffer for EXIF data. If this number is less than 2, it will unsuccessfully try to allocate a big buffer (size is an unsigned variable).

When triggered, this bug results in throwing unhanded C++ exception in the process responsible for image processing. The process receives ABORT signal from the OS and terminates. Due to specific systemd configuration, termination of that process causes the whole IVI Linux system to reboot.

Integer overflow CVE-2023-28903 was identified in the code responsible for parsing EXIF data. The following pseudo-code illustrates the issue:

 1. tag_data_ptr = (unsigned int *)(v13 + 8);
 2. tag_data_size = number_of_elems * exif_tag_size_array[type];
 3. if ( tag_data_size > 4 )
 4. {
 5.   tag_data_offset = exif_get_int(a1, tag_data_ptr, v10);
 6.   if ( (unsigned __int64)(tag_data_size + tag_data_offset) > a2->data_size )// (1) integer buffer overflow
 7.   {
 8.     … // Error: Illegal pointer offset value in EXIF.
 9.     goto EXIT;
10.   }
11.   tag_data_ptr = (unsigned int *)(a2->data_start + tag_data_offset);
12. }

Condition check (1) is not correct because the two numbers (tag_data_size, tag_data_offset) have 32-bit form, and the result of addition will be a 32-bit number. It is possible to put any number in the tag_data_offset variable and thus overflow the result of the addition (tag_data_size + tag_data_offset) and pass the check (1).

After this check, variable tag_data_offset is used for extraction of EXIF tags data. If it will have a negative or a large positive value pointing out of the bounds of the EXIF data array, process memory leak or process crash (SEGFAULT) will happen. In the latter case, due to specific systemd configurations, the whole system will reboot.

Exploitation scenario and impact

To exploit these vulnerabilities, malefactors need to attach a USB flash drive to the IVI USB port located inside the vehicle and open a specifically crafted JPEG image via IVI HMI.
During IVI reboot, infotainment services such as multimedia and navigation, become unavailable for several seconds.

Credits

The vulnerabilities were identified by Artem Ivachev from PCAutomotive Security Assessment team.

Code execution via heap overflow in Picture Handler

Description

This bug was also identified in the following binaries sharing common vulnerable code base:

- tsd.media.picserver.mib3.app.target
- tsd.bt.phone.mib3

The vulnerability could be reached wirelessly via Bluetooth, as the binary tsd.bt.phone.mib3 performs phone contact synchronization via Bluetooth and includes vulnerable code that works with JPEG images – contact photos.

Phone contact book synchronization is implemented following Phone Book Access Profile (PBAP) specification available at bluetooth.com/specifications/specs/. This feature is added to the IVI to support hands-free calls while driving the car.

Before synchronizing the contacts between the phone and the IVI, it is required to perform Bluetooth pairing of the two devices, for which it is required to confirm pairing request on the IVI screen.
The actual contact exchange works over OBEX protocol. The IVI plays the role of a Phone Book Client Equipment (PCE) and requests phone book from a Phone Book Server Equipment (PSE), usually the driver’s mobile phone.

The contact database exchanged between the two devices is a sequence of vCards. An example of such a vCard is shown below:

BEGIN:VCARD
VERSION:2.1
FN:Christopher Nolan
N:Nolan;Christopher;;;
TEL;CELL:1234567890
PHOTO;ENCODING=B;TYPE=JPEG:<image content in base64>
END:VCARD 

A contact may have the property PHOTO, and in this case, the vCard will contain the contact photo (avatar) encoded in base64. Detailed information about the contact database format can be found in RFC6350.

The contact database loaded to the IVI can later be browsed on the IVI screen. To display contact photos, the IVI performs scaling of the JPEG images to fit the table drawn on the screen:

The scaling is performed with libjpeg 9c.

When a JPEG image is loaded into memory, a temporary image row buffer with fixed size is allocated:

As a next step, the buffer is filled with image data with jpeg_read_scanlines function (a scanline is simply a horizontal row of pixels in the image):

Maximum JPEG image width is 0xFFFF pixels. The pixel size depends on the color space used (RGB, CMYK, and so on). In this case and for most color spaces, the maximum pixel size was equal to 4 bytes:

This made the total scanline length equal to 4 * 0xFFFF = 0x3FFFC bytes.
libjpeg internally scales the scanline with maximum multiplier 1/8, thus reducing the maximum length of data returned into the buffer to 0x3FFFC / 8 = 0x7FFF bytes, which is still greater than the fixed allocation size 0x4000. Thus, it was possible to craft a contact avatar with a long image width that causes the heap overflow.

Exploitation scenario and impact

This vulnerability could be exploited to get code execution on the IVI on behalf of an unprivileged user phone via Bluetooth. The PBAP server for exporting contacts could be created, for example, with nOBEX tool.

To exploit the issue, a would-be attacker needs to perform Bluetooth pairing of their device with the infotainment system.

Credits

The vulnerability was identified by Artem Ivachev from PCAutomotive Security Assessment team.

Code execution via a chain of bugs in Bluetooth stack

Description

These 3 vulnerabilities were discovered in the MIB3 IVI Bluetooth stack, more specifically – in the binary tsd.bt.phone.mib3, which handles Bluetooth communications with external devices.
Logical Link Control and Adaptation Protocol (L2CAP) Bluetooth protocol stack layer can provide data to upper layers (profiles) in two modes:

1. Fragmented packets mode – fragmentation fo1. r channels with BASIC mode is enabled. In that case, it's the channel's responsibility to reassemble the fragments.
2. Non-fragmented packets mode – fragmentation for channels with BASIC mode is disabled. In this case, no fragmentation is applied, and reassembly is not needed.

The first integer overflow CVE-2023-28908 occurred due to improper validation of user-supplied data when receiving non-fragmented Host Controller Interface (HCI) packets on a channel.
The mode mentioned is specified during the profile registration in L2CAP_RegisterPSM function. Below is the example of Audio/Video Control Transport Protocol (AVDTP) profile registration:

1.   avdtpContext.psm.callback = (__int64 (__fastcall *)(__int64, __int64))AvL2Callback;
2.   avdtpContext.psm.psm = 0x0019;
3.   avdtpContext.psm.localMtu = 0x800;
4.   avdtpContext.psm.minRemoteMtu = 48;
5.   avdtpContext.psm.flowParms.fragmentsEnabled = 1;
6.   avdtpContext.psm.rxFragments = L2CAP_FRAG_ENABLED;
7.   if ( !(unsigned __int8)L2CAP_RegisterPSM(&avdtpContext.psm) )
8.     return 1LL;

Note that avdtpContext.psm.rxFragments is initialized with L2CAP_FRAG_ENABLED value, meaning that fragmented data can be received on a channel with BASIC mode.
When a non-fragmented HCI Asynchronous Connection-oriented logical transport (ACL) packet is received, it's appended to the cumulative buffer in PHYLINK_HciBuffAppend function. The mentioned buffer has a fixed size of 1009 bytes. If the data frame exceeds the cumulative buffer size, then no data is written, and the frame is skipped. But pLink->rxLen will be updated with the frame size in any way.

 1. __int64 __fastcall PHYLINK_HciBuffAppend(BtPhysicalLink *pLink, const void *src, unsigned __int16 _srclen)
 2. {
 3.   [...]
 4.  
 5.   hciBuff = pLink->hciBuff;
 6.   srclen = _srclen;
 7.   dstlen = hciBuff->len;
 8.   if ( dstlen > 1008 )
 9.   {
10.     add_len = 0;
11.   }
12.   else
13.   {
14.     buffer = hciBuff->buffer;
15.     LODWORD(tocopy) = 1009 - dstlen;
16.     if ( (int)(1009 - dstlen) > srclen )
17.       tocopy = (unsigned int)srclen;
18.     else
19.       tocopy = (unsigned int)tocopy;
20.     add_len = (unsigned __int16)tocopy;
21.     xmemcpy(&buffer[(unsigned __int16)dstlen], src, tocopy);
22.   }
23.   pLink->hciBuff->len += add_len;
24.   pLink->rxLen += srclen; // <== total RX size is updated
25.   return add_len;
26. }

It was therefore possible to construct an L2CAP frame that contains at least two HCI ACL fragments, both having size 1009 bytes. After processing the first fragment, pLink->rxLen will become equal to 1009, and then after the second fragment is handled, this value becomes 1009x2 however the actual packet data is not changed. A would-be attacker can expand this approach to multiple HCI ACL fragments and eventually overflow pLink->rxLen to a small value that can be used to bypass MTU.

The problem identified was reachable before Bluetooth pairing. The constraint preventing exploitation of this vulnerability is that a limited count of HCI ACL fragments can be processed. This limitation depends on the created channel information.

The second integer overflow CVE-2023-28909 is applied to channels with enabled fragmentation.
When a fragmented HCI ACL packet is received, it is validated in PHYLINK_ReassemblePacket and then is relayed to the channel's data handler through L2CAP_LinkEvent handler:

1. void __fastcall PHYLINK_ReassemblePacket(BtPhysicalLink *pLink, HciBuffer *rxbf, unsigned __int16 off, int firstPacket)
 2. {
 3.   [...]
 4.   
 5.   rxlen = rxbf->len;
 6.   if ( firstPacket )
 7.     newRxLen = rxlen - 4;
 8.   else
 9.     newRxLen = rxlen - off_ + pLink->rxLen; // [1] integer overflow
10.   pLink->rxLen = newRxLen;
11.   if ( off_ != rxlen )
12.   {
13.     rxbf->len = rxlen - off_;
14.     plinkRxLen = pLink->rxLen;
15.     buffer = rxbf->buffer;
16.     evt.p.hci.hciBuff = rxbf;
17.     rxbf->buffer = &buffer[(unsigned __int16)off_];
18.     if ( plinkRxLen <= pLink->rxLenBlh ) // [2] check completeness
19.     {
20.       bt.me.linkHandler->callback(bt.me.linkHandler->context, (BtEventEx *)&evt); // [3] upper-level relay
21.       PHYLINK_FreeHciBuffs(pLink, rxbf);
22.       if ( pLink->rxLen != pLink->rxLenBlh )
23.         goto advance_rxbf;
24.     }
25.     else
26.     {
27.       PHYLINK_FreeHciBuffs(pLink, rxbf);
28.       L2CAP_LinkSendFailedStatus(pLink);
29.     }
30.     pLink->rxState = RX_INITIAL_STATE;
31. advance_rxbf:
32.     v12 = rxbf->buffer;
33.     rxbf->len += off_;
34.     rxbf->buffer = &v12[-(unsigned __int16)off_];
35.   }
36. }
37.  

Each L2CAP packet has a size field. For channels with enabled fragmentation, each HCI ACL fragment size is added to the pLink->rxLen storing the total received size of the current L2CAP packet composed of multiple HCI ACL fragments.

When a HCI ACL fragment arrives, the new rxLen is calculated in [1] and then reassigned to pLink->rxLen member. If the new length is less than the actual L2CAP packet length in [2] described by pLink->rxLenBlh, then a link handler will execute L2CAP_LinkEvent function at point [3] in the code above.

Finally, the CVE-2023-28910 is the flaw allowing an attacker to bypass the assert BGLOG_Assert function and reach parts of the code that do not expect invalid data or environment state.
The MIB3 IVI Bluetooth stack extensively uses the assertion function BGLOG_Assert that comes from the BlueGO stack. This function is designed to abort execution of the process if a specific condition is not met.

Internally, BGLOG_Assert uses bAbortion global variable to decide whether to terminate the process or not after printing the assertion message. The mentioned flag is used in conjunction with the first argument in BGLOG_Assert function. If both the argument and the flag are not zero, then abortion takes place. Otherwise, the process is not terminated.

1. __int64 BGLOG_Assert(
2.         unsigned int a1,
3.         unsigned __int8 a2,
4.         _BYTE *a3,
5.         const char *a4,
6.         unsigned int a5,
7.         char *format,
8.         ...)
9. {
10.   [...]
11.     if ( (bAbortion & a1) != 0 )
12.       abort();
13.   [...]
14.     if ( (bAbortion & a1) != 0 )
15.     {
16.       [...]
17.       qword_10A08E0("=== PROGRAM ABORTED ===
", 25LL, qword_10A08E8, 0LL, a1, v12, a3, a4, a5);
18.       sub_787320(1000);
19.       return BGLOG_Abort();
20.     }
21. }
22.  

For most BGLOG_Assert function calls, the first argument is equal to 1. Regarding bAbortion, it's assigned in set_abortflag function:

1. __int64 __fastcall set_abortflag(__int64 result)
2. {
3.   bAbortion = result;
4.   return result;
5. }

When a Bluetooth host gets initialized, it calls set_abortflag in Initializer::requestInitLocalDevice function that is an IPC callback for the IVI Bluetooth local device initialization request. In that handler, bAbortion is assigned to 0 meaning that no process termination will take place:

1. void __fastcall Initializer::requestInitLocalDevice(__int64 a1)
2. {
3.   [...]
4.     set_abortflag(0LL);
5.   [...]
6. }

Exploitation scenario and impact

The vulnerabilities CVE-2023-28909 and CVE-2023-28910 could be chained together to achieve code execution on the MIB3 IVI on behalf of low-privileged phone – the very same impact as for CVE-2023-28905. One prerequisite is that for communicating with the IVI via AVDTP protocol, and therefore, for successful attack, pairing with the IVI is required.

An attacker could then force the IVI to connect to their Wi-Fi access point and obtain access to IVI system shell:

The mentioned L2CAP_LinkEvent function internally validates the current L2CAP packet size against the channel's local MTU. In case the packet's size is greater than MTU, a disconnection request is sent changing the channel's state from OPEN to DISCONNECTING. It is worth noticing that the channel's general state doesn't affect the data reception if an L2CAP packet is not completely received yet.

1. void __fastcall L2CAP_LinkEvent(void *context, LinkEvent *event)
2. {
3.   [...]
4.           if ( lLink->pLink->rxLen > (unsigned int)channel->rxMtu )
5.           {
6.             L2CAP_SendDiscReqInternal(channel);
7.             return;
8.           }
9.   [...]
10. }

Therefore, after disconnection request from IVI is sent, an attacker is still able to send HCI ACL fragments corresponding to the L2CAP packet, advancing pLink->rxLen further and overflowing it. As long as pLink->rxLen is not equal to pLink->rxLenBlh, an attacker can overflow pLink->rxLen resulting in the channel's MTU validation bypass.

Exploitation of the MTU bypass is further possible due to the disabled abortion flag. More specifically, AVDTP incoming data handler validates the length of the written data to the destination buffer and if the new frame exceeds the destination buffer, BGLOG_Assert is executed. But with disabled abortion flag this assert function will not terminate process and overflow may happen:

 1. void __fastcall AvdtpConnConnected(AvdtpChannel *__shifted(AvdtpChannel,0x18) chan, L2capCallbackParms *parms)
 2. {
 3.     case L2EVENT_FRAGMENT_IND:
 4.       if ( status == 1 )
 5.       {
 6.         [...]
 7.       }
 8.       else
 9.       {
10.         if ( (unsigned __int16)ADJ(chan)->sduOffset + parms->dataLen > 2048 )
11.           BGLOG_Assert(
12.             1u,
13.             0xA0u,
14.             "/home/jenkins-slave/workspace/8b71e6df0b42308b56255529b8d72f0b/work/phone/bt-middleware/ext-bluego/src/1/wor"
15.             "kspace/src/bluesdk/av/profiles/avdtp/avdtpcon.c",
16.             "AvdtpConnConnected",
17.             0x103u,
18.             "(Conn->sduOffset + Parms->dataLen) <= sizeof(Conn->sdu)");
19.         xmemcpy(&ADJ(chan)->sdu[(unsigned __int16)ADJ(chan)->sduOffset], parms->ptrs.packet, parms->dataLen);
20.         ADJ(chan)->sduOffset += parms->dataLen;
21.       }
22.       break;
23. } 

Credits

The vulnerabilities were identified by Mikhail Evdokimov from PCAutomotive Security Assessment team.

Bluetooth DoS caused by arbitrary channel disconnection

Description

This vulnerability was also discovered in tsd.bt.phone.mib3 binary responsible for Bluetooth communication.

Various signaling commands can be passed between two L2CAP entities on remote devices. All signaling commands are sent to CID 0x0001 (the signaling channel). The L2CAP implementation must be able to determine the Bluetooth address BD_ADDR of the device that sent the commands. Multiple commands may be sent in a single L2CAP packet sent to CID 0x0001. A complete list of requests is provided in the L2CAP specification.

L2CAP_ProcessSignalReq function is responsible for processing the incoming signaling requests.

Disconnection request is one of the commands. As a result of this command, the IVI disconnects the channel matching the specified local and remote CIDs. Notice that there is no validation on the remote BD_ADDR meaning that any remote device can disconnect a specific channel described by the pair of <local CID, remote CID>:

1. void __fastcall L2CAP_ProcessSignalReq(BtLogicalLink *lLink, unsigned __int8 *rxdata, unsigned __int16 rxlen)
2. {
3.   [...]
4.       case LLC_DISC_REQ:
5.         cid = LEtoHost16(rxdata + 4);
6.         ch_ = L2CAP_GetValidChannel(cid);
7.         chan = (L2CAP_FixedChannel *)ch_;
8.         if ( !ch_ )
9.         {
10.           [...]
11.         }
12.         remoteCid = ch_->bc.remoteCid;
13.         if ( remoteCid == (unsigned __int16)LEtoHost16(rxdata + 6) )
14.         {
15.           state = LLC_DISC_REQ;
16.           bt.l2cap.lastRemoteIdent = ident;
17.           chan->c.bc.remoteIdent = ident;
18. sm_avdance_0:
19.           ch = &chan->c;
20. sm_advance_1:
21.           L2CAP_StateMachine(ch, state);
22.         }
23.         break;
24.   [...]
25. }

Exploitation scenario and impact

By utilizing this vulnerability, a would-be attacker can brute-force pairs of <local CID, remote CID> and disconnect any established dynamic channel between the IVI and a remote device (different from the attacker's channel). Such behaviour leads to DoS in the way that it leads to the disconnection of the channel.

Credits

The vulnerability was identified by Mikhail Evdokimov from PCAutomotive Security Assessment team.

Privilege escalation via flaws in custom IPC mechanism

Description

The vulnerability CVE-2023-28906 was discovered in tsd.networking.mib3 binary and allowed to escalate privileges in the IVI Linux system.

Linux processes in the MIB3 IVI have a custom IPC mechanism which can be used to call remote procedures in many system services. This mechanism doesn't have any privilege checking mechanism so if some process can successfully initialize this IPC mechanism, it can call any remote procedure from all services which are using this mechanism.

Service networking had a remote procedure that calls popen with partially controlled user input:

The fact that the IPC mechanism lacks any privilege level separation (CVE-2023-29113), may cause similar issues in other binaries of the MIB3 system.

Exploitation scenario and impact

A would-be attacker can use this lack of input sanitization to escalate privileges in the OS to networking service privileges. This service had the capability called CAP_SYS_MODULE, so this could be used to load a custom kernel module in the OS kernel space and escalate privileges to unrestricted root.

Example code execution on the MIB3 IVI:

Credits

The vulnerabilities were identified by Artem Ivachev and Mikhail Evdokimov from PCAutomotive Security Assessment team.

Persistence via Secure Boot bypass

Description

This issue was discovered in the bootloader binary executable of the MIB3 IVI named bl2.bin.

MIB3 system has Renesas R-Car M3 SoC as its main CPU. R-Car M3 is a 64-bit hepta-core ARM SoC designed for the automotive industry and introduced in 2016. The M3 incorporates four Cortex-A53 cores, two Cortex-A57, and an additional Cortex-R7 core for real-time processing. R7 core in MIB3 infotainment system is called CARCOM. It is responsible for handling communication of MIB3 with other vehicle ECUs via infotainment CAN bus.

The boot process of MIB3 IVI board is built in accordance with ARM Trusted Firmware specification.

Based on this general specification, Renesas built their Trusted Firmware implementation for R-Car M3 and other automotive chips. This open-source implementation was used by Preh when developing secure boot for MIB3 system. Renesas repository is available here about renesas rcar/arm trusted firmware.

Following ARM Trusted Firmware Architecture, the first boot loader called BL1 starts execution from mask ROM of the SoC. This boot loader loads and verifies the signature of the next boot loader, BL2, and passes control to it.

The main responsibility of BL2 is to load and verify cryptographic signatures of the following firmware parts:

1. BL31
2. BL32 – Trusted Execution Environment, TEE.
3. BL332 – CARCOM firmware.
4. BL333 – Linux kernel image, vmlinux.
5. BL334 – Linux device tree.
6. BL335 – Linux initrd filesystem.

All the images loaded by BL2 at every boot are permanently stored in external SPI memory chip. To save some space in SPI chip memory, some images are stored in a LZ4-compressed form. Compressed images have the following PCCP header:

PCCP headers and image compression logic are not included in ARM or Renesas Trusted Firmware implementations and were specifically implemented in the MIB3 BL2 bootloader.
In addition to the PCCP header, each image loaded by BL2 has a certificate for cryptographic signature verification. Each image certificate has, among others, the following fields:

When loading compressed image, BL2 follows the following sequence of steps:

1. Load image in compressed form to temporary RAM buffer
2. Decompress image and store it at image load address specified in image certificate
3. Call boot ROM code to verify image signature and ensure its authenticity

The problem occurs because when loading an image to a temporary RAM buffer and decompressing it, BL2 refers to its size declared in PCCP header. At the same time, when verifying its signature, BL2 refers to the image size specified in the image certificate. Image size from the certificate is not validated against decompressed image size specified in PCCP header. Additionally, PCCP header is not signed, and thus, cannot be verified.

As a result, it is possible to craft an LZ4 archive that will be decompressed into the following way:

Thus, malicious data (red area) will corrupt addresses below memory intended for original file in RAM and will be appended to the valid signed image data (green). This causes the following problems:

1. Overwriting already verified and running images in memory at higher addresses. This is possible because images are loaded not sequentially (from lower address to higher address in RAM), but following the loading addresses specified in image certificates, which apparently don’t align with image boot sequence.
2. Appending malicious data to a valid signed image, which can later result in higher level code to interpret the full image as valid data. Such an approach works, for example, for initrd CPIO archive which will later be passed to Linux kernel for unpacking and mounting.

Exploitation scenario and impact

The vulnerability allowed to bypass secure boot. When chained with other vulnerabilities from this advisory leading to code execution on behalf of root user, this allowed to gain persistent code execution on behalf of root user by modifying the content of the SPI memory, which contains boot images for the MIB3 system.

Credits

The vulnerability was identified by Danila Parnishchev and Polina Smirnova from PCAutomotive Security Assessment team.

Access to CAN bus due to lack of virtual memory isolation between CPU cores

Description

The MIB3 system includes the CARCOM CPU core for communication through CAN bus. This core is part of the RCAR-M3 SoC that also contains the main OS cores. The CARCOM core and the main core have common physical memory address space, and there are no access restrictions for OS from main chip to read and modify CARCOM physical memory, so a would-be attacker with main (Linux) OS kernel privileges can modify all physical memory of the CARCOM chip.

Exploitation scenario and impact

This security issue can be used to get code execution in context of CARCOM system and get ability to read/write to CAN bus in Infotainment CAN network of the vehicle, provided that the main chip running Linux OS is compromised.

Credits

The vulnerability was identified by Artem Ivachev from PCAutomotive Security Assessment team.

Exfiltration of phone contact database

Description

The phonebook information of the paired smartphone device is stored on the Infotainment system in clear text. The information mentioned includes the following:

• Contact name
• Contact phone number
• Contact email address
• Contact profile picture (as specified on the smartphone).

Exploitation scenario and impact

An attacker can leverage this vulnerability by compromising the IVI and extracting car user’s contact database. Compromise can be done either remotely via one of the vulnerabilities described in this document, or physically by dumping eMMC memory of the MIB3 unit, where Linux file system is physically stored.

The next screenshot shows a test smartphone having two contacts in its phonebook:

The database is stored in sqlite3 which can be found on the IVI's filesystem by executing the following command with the known contact’s name:

Contact profile pictures are stored on the filesystem:

In the mentioned database there is a table called ContactTable that stores a relationship between contact ID and hash. The latter is used as a part of the profile picture on the filesystem; therefore, an attacker can match the contact data in database with the profile picture stored in the file system.

Credits

The vulnerability was identified by Artem Ivachev and Mikhail Evdokimov from PCAutomotive Security Assessment team.

Vulnerability chaining

The following diagram shows how discovered vulnerabilities can be chained into attack paths, allowing would-be attackers to achieve certain impact:

Related publications

PCA made a talk about discovered vulnerabilities at BlackHat EU 2024.

• Slides are available here about EU 24/Presentations/EU 24 Parnishchev OverTheAirVW
• Watch the talk on YouTube here about watch