Code execution as root via AT commands on the Quectel EG25-G modem (2021)(nns.ee)
nns.ee
Code execution as root via AT commands on the Quectel EG25-G modem (2021)
https://nns.ee/blog/2021/04/03/modem-rce.html
9 comments
Would it be feasible to power off the ARM core on the modem and do everything from the main PinePhone ARM SoC?
I think the ARM core on that is pretty weak even compared to the A64 (and certainly compared to the RK3399 of the PPP!). So while possible, I think it is pretty infeasible. That and I think everything is wired to the main CPU anyways.
Has anyone looked at the ADSP firmware part of the modem?
Aside from clean room reverse engineering, I do not think there is anyway to actually replace that. One can wipe and reformat the ADSP, but to my knowledge, if the source code is out there, it is certainly leaed proprietary source code.
Fun fact! Earlier versions of the Quectel modem firmwares supported a more direct method for running code as root:
AT+QLINUXCMD="/sbin/reboot"(Published September 2021)
03/04/2021 - Attempted to contact vendor
13/04/2021 - Vendor confirmed vulnerability
23/04/2021 - Vendor issued $2,000 bounty
24/04/2021 - Assigned ID CVE-2021-31698
08/09/2021 - Write-up published
Quectel, not Qualcomm.
Of course Pine has to treat it as unfixable -- the modem is already an untrusted component out of the box, and the FCC (and peers) would never allow Pine to ship their own modem firmware.
Of course Pine has to treat it as unfixable -- the modem is already an untrusted component out of the box, and the FCC (and peers) would never allow Pine to ship their own modem firmware.
The first thing I do on new Quectel firmware is the check with Ghidra. I don't use the insecure Linux modems, just the baremetal modems. Which are actually 2 CPU's with 2 firmwares. The modem itself is either a Broadcom or Qualcomm RF chip with all those AT commands and its completely insecure AT parsing via internal UART. The main CPU is best used baremetal, which is much more secure and needs much less energy than the Linux variants. I fixed dozens of security issues in their SDK, but still prefer it over STM, Atmel or Raspi.
So you can finally own your modem? I'd consider this a feature. Shame that someone's going to patch it now..
You could already do that on this particular modem; the author's previous post (linked from the first paragraph here) involves running a lot of arbitrary code on the modem, and there's an entire alternative implementation running around (https://news.ycombinator.com/item?id=30301837 discusses it a bit). This just talks about running arbitrary commands specifically through the AT interface on the stock firmware.
You and everyone else can own your modem. I'd rather someone not be able to install an undetectable rootkit on my phone with nothing more than an AT command...
Can you even run AT commands without already having privileged access on the phone?
I'm honestly not sure (I haven't played with modems much), but I do know that doing a clean wipe of the eMMC or an SD card is way easier than a clean wipe of your modem. It's also a fair bit harder to check for anomalous activity, although with easier shell access, maybe that mitigates both problems?
To be clear, I think it's a lose/lose situation, because I want access to the modem in my pinephone, but I'd rather shell access require some kind of physical attestation (serial connection over the pogopins or something), instead of ... this.
To be clear, I think it's a lose/lose situation, because I want access to the modem in my pinephone, but I'd rather shell access require some kind of physical attestation (serial connection over the pogopins or something), instead of ... this.
I believe the Bluetooth Serial Port Profile supports AT commands, and I've seen phones connect to bluetooth devices while locked... so...
...so nothing of substance is hiding there, because AT commands from Bluetooth peripherals have no way to reach the modem (they just happen to speak same-ish language the modem does).
This is certainly interesting from a vulnerability perspective - and hats off for the effort. But there's still `adb shell`, so it feels a bit like picking the lock when the front door is wide open.
For those with just the module, I believe at least some of these modems also have a root shell TTY exposed over RS232 on pins 11 & 12. (https://osmocom.org/projects/quectel-modems/wiki/EC25)
For those with just the module, I believe at least some of these modems also have a root shell TTY exposed over RS232 on pins 11 & 12. (https://osmocom.org/projects/quectel-modems/wiki/EC25)
This, exactly. I work with similar modems daily. The first thing I do is to run the AT command for enabling adb. From there you can do whatever. The modems are quite beefy, 100s MB of RAM and multiple CPU cores. They even come pre-installed with a http server, ftp client, ALSA and much more.
Also, if you really want to get creative, I think you can just dump the firmware, which is just normal Linux. So just dump it, mount the filesystem and make whatever changes you want then re-flash.
The quality and security of the software in these things is absolutely bottom tier.
Also, if you really want to get creative, I think you can just dump the firmware, which is just normal Linux. So just dump it, mount the filesystem and make whatever changes you want then re-flash.
The quality and security of the software in these things is absolutely bottom tier.
Do they need all that power? Sounds like it's more of an SoC with a modem than just a modem. Why then have another processor?
The market for cellular modules is very competitive. From a time to market point of view is cheaper and faster to reuse smartphone-grade socs instead of reinventing the wheel.
As far as I know, only u-blox is producing their own SoC (albeit for cat-m/nb-iot only) all the others are using existing solutions from Qualcomm and others.
This is only scratching the surface. I did not talk about certification which is another beast altogether.
As far as I know, only u-blox is producing their own SoC (albeit for cat-m/nb-iot only) all the others are using existing solutions from Qualcomm and others.
This is only scratching the surface. I did not talk about certification which is another beast altogether.
If you had to implement secure 4G/5G in an embedded environment, which hardware or approach would you reach for?
I guess the proper takeaway is each time you load a new booty to the phone, make a point of reflashing the modem as well?
[deleted]
oh that's fun, but it's pretty common on even commercial qualcomm phones, especially xiaomi/huawei where you can force the modem/baseband to have a com port/debug port.
This looks like a feature, why the agitation?
https://github.com/Biktorgj/pinephone_modem_sdk/releases
It still uses the ADSP from Quectel, but from my usage (and from other's reports), it is FAR more stable than the stock firmware. It is also immune to this vunerability (I don't even think it has atfwd_daemon).