[HN Gopher] Glitching a microcontroller to unlock the bootloader
___________________________________________________________________
Glitching a microcontroller to unlock the bootloader
Author : Graziano_M
Score : 70 points
Date : 2023-01-17 16:14 UTC (6 hours ago)
(HTM) web link (grazfather.github.io)
(TXT) w3m dump (grazfather.github.io)
| ur-whale wrote:
| Glitching attacks are very cool, and I've never seen formal
| security research explaining how to defend against them.
|
| Has anyone?
| kragen wrote:
| the problem is that glitching attacks target the specification
| approach that engineering has been based on for at least a
| century, where the vendor promises that if their component is
| operated under some set of nominal operating conditions, it
| will perform within some nominal performance range, but
| promises nothing about what will happen if operated under some
| other conditions, or where its performance will lie within that
| range
|
| a bolt, for example, will have tensile strength and pitch
| diameter within a certain specified range as long as the
| temperature is within some given range (and it hasn't
| previously been exposed to excessive stress or temperature),
| and a resistor will have its resistance, temporal drift,
| physical dimensions, inductance, etc., within a certain
| specified range as long as the temperature is within some given
| range and it hasn't been previously overheated
|
| the specifications for a microcontroller sometimes run to
| thousands of pages
|
| vendors are free to include other features not documented in
| the spec, such as undisclosed debug ports, and to switch from
| one supplier to another whenever they like as long as the
| product still meets the spec
|
| in glitching attacks the attacker operates the components
| outside their nominal ranges, where the vendor offers you no
| guarantees of what will happen. higher clock speeds, shorter
| write times, lower voltages, higher temperatures, shorter setup
| and hold times, etc. even if one vendor does try to offer such
| guarantees, generally their product includes parts and
| processes sourced from other vendors who don't
|
| so i don't think it's yet something you can define crisply
| enough to mount a general defense; glitching attacks are
| enabled by a social system that creates new vulnerabilities
| much more rapidly than they are closed
| picture wrote:
| To add on, there are a good amount of effort put in to
| defending against side channel attacks, including hardware IP
| like [1]. However, it's not a winnable game when your
| adversary has access to your hardware. If they're determined
| enough, they can use SEM microscopes and expensive equipment
| to physically rewire your chip, bypassing circuitry
| arbitrarily.
|
| [1] https://www.agileanalog.com/ip-by-product-
| type/agilevglitch-...
| Kirby64 wrote:
| The simple example in the article is demonstrated: you have a
| fail safe condition, not a fail open condition. Since you only
| need to flip one bit, unlocking the bootloader is trivial. If
| you need to flip multiple bits, in a specific pattern, this
| makes the challenge exponentially more difficult.
|
| For something like the reset glitch hack on the Xbox 360, for
| example, they were glitching a single opcode to do the compare
| with the checksum. Multiple ways to defend/harden against that
| attack (which, likely, were implemented on the Xbox One).
| jesprenj wrote:
| As also mentioned in the article, the glitch could've
| affected the branching or comparison part of the code, so you
| may still be able to glitch a chip with the proposed
| solution.
| Graziano_M wrote:
| Another tactic is to run the check a bunch of times, maybe in
| parallel. If any of them don't match then assume locked or
| halt. Getting multiple glitches to each hit each check in the
| same way is very difficult.
|
| Literally something like if
| (read_flash(0xdeadbeef) != 0x1234) { count += 1;
| } if (read_flash(0xdeadbeef) != 0x1234) {
| count += 1; } ...
|
| but of course, then you have to worry about how `count` is
| being checked.
| rtkwe wrote:
| Quick search turns up this research paper that talks about
| glitch defense in software. It's a tough attack to completely
| mitigate just because it attacks the hardware directly but the
| timing is extremely difficult to hit even without active
| defenses so some basic fixes might be able to make the attack
| functionally unworkable just due to the difficulty of
| successfully executing it even if the underlying issue
| persists.
| rtkwe wrote:
| I completely forgot to actually link the paper I was talking
| about: https://sites.cs.ucsb.edu/~vigna/publications/2021_DSN
| _Glitc...
| jnwatson wrote:
| 1. Check more than 1 bit. 2. Add glitching detection circuitry.
| 3. Randomize when you do the check.
| FatActor wrote:
| a solution has been around for ages: lockstep processors.
|
| https://www.microcontrollertips.com/dual-core-lockstep-proce...
|
| https://www.synopsys.com/designware-ip/processor-solutions/a...
| snvzz wrote:
| I'm confused. Don't iCE40 have a PLL?
|
| I do not have that specific devboard, but I've run designs at
| ~70MHz.
| Graziano_M wrote:
| It does, and I mentioned that I tried to use it but had issues,
| so I got it to work at its default clock rate.
| snvzz wrote:
| Intuitively, I suspect running everything with the PLL clock
| would have been best, as crossing clock domains is itself a
| source of pains.
|
| Also, I'd ensure I feed the clock network with the PLL
| output. Not using the clock network is also a potential
| source of issues.
___________________________________________________________________
(page generated 2023-01-17 23:00 UTC)