what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

wfc-pkt-router Incorrect Bind

wfc-pkt-router Incorrect Bind
Posted May 5, 2023
Authored by Jann Horn, Google Security Research

wfc-pkt-router suffers from a vulnerability where it can wrongly bind to an external network interface instead of the VPN tunnel.

tags | advisory
advisories | CVE-2023-29092
SHA-256 | 03509814b094fdcb874430f7b5654f15f7ca1ccdd20e1463ac75f2a0d6edef4c

wfc-pkt-router Incorrect Bind

Change Mirror Download
wfc-pkt-router can wrongly bind to external network interface instead of VPN tunnel

There is a daemon called \"wfc-pkt-router\" (the \"IMS packet router daemon\" according to https://github.com/ItsLynix/samsung_a53x_dump/blob/36de1bc4f9a9b3646809805b9feaf2f4396177e5/vendor/etc/init/init.s5e8825.rc) on some Samsung-based phones, including Pixel 7 and (according to that github link) Samsung a53xnaxx (?). When WiFi Calling is active, this daemon is responsible for forwarding IP packets between the baseband (/dev/umts_wfc1 on Pixel 7) and an IPSec tunnel provided by Android. wfc-pkt-router creates a raw socket bound to a specific interface (using SO_BINDTODEVICE) and forwards raw IP packets between the interface-bound socket and the baseband (/dev/umts_wfc1).

Some other mechanism outside wfc-pkt-router (I have no idea how that works) apparently causes Android to set up an IPSec tunnel with a local IP address that is also known to the baseband. When the baseband starts using an IPSec tunnel via wfc-pkt-router, it has to tell wfc-pkt-router which interface to bind to. The baseband does this by telling wfc-pkt-router the local IP address of the IPSec tunnel; wfc-pkt-router then scans through the list of network interfaces (using getifaddrs()) and searches for a matching interface. If multiple interfaces match, it picks the *newest* interface with the right IP address.

The main problem with this is that multiple interfaces can have the same local IP address. IPSec interfaces are created dynamically, so they are typically created later than WiFi interfaces or such, which means an address collision with a WiFi interface is not a problem *as long as the IPSec interface exists*; but the interfaces associated with USB ethernet adapters or VPN apps can be dynamically created after the IPSec interface creation.

I have experimentally tested on a Pixel 7 that, if a USB ethernet adapter is inserted after the IPSec interface was created, and the DHCP server assigns the same IP address that is also used for the IPSec tunnel, traffic intended for the IPSec tunnel flows bidirectionally between the baseband and the ethernet adapter - I saw an outgoing SIP connection attempt that I could intercept and reply to. (This requires that the IP address used inside IPSec is IPv4 - I have seen one provider that uses IPv4 inside the IPSec tunnel and another one that uses IPv6.)

I recommend that you give wfc-pkt-router the right interface name somehow instead of letting it search for the right interface based on IP address.

--- Additional Comments ---

Because of the bug, the baseband's SIP connection does *NOT* go through the IPSec tunnel. So the protections provided by IPSec become irrelevant.

The normal flow of data for wifi calling is like this:

1. baseband generates a TCP SYN packet
2. baseband puts the TCP SYN packet in an unencrypted IP packet
3. baseband sends the unencrypted IP packet to wfc-pkt-router (on the AP)
4. wfc-pkt-router sends the unencrypted IP packet to "ipsec*" network interface
5. Linux kernel IPSec/xfrm layer encrypts the IP packet
6. Linux kernel sends encrypted IP packet over wifi or whatever

But when the bug is hit, the data flow is instead like this:

1. baseband generates a TCP SYN packet
2. baseband puts the TCP SYN packet in an unencrypted IP packet
3. baseband sends the unencrypted IP packet to wfc-pkt-router (on the AP)
4. wfc-pkt-router sends the unencrypted IP packet to eth0 network interface

So the unencrypted IP packet from the baseband is directly sent out of the phone. The other direction works the same way.

Samsung Device Solution BU's PSIRT (dsprodsec) let me know that they plan to list this in their bulletin as:

Improper handling of parameters while binding network interface
Exynos Mobile Processor and Modem
Exynos Modem 5123, Exynos Modem 5300, Exynos 980, Exynos 1080
Denial of Service
Attacker insert malicious configured USB ethernet adapter
Binding wrong resource can occur due to improper handling of parameters while binding network interface
3.1 Low CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:L

https://source.android.com/docs/security/bulletin/pixel/2023-04-01 says CVE-2023-29092 was fixed at the 2023-04-05 patch level.

This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is 2023-05-08.

Related CVE Numbers: CVE-2023-29092wasfixedatthe2023-04-05patchlevel,CVE-2023-29092.

Found by: jannh@google.com

Login or Register to add favorites

File Archive:

September 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    2 Files
  • 2
    Sep 2nd
    21 Files
  • 3
    Sep 3rd
    0 Files
  • 4
    Sep 4th
    17 Files
  • 5
    Sep 5th
    34 Files
  • 6
    Sep 6th
    29 Files
  • 7
    Sep 7th
    11 Files
  • 8
    Sep 8th
    25 Files
  • 9
    Sep 9th
    0 Files
  • 10
    Sep 10th
    0 Files
  • 11
    Sep 11th
    26 Files
  • 12
    Sep 12th
    23 Files
  • 13
    Sep 13th
    17 Files
  • 14
    Sep 14th
    22 Files
  • 15
    Sep 15th
    16 Files
  • 16
    Sep 16th
    0 Files
  • 17
    Sep 17th
    0 Files
  • 18
    Sep 18th
    19 Files
  • 19
    Sep 19th
    60 Files
  • 20
    Sep 20th
    23 Files
  • 21
    Sep 21st
    15 Files
  • 22
    Sep 22nd
    8 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    17 Files
  • 26
    Sep 26th
    3 Files
  • 27
    Sep 27th
    13 Files
  • 28
    Sep 28th
    5 Files
  • 29
    Sep 29th
    12 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By