Over the past week, I have been exploring the concept of extending the KERNELFAULT attack to use EMFI, with some success, in the context of setting up further attacks against other targets.
The key questions to answer for me were as follows:
- By nature, the transient EM pulse must be an order of magnitude shorter than the crowbar glitch employed previously. What does this look like in practice?
- Is the fault model consistent – are we still encountering the same kind of program corruption as we experienced previously, or are there new faults to deal with?
- Where are the most vulnerable locations above (or below!) the Broadcom SoC? What effect does different coil configuration have?
This exercised used a ChipSHOUTER and a ChipWhisperer-Lite running a simple counting loop as a timer. The same trigger program was used as the KERNELFAULT experiments – no modification was needed.
An afternoon of brute forcing led us to a successful result:
- The pulse length is significantly shorter than the previous use case, indicating (as expected) that the impact of decoupling capacitors is greatly reduced or removed in this scenario.
- The fault model was consistent, the same type of crashes was occurring whether I’m VCC glitching or using EMFI.
From a positioning perspective, I noted a different result to Trouchkine et al’s paper (here):
This could be due to a difference in coil selection / manufacturing imperfection in the coil, or maybe it was wind pushing the board slightly. After watching some of Colin O’flynn’s work, I’ve purchased a Panavise clamp to hold the target in place, so I can open a window and not impact the results in future.
No testing has yet been done on the effect of coil choice, but I expect this to have a similar impact to moving the position of the coil: the shape and direction of the generated magnetic field would differ, so naturally, the results would too.
Some improvements were made to the classification script, which can help us identify where the successful glitches are occuring (red diamond marks indicating where code is executing down the commit_creds path – there’s some missing “bad crashes” here to remove clutter):
Interestingly, I was able to force execution down the commit_creds path when glitching using an ext_offset of approximately 200 (same as the VCC glitching experiment which previously succeeded), but was unable to wrangle this into a successful privilege escalation (crashes in commit_creds: I suspect this timing represents a before-and-after of the ns_capable_setid call in sys_setresuid.
This experiment required minimal code changes, everything is in Github here in the experiments/pi folder.
Much, much more work is to be done here, and I look forward to extending the attack against other complex SoC’s.