10 ms·

Hardening cellular basebands in Android

219 points by el_duderino 3y ago

pedrocr 3y ago
Isn't all of this obvious for a modern C or C++ codebase? Is the state of Android baseband so bad that these are useful suggestions? Are they at least properly ring-fenced from the host CPU/RAM these days?
- deleted 3y ago
  [deleted]
- DiabloD3 3y ago
  The problem is it isn't "Android baseband", it doesn't run on the CPU that Android does at al. Instead, an entire second whole computer (not even a "microcontroller", in many cases they are just as powerful per-core as your real CPU) that runs a closed source realtime OS that Google (et al.) has zero visibility into. Some phones straight up admit the baseband is actively hostile and only communicates with it via serial (which leads to poor performance, but a secure phone). Some phones, such as any using a vanilla Qualcomm Snapdragon setup of any generation simply don't care: the baseband firmware has more holes than a slice of swiss, and the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM. This is a known attack vector used by state sponsored actors, including the US breaking into the phones of so-called "drug lords" to ease drop on them live from their own phones , without a call being active. Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship.
  - csdvrx 3y ago
    > Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship. I agree. I couldn't see much of a point in the techniques discussed when there's a huge elephant in the room, and you can't fix it, so I thought I was missing something obvious. I wasn't: it's just security theater, doing something for the sake of doing something, while there's a big pink elephant in the room you should not look at: > the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM. And I can't find any valid technical reason for that elephant to be in the room. There shouldn't be limitations for accepting IOMMUs: "be liberal in what you accept and conservative in what you send" > Some phones straight up admit the baseband is actively hostile and only communicates with it via serial That looks like a fair assumption. You wouldn't have daemons listening as UID 0 on all ports, accepting then running the random binaries they get, so why would you magically assume it's ok to do the exact same but with baseband instead of a daemon? > (which leads to poor performance, but a secure phone) Can you recommend some phones? I wanted to get a better understanding of the stack so I bought an original pinephone, with the grand plan of installing arch on it (for fun!) Could it be made to work like that? A simple search only found https://www.reddit.com/r/pinephone/comments/har9aj/pine_phone_and_graphen_os/ https://www.reddit.com/r/pinephone/comments/har9aj/pine_phon... which concludes with "I don't think the Pinephone can provide any of the security requirements of Graphene OS ( iommu isolation etc )" What should I buy to explore the concept of IOMMUs on cellphones?
    - galangalalgol 3y ago
      Graphene recommends a modern pixel. If they can properly restrict memory access on those phones and the baseband doesn't have any direct access to the mic via analog signal or similar, then it probably can't listen in on either incoming or outgoing communication, that should all be encrypted before it hits the memory right? You could still be located and identified, but they don't need to compromise your baseband for that.
      - chislobog 3y ago
        This could be old info but I believe the Baseband chipset has its own microphone in addition to access to the user mics for the purposes of signal processing. This was a stink years ago and part of the GSMK product development. AFAIK GSMK is the only commercially available product to have a baseband firewall and their own stuff running to deal with this
    - DiabloD3 3y ago
      Arguably, any system that uses a Qualcomm SoC is not secure: either they do it on purpose, or they truly are incompetent, or it is a mix of both. No Qualcomm phone I've ever owned I've been truly happy with from the SoC SDK perspective (makes the job of community ROMs a thousand times harder). I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Allwinner and Rockchip do not have the security nightmare track record that Qualcomm does. They also ship with Postmarket instead of an Android that isn't security focused, which is nice. The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. Qualcomm and Mediatek just have a record, today, of security flaw after security flaw. The new Samsung-made SoCs in the new Pixels are also an interesting choice. They do not use the Samsung TPM, instead opting for Google's newest version of the Titan TPM. Shortly after the Pixel 6 came out, Google Project Zero issued a story about the Samsung TPM having security issues. Hmmmmmmmmmmmmmmmmmmmmmmmmm.
      - csdvrx 3y ago
        > I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Good, I'll play with my pinephone then! I didn't want my efforts to be wasted if I discovered some horrible security hole that I would find as distracting as this obvious huge elephant in the room > The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. I do not believe this is a likely problem. And even if it was, "not for me": I already have a few eink android Chinese devices so I'd be toast anyway, so it shouldn't influence my decision. > Qualcomm and Mediatek just have a record, today, of security flaw after security flaw. I see that and I find it concerning, so I'd rather take my chances with something I can explore, see the flaws and limit them, than something that doesn't let me do that. BTW I love how they are more flexible that US devices, letting me root and change their mtd content! Check the boox and bigme devices if you are interested in linux on baremetal color eink, yet with full control.
  - deleted 3y ago
    [deleted]
csdvrx 3y ago
The ASAN etc. are nice suggestions for parsing the OTA messages delivered over a link. It really mattered with serial links But if there's a CPU, and the link has access to the IO space, I'd prefer to first have IOMMU to avoid giving too much trust to the baseband: a takeover or exploit of whatever's parsing the messages would then be a lesser concern. Most 4G/5G modems are connected straight to the PCI bus and I believe that's far more unsafe: with no IOMMU, in case of a baseband takeover, it's game over. Old serial ports on well-known IO (ex: COM1 0x03f8, COM2 0x02f8) seem to have provided a natural checkpoint and chokepoints. Or am I missing something obvious?
- jtriangle 3y ago
  Take a few steps back, the obvious problem is that all phones are chock full of mysterious black boxes that the owner of the device has zero say over. Android has the problem of being too open to prevent backwards implementations and shitty, vulnerable, and bug prone code, but not open enough for anyone with the incentive to fix those issues to actually be allowed to fix them. I see the eventualities to be either Google locks down android significantly, and the market shifts to something more akin to Nvidia's board partner model, or, it opens way up, and device manufacturers open source their implementations of various system devices in order to crowd source fixes/improvements/etc. The former is much more likely than the latter, but, as a consumer, the latter would be preferable.
- devit 3y ago
  At least modern Google Pixel phones have an IOMMU (https://grapheneos.org/faq#baseband-isolation https://grapheneos.org/faq#baseband-isolation)
  - csdvrx 3y ago
    > A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way YES!
- 3y ago
xiipie 3y ago
All good points, but why write this in an 'open letter' style to unnamed baseband vendors? Does Google not have sufficient contact with key decision makers at Qualcomm, MediaTek, Samsung, etc. to encourage them to improve the the security of their baseband firmware? Those are the people who really need to be convinced.
- deleted 3y ago
  [deleted]
- DiabloD3 3y ago
  It isn't about "sufficient contact". Google knows exactly who to call at any of these companies, and those people will pick up the phone when they see Google is the one calling. Qualcomm actively botches the security of their products as per request of many governments. The purpose of the letter is to openly shame these companies without directly accusing them of foul play, instead of gently painting them with the brush of mere incompetence, mere lack of knowledge how modern tooling works.
  - xiipie 3y ago
    > Qualcomm actively botches the security of their products as per request of many governments. Interesting, I was not aware that's what they're doing. Is there evidence of this?
    - avidiax 3y ago
      I doubt there's publicly available evidence. Assuming incompetence before malice, I'd say that Qualcomm and the other 5G baseband manufacturers have such a moat around cellular modems that it doesn't need to be secure. It's not a competitive advantage. A security critical application simply assumes that the network and the 5G baseband are compromised.
      - jjav 3y ago
        I have no idea how the bugs ends up where they end up. I remember a pretty egregious mis-implementation in a qualcomm rsa encryption module many startups ago when I was using that, I never heard back about the bug report. That was over a decade ago so surely it's fixed by now I guess. I guess?
therealmarv 3y ago
Guessing the Tensor G1..3 based Android phones are not affected by 5Ghoul? https://asset-group.github.io/disclosures/5ghoul/ https://asset-group.github.io/disclosures/5ghoul/
- ksjskskskkk 3y ago
  it probably is, but you won't get the usual academic work for free as you get with more common platforms.
- mschuster91 3y ago
  The Pixel lineup uses Samsung modems.
acaloiar 3y ago
For those who don't eat and breathe this stuff, "basebands" are the processors that do all the cellular radio stuff on your smartphone. They're separate from device CPUs (referred to as the Application Processor), and are loaded with firmware. This post is about securing the firmware that runs on these little processors. When baseband firmware is compromised, it can lead to complete device compromise.
- tptacek 3y ago
  It can but doesn't necessarily, right? There's a variety of interconnect and IOMMU architectures here, so it's not a given that a baseband processor has or is one step away from unrestricted access to the whole platform.
  - csdvrx 3y ago
    it can't and it shouldn't IF IOMMUs were properly used
    - MadnessASAP 3y ago
      If I can put my paranoia cap on for a moment. The baseband processor having privileged access to the main processor may be a "feature" not a bug. It's a powerful processor, that is running constantly, has unlimited and continuous inscrutable communication with the network, is the gatekeeper for the main processors communication with the network, and it's firmware is practically required by regulations to be an opaque blob. Seems to be pretty much the ideal place for nefarious deeds.
      - csdvrx 3y ago
        > The baseband processor having privileged access to the main processor may be a "feature" not a bug yes but iff with the qualifier of "in old systems, where permissions were a tree-like state where root/uid0 could see what unpriviledged users would do - by design" It's a dated design. More separation is needed, like what was achieved for virtualization or containers (namespaces) > it's firmware is practically required by regulations to be an opaque blob That's another problem, but I think it also comes from thinking in a tree-like state system. Ideally, a device shouldn't be able to take down a well designed network: if you plug a bad appliance in your AC, it will not crash the power grub: it'll just trip a fuse.
phh 3y ago
I'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there. The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack. This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language. This is exactly what I'm doing: https://github.com/phhusson/ims https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no native code [2]. I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future. In addition to security, this allows for a lot of de-obsoleting: - It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers - I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store) - I can integrate modern voice improvements - I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful) - I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls) I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash. [1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it. [2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there. PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious. PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango https://github.com/phhusson/doubango
- 3y ago
mschuster91 3y ago
Anyone surprised by basebands being vulnerable should know these things: - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices and the Google Pixel lineup (where they also have been implicated in security [4] and battery performance [5] issues) - Qualcomm is infamous for suing anyone including Apple for patents crap, which is how this oligopoly formed in the first place, and why there's barely any competition - It's not the first time serious vulnerabilities have appeared in baseband chips [1] - and finally, to a possible cause, Qualcomm's development practices [2] are even worse than what's reported about Oracle [3], if these (anonymous) HN comments are to be believed. [1] https://www.bleepingcomputer.com/news/security/qualcomm-vulnerability-impacts-nearly-40-percent-of-all-mobile-phones/ https://www.bleepingcomputer.com/news/security/qualcomm-vuln... [2] https://news.ycombinator.com/item?id=38607205 https://news.ycombinator.com/item?id=38607205 [3] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 [4] https://www.notebookcheck.com/Google-warnt-vor-massiven-Sicherheitsluecken-im-Exynos-Modem-in-Pixel-7-Galaxy-S22-Galaxy-Watch5-und-Co.701749.0.html https://www.notebookcheck.com/Google-warnt-vor-massiven-Sich... [5] https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-life-drain https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-...
- phh 3y ago
  > - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE) Just to give a quick approximate overlook: - If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1] - If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1] - If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones - In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik. [2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware
BobbyTables2 3y ago
I feel like this article was surely written by someone who has never actually looked at cellular baseband firmware, listened to researcher’s talks, or even stayed at a Holiday Inn. Cellular hardware companies have to care first… As in NOT using crappy 32bit processors without virtual memory. Things like non-executable stacks have merit… ASLR has merit… Then, we can start yapping about compiler flags…
- deleted 3y ago
  [deleted]
rubatuga 3y ago
Or you could just use a USB cellular modem.

219 points by el_duderino 3y ago

Isn't all of this obvious for a modern C or C++ codebase? Is the state of Android baseband so bad that these are useful suggestions? Are they at least properly ring-fenced from the host CPU/RAM these days?

deleted 3y ago
[deleted]
DiabloD3 3y ago
The problem is it isn't "Android baseband", it doesn't run on the CPU that Android does at al. Instead, an entire second whole computer (not even a "microcontroller", in many cases they are just as powerful per-core as your real CPU) that runs a closed source realtime OS that Google (et al.) has zero visibility into. Some phones straight up admit the baseband is actively hostile and only communicates with it via serial (which leads to poor performance, but a secure phone). Some phones, such as any using a vanilla Qualcomm Snapdragon setup of any generation simply don't care: the baseband firmware has more holes than a slice of swiss, and the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM. This is a known attack vector used by state sponsored actors, including the US breaking into the phones of so-called "drug lords" to ease drop on them live from their own phones , without a call being active. Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship.
- csdvrx 3y ago
  > Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship. I agree. I couldn't see much of a point in the techniques discussed when there's a huge elephant in the room, and you can't fix it, so I thought I was missing something obvious. I wasn't: it's just security theater, doing something for the sake of doing something, while there's a big pink elephant in the room you should not look at: > the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM. And I can't find any valid technical reason for that elephant to be in the room. There shouldn't be limitations for accepting IOMMUs: "be liberal in what you accept and conservative in what you send" > Some phones straight up admit the baseband is actively hostile and only communicates with it via serial That looks like a fair assumption. You wouldn't have daemons listening as UID 0 on all ports, accepting then running the random binaries they get, so why would you magically assume it's ok to do the exact same but with baseband instead of a daemon? > (which leads to poor performance, but a secure phone) Can you recommend some phones? I wanted to get a better understanding of the stack so I bought an original pinephone, with the grand plan of installing arch on it (for fun!) Could it be made to work like that? A simple search only found https://www.reddit.com/r/pinephone/comments/har9aj/pine_phone_and_graphen_os/ https://www.reddit.com/r/pinephone/comments/har9aj/pine_phon... which concludes with "I don't think the Pinephone can provide any of the security requirements of Graphene OS ( iommu isolation etc )" What should I buy to explore the concept of IOMMUs on cellphones?
  - galangalalgol 3y ago
    Graphene recommends a modern pixel. If they can properly restrict memory access on those phones and the baseband doesn't have any direct access to the mic via analog signal or similar, then it probably can't listen in on either incoming or outgoing communication, that should all be encrypted before it hits the memory right? You could still be located and identified, but they don't need to compromise your baseband for that.
    - chislobog 3y ago
      This could be old info but I believe the Baseband chipset has its own microphone in addition to access to the user mics for the purposes of signal processing. This was a stink years ago and part of the GSMK product development. AFAIK GSMK is the only commercially available product to have a baseband firewall and their own stuff running to deal with this
  - DiabloD3 3y ago
    Arguably, any system that uses a Qualcomm SoC is not secure: either they do it on purpose, or they truly are incompetent, or it is a mix of both. No Qualcomm phone I've ever owned I've been truly happy with from the SoC SDK perspective (makes the job of community ROMs a thousand times harder). I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Allwinner and Rockchip do not have the security nightmare track record that Qualcomm does. They also ship with Postmarket instead of an Android that isn't security focused, which is nice. The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. Qualcomm and Mediatek just have a record, today, of security flaw after security flaw. The new Samsung-made SoCs in the new Pixels are also an interesting choice. They do not use the Samsung TPM, instead opting for Google's newest version of the Titan TPM. Shortly after the Pixel 6 came out, Google Project Zero issued a story about the Samsung TPM having security issues. Hmmmmmmmmmmmmmmmmmmmmmmmmm.
    - csdvrx 3y ago
      > I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Good, I'll play with my pinephone then! I didn't want my efforts to be wasted if I discovered some horrible security hole that I would find as distracting as this obvious huge elephant in the room > The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. I do not believe this is a likely problem. And even if it was, "not for me": I already have a few eink android Chinese devices so I'd be toast anyway, so it shouldn't influence my decision. > Qualcomm and Mediatek just have a record, today, of security flaw after security flaw. I see that and I find it concerning, so I'd rather take my chances with something I can explore, see the flaws and limit them, than something that doesn't let me do that. BTW I love how they are more flexible that US devices, letting me root and change their mtd content! Check the boox and bigme devices if you are interested in linux on baremetal color eink, yet with full control.
- deleted 3y ago
  [deleted]

csdvrx 3y ago

The ASAN etc. are nice suggestions for parsing the OTA messages delivered over a link. It really mattered with serial links But if there's a CPU, and the link has access to the IO space, I'd prefer to first have IOMMU to avoid giving too much trust to the baseband: a takeover or exploit of whatever's parsing the messages would then be a lesser concern. Most 4G/5G modems are connected straight to the PCI bus and I believe that's far more unsafe: with no IOMMU, in case of a baseband takeover, it's game over. Old serial ports on well-known IO (ex: COM1 0x03f8, COM2 0x02f8) seem to have provided a natural checkpoint and chokepoints. Or am I missing something obvious?

jtriangle 3y ago
Take a few steps back, the obvious problem is that all phones are chock full of mysterious black boxes that the owner of the device has zero say over. Android has the problem of being too open to prevent backwards implementations and shitty, vulnerable, and bug prone code, but not open enough for anyone with the incentive to fix those issues to actually be allowed to fix them. I see the eventualities to be either Google locks down android significantly, and the market shifts to something more akin to Nvidia's board partner model, or, it opens way up, and device manufacturers open source their implementations of various system devices in order to crowd source fixes/improvements/etc. The former is much more likely than the latter, but, as a consumer, the latter would be preferable.
devit 3y ago
At least modern Google Pixel phones have an IOMMU (https://grapheneos.org/faq#baseband-isolation https://grapheneos.org/faq#baseband-isolation)
- csdvrx 3y ago
  > A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way YES!
3y ago

xiipie 3y ago

All good points, but why write this in an 'open letter' style to unnamed baseband vendors? Does Google not have sufficient contact with key decision makers at Qualcomm, MediaTek, Samsung, etc. to encourage them to improve the the security of their baseband firmware? Those are the people who really need to be convinced.

deleted 3y ago
[deleted]
DiabloD3 3y ago
It isn't about "sufficient contact". Google knows exactly who to call at any of these companies, and those people will pick up the phone when they see Google is the one calling. Qualcomm actively botches the security of their products as per request of many governments. The purpose of the letter is to openly shame these companies without directly accusing them of foul play, instead of gently painting them with the brush of mere incompetence, mere lack of knowledge how modern tooling works.
- xiipie 3y ago
  > Qualcomm actively botches the security of their products as per request of many governments. Interesting, I was not aware that's what they're doing. Is there evidence of this?
  - avidiax 3y ago
    I doubt there's publicly available evidence. Assuming incompetence before malice, I'd say that Qualcomm and the other 5G baseband manufacturers have such a moat around cellular modems that it doesn't need to be secure. It's not a competitive advantage. A security critical application simply assumes that the network and the 5G baseband are compromised.
    - jjav 3y ago
      I have no idea how the bugs ends up where they end up. I remember a pretty egregious mis-implementation in a qualcomm rsa encryption module many startups ago when I was using that, I never heard back about the bug report. That was over a decade ago so surely it's fixed by now I guess. I guess?

therealmarv 3y ago

Guessing the Tensor G1..3 based Android phones are not affected by 5Ghoul? https://asset-group.github.io/disclosures/5ghoul/ https://asset-group.github.io/disclosures/5ghoul/

ksjskskskkk 3y ago
it probably is, but you won't get the usual academic work for free as you get with more common platforms.
mschuster91 3y ago
The Pixel lineup uses Samsung modems.

acaloiar 3y ago

For those who don't eat and breathe this stuff, "basebands" are the processors that do all the cellular radio stuff on your smartphone. They're separate from device CPUs (referred to as the Application Processor), and are loaded with firmware. This post is about securing the firmware that runs on these little processors. When baseband firmware is compromised, it can lead to complete device compromise.

tptacek 3y ago
It can but doesn't necessarily, right? There's a variety of interconnect and IOMMU architectures here, so it's not a given that a baseband processor has or is one step away from unrestricted access to the whole platform.
- csdvrx 3y ago
  it can't and it shouldn't IF IOMMUs were properly used
  - MadnessASAP 3y ago
    If I can put my paranoia cap on for a moment. The baseband processor having privileged access to the main processor may be a "feature" not a bug. It's a powerful processor, that is running constantly, has unlimited and continuous inscrutable communication with the network, is the gatekeeper for the main processors communication with the network, and it's firmware is practically required by regulations to be an opaque blob. Seems to be pretty much the ideal place for nefarious deeds.
    - csdvrx 3y ago
      > The baseband processor having privileged access to the main processor may be a "feature" not a bug yes but iff with the qualifier of "in old systems, where permissions were a tree-like state where root/uid0 could see what unpriviledged users would do - by design" It's a dated design. More separation is needed, like what was achieved for virtualization or containers (namespaces) > it's firmware is practically required by regulations to be an opaque blob That's another problem, but I think it also comes from thinking in a tree-like state system. Ideally, a device shouldn't be able to take down a well designed network: if you plug a bad appliance in your AC, it will not crash the power grub: it'll just trip a fuse.

phh 3y ago

I'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there. The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack. This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language. This is exactly what I'm doing: https://github.com/phhusson/ims https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no native code [2]. I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future. In addition to security, this allows for a lot of de-obsoleting: - It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers - I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store) - I can integrate modern voice improvements - I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful) - I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls) I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash. [1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it. [2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there. PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious. PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango https://github.com/phhusson/doubango

3y ago

mschuster91 3y ago

Anyone surprised by basebands being vulnerable should know these things: - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices and the Google Pixel lineup (where they also have been implicated in security [4] and battery performance [5] issues) - Qualcomm is infamous for suing anyone including Apple for patents crap, which is how this oligopoly formed in the first place, and why there's barely any competition - It's not the first time serious vulnerabilities have appeared in baseband chips [1] - and finally, to a possible cause, Qualcomm's development practices [2] are even worse than what's reported about Oracle [3], if these (anonymous) HN comments are to be believed. [1] https://www.bleepingcomputer.com/news/security/qualcomm-vulnerability-impacts-nearly-40-percent-of-all-mobile-phones/ https://www.bleepingcomputer.com/news/security/qualcomm-vuln... [2] https://news.ycombinator.com/item?id=38607205 https://news.ycombinator.com/item?id=38607205 [3] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 [4] https://www.notebookcheck.com/Google-warnt-vor-massiven-Sicherheitsluecken-im-Exynos-Modem-in-Pixel-7-Galaxy-S22-Galaxy-Watch5-und-Co.701749.0.html https://www.notebookcheck.com/Google-warnt-vor-massiven-Sich... [5] https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-life-drain https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-...

phh 3y ago
> - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE) Just to give a quick approximate overlook: - If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1] - If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1] - If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones - In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik. [2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware

BobbyTables2 3y ago

I feel like this article was surely written by someone who has never actually looked at cellular baseband firmware, listened to researcher’s talks, or even stayed at a Holiday Inn. Cellular hardware companies have to care first… As in NOT using crappy 32bit processors without virtual memory. Things like non-executable stacks have merit… ASLR has merit… Then, we can start yapping about compiler flags…

deleted 3y ago
[deleted]

rubatuga 3y ago

Or you could just use a USB cellular modem.