5

There is a chipset I am working with that utilizes an ARM cortex -A7 as the Application processor and an ARM 9 Baseband processor.

I had a major concern since the ARM cortex A7 is utilizing android that the MPU and/or MMU could be subverted to see the whole DRAM which includes the ARM9 side as well. Although the architecture seems to suggest they are utilizing an MPU my concern is that the since the android kernel can be subverted that the MPU could be reconfigured at runtime to remove the restrictions. The concern is not just that the Android kernel of this embedded device could be rooted but that privileged escalation could occur so that a kernel process at runtime could modify the MPU registers (i am guessing). Although these processors do have trustzone however nothing out of the chipset has been created which means that there is no concept of NSbit to delineate between secure vs non secure world.

What kinds of vulnerabilities i could be looking at and if my concerns are legit? lastly, the device has secure boot but its the Applications processor side that I have serious concerns about and of course in runtime. Any help with potential vulnerabilities and/or solutions would be appreciated.

Ebenezar John Paul
  • 2,884
  • 16
  • 23
Dave Powell
  • 151
  • 3
  • So, to be clear, you're worried about a threat model where an attacker that has gained kernel code execution? At that point is there really a question as to whether they've owned the device? Or are you more worried about them overwriting baseband firmware that exists outside of the kernel? – Polynomial Oct 16 '13 at 13:02
  • Kernel code execution is just one aspect but yes. The baseband is separated with its own micro kernel which is not open source and thus secure. The main concern is with regards to baseband firmware and operations and thus I have to think about how the assets be peripherals (ram,flash,data as well as bus maters and slaves, system registers ) could get subverted. One glaring issue is the one of subverting android kernel (ring0 access) and then modifying the Mpu/MMU to see ARM9 operations in external dram. Ownership is not an issue. Point is if I put company IP on this device will it compromised – Dave Powell Oct 16 '13 at 14:32

1 Answers1

1

All the SoC's I've seen with this configuration have handled this situation by having MPU registers only writable from the "secure" baseband processor or from within TrustZone. As you wrote it's virtually impossible to keep the application world from getting hacked/rooted, but as long as the MPU(s) cannot be reconfigured from the Linux kernel then you still have reasonable protection. I don't agree with the statement that the non-opensource micro kernel would be any more secure though - plenty of vulnerabilities in baseband code...

Edit: I haven't worked with the Qualcomm MSM8x10/8x12 (Snapdragon 200 family) specifically but the architecture looks very familiar to the more powerful Snapdragon 400/600/800 chips with xPUs (Protection Units) all over the place (protecting memories and peripherals).

Also I would be very surprised if the NS-bit isn't respected (it is dealt with in all other Snapdragon SoCs I've worked with). The details of the security solution is something that Qualcomm will have to disclose to you through the normal support channels though.

As far as attack vectors go there have been a lot of different approaches, everything from utilizing JTAG interfaces that people forgot to disable to very advanced attacks on the low level software. In the end it all depends on how interesting of a target your application is - cellphones have traditionally been a high-value target where people are trying to gain access to the baseband to change the SIM-lock and/or the IMEI/MEID number. Most hackers these days are more concerned about gaining full access to the application side (rooting), so as long as you're not making that too difficult hopefully they will leave you baseband alone.

If the security has been set up correctly then obtaining access to the TrustZone Trusted Execution Environment (TEE) memory on the application side and access to the baseband memory should be very difficult from the non-secure world. There's no way the chipset will be approved for the more serious DRM schemes if this wasn't the case.

wj.
  • 23
  • 4
  • I am considering a qualcomm 8x10/8x12 chipset. however, I would be interested in what attack vectors you are aware of that I might consider or if you know a place where I can look up these kinds/types of attack vectors? I intend to place the company IP still on the BB (baseband). From a chipset standpoint It seems that BB is running in it own TEE. TrustZone itself which only runs on the AP side only needs to be configured such that it should not access the BB. – Dave Powell Jan 14 '14 at 13:28
  • Expanded the original answer with a bit more chipset information – wj. Jan 15 '14 at 02:02
  • I think that is exactly it right. how should security be setup in an embedded mobile device from the H/W config to the SW config etc. I think I am trying to do – Dave Powell Jan 16 '14 at 05:53
  • I think that is exactly it right. how should security be setup in an embedded mobile device from the H/W config to the SW config etc. I think I am trying to do due diligence and in doing that trying to figure out if there are any standard bodies that can help with security attack vectors depending on the surface to at least cover those basis and validate that through testing. So for example, issue like where recently there were issues with moto unlock boot loader implemented in TZ is a example of how issues can crop up. – Dave Powell Jan 16 '14 at 15:31
  • Yeah, the moto issue was an unfortunate one for multiple reasons. I believe the logic of that QFuse was reversed in the first place, it should have been fused on the non-dev units so the only way you would go is from unfused to fused during production to disable the dev mode (and left unfused on the dev devices). The other broken part was that not enough validation was performed on untrusted input into TZ. – wj. Jan 17 '14 at 04:13
  • Thus, the issue of figuring out where I can get guidance in terms of maybe standardized bodies which can provide attack vectors in terms of embedded devices which can also apply to mobile devices etc. I am just not sure if anyone here is knowledgeable either in standards for embedded security or otherwise to help. I wonder if there are any people on this site who know where i can go and check for example a db of attack vectors concerning embedded devices. These could be generic but at least I can get some kind of solid direction for testing/validation purposes. – Dave Powell Jan 18 '14 at 01:07