[HN Gopher] Robot can rip the data out of RAM chips
___________________________________________________________________
Robot can rip the data out of RAM chips
Author : laktak
Score : 112 points
Date : 2023-06-09 06:30 UTC (2 days ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| jhalderm wrote:
| Incredibly "cool"! The physical-chip-swapping version of the
| cold-boot attack is extremely general, but it's always been very
| labor intensive--that's why automation like this could be a game
| changer.
|
| Here are some photos from our original experiments 15 years ago,
| to help you picture what's involved in doing these attacks
| manually:
|
| https://web.archive.org/web/20080225131822/http://citp.princ...
|
| Needless to say, our setup (and approach to lab safety) was
| rather privative by today's standards:
|
| https://web.archive.org/web/20100616201843/http://citp.princ...
| coppsilgold wrote:
| AMD Ryzen Pro CPUs have a memory encryption feature (SME):
| <https://www.amd.com/system/files/documents/amd-memory-guard-...>
|
| It may require to have support from the motherboard.
|
| EFI firmware has a var (/sys/firmware/efi/efivars/) named
| MemoryOverwriteRequestControl that if set is _supposed_ to
| instruct the firmware to overwrite memory on next boot. If you
| set it and if you can somehow trigger a reboot memory should not
| be recoverable.
|
| You can also set init_on_free=1 in linux cmdline, the kernel will
| overwrite freed memory. If a reboot is physically interrupted or
| if the EFI firmware does not honor the var mentioned above,
| encryption keys and any other private data may have been freed.
| mabbo wrote:
| Must be 25 years ago now I was chatting with a family friend, my
| friends dad, and he told me roughly what it was that he does:
|
| "If I have physical access to your computer, I can probably get
| whatever data you have off of it". It was the first time I had
| even heard of computer security as a concept.
|
| I don't know precisely what methods he was using back then (it
| was the 90s) but he was dead serious.
|
| The point he made has become more and more true over time:
| Whoever can touch the machine, you presume they have better
| access than the admin.
| remh wrote:
| 25 years ago it would be very unlikely for your hard drive to
| be encrypted. So you could just take the hard drive and read it
| direct ly.
| fbdab103 wrote:
| I do not think that holds up today. While there do still exist
| a wide variety of unsecured vectors, those are closing rapidly.
| Look at any of the closed hardware platforms (Xbox,
| Playstation, iPhone, TPM, etc). People with strong desires to
| exfiltrate data are stymied.
| HWR_14 wrote:
| While people with strong desires are stymied, I wouldn't
| trust any of those systems against a motivated nation-state.
| iudqnolq wrote:
| It's not that simple. Everything, even secure hardware, can
| have bugs. https://www.washingtonpost.com/technology/2021/04/
| 14/azimuth...
| tpmx wrote:
| Paper: https://wootconference.org/papers/woot23-paper3.pdf
| tpmx wrote:
| And slides:
|
| https://wootconference.org/slides/3-Cryo-Mechanical_Memory_E...
| bsder wrote:
| Thank you for this!
|
| The whole thing hinges on the elastomeric sockets and I had no
| idea what they were talking about until you referenced the
| paper.
|
| Those sockets are _mega_ cool. I need to go down the rabbit
| hole of those for a while.
| chongli wrote:
| Why not build a thermocouple into the RAM package and program the
| operating system to overwrite memory with random data on
| detection of a sudden temperature drop?
| bri3d wrote:
| Using the OS to do this is unlikely to be effective; the
| attacker with this access could usually halt the CPU before
| they remove RAM. As in the article, the best mitigation against
| this kind of attack is memory encryption, either in hardware or
| software (although in software, you have to figure out how to
| keep your keys out of RAM).
|
| There are security oriented ICs of various types (flash, RAM,
| secure element) which do clear data with a tripwire in a lot of
| ways; some even have onboard current storage of some kind which
| allows them to clear all data as a "dying breath" when the
| package is tampered with. But COTS DDR RAM needs to be cheap
| and doesn't usually have this kind of threat model.
| josephg wrote:
| > although in software, you have to figure out how to keep
| your keys out of RAM
|
| I think you can do this with modern "trusted computing"
| modules.
| brookst wrote:
| How much more would you pay for hardware with this extra
| protection against you hacking it?
| chongli wrote:
| I'm not important enough to be a target of this attack in the
| first place!
| mhh__ wrote:
| Money
| [deleted]
| the8472 wrote:
| That's still a reactive defense. A safer approach is to encrypt
| the data and keep the keys in the CPU, which is what TME
| (intel) and SME (amd) do. The downside is some added latency,
| power consumption and die area.
| adhesive_wombat wrote:
| You can also pot the PCB, and/or enclose it in a physically
| secure enclave where if it detects ambient light, actuation of
| a switch, breach of a conductive trace embedded in the case
| around it, etc, it wipes the RAM and, depending on your
| paranoia levels, blows the hardware up. Some key management
| Hardware Security Modules do this.
|
| Also this:
| https://en.wikipedia.org/wiki/Harvey's_Resort_Hotel_bombing
|
| The designer could probably have made more cash patenting his
| systems!
| peter_d_sherman wrote:
| Here's an interesting line from this article:
|
| >They also conducted a similarly successful attack on DDR3 DRAM
| in a CISCO IP Phone 8800 series to access the runtime ARM
| TrustZone memory.
|
| Generic Pattern/Idea expressed in above statement:
|
| a) _IF_ a given CPU implements a security processor (i.e., Intel
| Management Engine, AMD PSP, Apple Secure Enclave, an ARM security
| coprocessor, etc.) then:
|
| b) _IF_ that security processor uses a small part of physical RAM
| of the computer it is in for its activities, and that physical
| RAM, during those activities is inaccessible to programs, OS 'es
| and Hypervisors alike, then:
|
| c) It _may_ still be possible to get a memory dump of that
| protected subsection of RAM during those activities by one or
| more methods, including (but not limited to!) the physical
| freezing /robotic extraction of the RAM...
|
| I would suggest that if point-in-time RAM extraction were the
| desired goal (and it apparently is) -- that it might be far
| simpler to use an FPGA connected to appropriate RAM and have that
| device _emulate_ aka _proxy_ (via signal paths) the device 's RAM
| from which data is to be extracted from...
|
| Also... prediction: Future RAM will be built such that it can be
| easily proxied/tapped/tee'd/traced/interposed by third party
| hardware devices... That is, future RAM interconnect signal paths
| will be intentionally engineered for that purpose...
|
| In future computers, CPU, memory and all devices will be modular;
| where all interlinking signal paths could be
| proxied/tapped/tee'd/traced/interposed by third party hardware
| devices...
|
| Think of it this way; what the original IBM-PC did for computing
| of the era (open the bus, open the backplane to accept 3rd party
| expansion cards) -- should be done between every possible set of
| electronic components in future PC's/computing devices...
| bogantech wrote:
| Anyone know how the memory chips are removed from the target
| board? They can't be desoldering them if it's a cryogenic process
| bri3d wrote:
| It's in the article, they're desoldered and reballed like
| normal and then socketed: "What makes the attack possible, he
| said, is something called a conductive elastomer IC test
| socket." The cryogenic pick and place robot then moves the now-
| socketed chip from the board to the test fixture at runtime.
| imtringued wrote:
| This is ridiculous. You need to steal the hardware, analyse
| the specific model, build a machine for it and manipulate it
| and then bring it back to the original user and then steal it
| again after he has entered his credentials and then you have
| to use a dedicated machine to perform the actual attack and
| you only have one attempt.
| ilyt wrote:
| If it is a laptop, yeah, not super practical, but there are
| plenty of devices secured by encrypted firmware that gets
| decoded on boot and stored in memory
| wongarsu wrote:
| Yeah, way more practical for servers in a datacenter than
| for a random laptop you confiscated. Though tooling for
| each of the most recent iPhones might also be worth it
| adhesive_wombat wrote:
| The elastomeric sockets are really cool. They're like 2D
| versions of those zebra connectors for LCDs: you just press
| them down and the land pattern is replicated on the other
| side. Furthermore, they work into the GHz range, which you
| need, say, for messing with modern DDR RAM standards.
|
| https://www.ironwoodelectronics.com/products/ghz-
| elastomer-s...
| aa-jv wrote:
| Get things cold enough and you can pop off most BGA-based
| packages from the boards ..
| colanderman wrote:
| What is the advantage of this vs. some sort of "go-between"
| module which mirrors all RAM traffic to an external device?
| frabert wrote:
| You probably can't do that without screwing up the signal
| integrity
| javajosh wrote:
| Isn't the solution to make it very hard to remove the ram without
| destroying it? Like, epoxy it onto the motherboard?
| userbinator wrote:
| _A lot of the critical infrastructure embedded things that we
| depend on, almost none of them are addressing this kind of
| attack_
|
| Because it's beyond impractical and to attempt to "defend"
| against such things is effectively fighting against the base
| principles of (physical) property ownership?
|
| The direction that "security" research has headed in is really
| disturbing.
| bick_nyers wrote:
| Sounds like a use case for a BIC (Bomb-In-Chip) implementation.
| bsder wrote:
| Not at all.
|
| If I am forced to surrender my phone at a border crossing, for
| example, I would like to know that the fact I powered it off is
| sufficient to deter these kinds of attacks.
|
| It's relatively easy to thwart this attack--the CPU only sends
| encrypted data to external memory chips. The devil is in the
| implementation--encryption adds latency to memory access.
| ars wrote:
| You have neglected the man with a big gun security hole.
|
| Do I need to link to the XKCD comic?
| oceanplexian wrote:
| I think this makes sense, if only because physical property
| ownership has always been an illusion.
|
| You don't really "own" anything as long as someone with a badge
| and a gun can break down your door and take it from you. I
| don't care if you live in a democracy or a dictatorship, it
| happens in both.
|
| Encrypted information, on the other hand, can theoretically be
| "owned" if it's implemented correctly. No police, no court or
| law, no government, nothing can take your encrypted digital
| property from you. It's probably the most real manifestation of
| property humans have ever come up with.
| drones wrote:
| I thought ram chips had volatile memory. As soon as it loses
| power it effectively wipes all data, no? How does the physical
| removal process preserve the contents? Are modern RAM chips not
| volatile anymore?
| kiicia wrote:
| No, physical attacks are possible for many years now. They just
| require very high manual skill level. Ram chips must be
| immediately (as fast as possible after power goes down in case
| you don't have control over when computer loses power) frozen
| by liquid gas and then moved into ram-reading jig.
| hultner wrote:
| Or you know a can of bottled air upside down and a bootable
| usb will do it unless the efi is locked down and USB-boot
| disabled, in that case you also need to move it over to your
| own laptop.
| tenebrisalietum wrote:
| I remember switching my Commodore 64 off and on rapidly while
| it was displaying something on the bitmap graphic screen. The
| system would reset, but you could enable graphic mode and see
| 90% of what was there.
| dhx wrote:
| At normal DRAM module operating temperatures and assuming you
| want to stick to JEDEC specifications, retention times may
| typically be 50uS[1]. This low number is due to the standard
| having an extremely low tolerance for errors, and the
| inevitable problem of some MOS transistors/capacitors (a cell)
| being defective and having a much higher leakage rate than
| typical cells. Hence the standard has to cater for the weakest
| cell due to the extremely low tolerance for errors.
|
| In [2], the authors used readily available compressed gas[3] to
| chill (probably to approx -50oC) DDR1 and DDR2 DRAM modules
| during operation, then whilst the DRAM modules remained
| chilled, cut power to the computer, waited a period of time and
| then read out the DRAM module data for comparison. With power
| cut for 10 minutes, a read error rate of just 36 bytes per
| megabyte was observed. This increased to an error rate of 1700
| bytes per megabyte at 60 minutes when chilling to a lower
| temperature using LN2.
|
| The authors of [2] tested DDR1 and DDR2 DRAM retention without
| use of cooling, and results varied between different DRAM
| modules (different sense amplifiers, different MOS
| transistor/capacitor fabrication methods, different DRAM module
| heatsink designs, etc) but generally it showed 5 minutes
| unpowered would generally erase all data, but some remnants
| could still remain (e.g. enough to make a faint outline out of
| a photo stored in memory).
|
| Note that like the 2008 paper[2], this paper also uses DDR1 and
| DDR2 DRAM chips. The main reason for this choice is DDR3+
| specifications and modern memory controllers implement "data
| scrambling"[4], originally not for security reasons (that's
| just a bonus side effect), but for electrical reasons to reduce
| di/dt noise on the data bus. "Data scrambling" means that data
| is XOR'd with a pseudorandom function, thus if you write
| 11111... or 00000... you'd expect on average the data bus to
| have the same average electrical characteristics. Since row
| hammer, the pseudorandom function has been improved to provide
| security against cold boot attacks. It's possible for the
| memory controller to use low-latency strong encryption such as
| ChaCha8. AMD "Memory Guard" uses AES128/NIST SP 800-90[5] and
| Intel's "Total Memory Encryption" uses AES128/256-XTS[6].
|
| [1] Page 19 (PDF),
| https://www.egr.msu.edu/classes/ece410/mason/files/Ch13.pdf
|
| [2]
| https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
|
| [3] https://en.wikipedia.org/wiki/Freeze_spray
|
| [4]
| https://web.archive.org/web/20190616183914/https://www.eecs....
|
| [5] https://www.amd.com/system/files/documents/amd-memory-
| guard-...
|
| [6] https://cdrdv2-public.intel.com/679154/multi-key-total-
| memor...
| megous wrote:
| It doesn't lose content as soon as you lose power.
|
| One fun way I saw this was when working on LCD support in a
| bootloader. You do a quick power cycle and if the framebuffer
| location is fixed in memory and you don't initialize the
| contents, you may see faded traces of the picture from previous
| boot.
| joezydeco wrote:
| In my experience that's more of a side effect from TFT
| displays. Each pixel has its own gate and can hold a charge
| for quite a long time.
|
| It can also be a side effect of older LCDs, when power is
| lost the crystal can take a long amount of time to
| depolarize. If you apply backlight you'll see an afterimage.
|
| LCDs are driven by the controller and have no knowledge of
| the framebuffer location, or even access to the host address
| and data busses. So if you see an afterimage, that's in the
| pixel.
| alufers wrote:
| They literally freeze them with liquid nitrogen, which makes
| them preserve their state.
| drones wrote:
| Huh, TIL: https://en.wikipedia.org/wiki/Cold_boot_attack
| amelius wrote:
| A RAM module should keep some power in the module to erase
| itself when the external power is lost. Or when suddenly
| the temperature drops by a lot.
| speedgoose wrote:
| An alternative is to encrypt the data.
|
| AMD calls that SME for example.
| https://www.amd.com/en/developer/sev.html
| gabeio wrote:
| (quote from link)
|
| > The key is generated by the AMD Secure Processor at
| boot.
|
| Wouldn't this key _also_ be accessible? Maybe not on the
| same _chip_ but it's still at some level in a memory chip
| somewhere, they would just need to find it?
| sneak wrote:
| It's stored inside the CPU of the secure element, in
| something like a register. Otherwise both the key and the
| ciphertext would be in the ram and the protection would
| be pointless.
| dhx wrote:
| Seemingly it'd be possible to attack an operating memory
| controller by etching with a laser, editing the circuit
| with a Focused Ion Beam (FIB) machine and putting some
| probes down to extract the key. But it's then an arms
| race with chip manufacturers who would try and bake in
| ever more sophisticated and complex tamper-detection to
| their chips.
|
| Look up Christopher Tarnovsky talks from Black Hat 2009,
| Black Hat 2010, DEF CON 20, hardwear.io 2019.
| wtallis wrote:
| Possibly, but now you have only one circuit to harden
| against such attacks, and you can continue using
| commodity DRAM ICs and modules.
| Cody-99 wrote:
| It isn't nearly as easy since the key never leaves the
| inside of the CPU. The key never goes to main memory or
| is exposed outside of the part used to encrypt/decrypt
| memory inside the CPU. Attacking a specific register
| instead the 'secure' enclave of a CPU is much harder than
| attacks like the OP where your rip out the RAM.
|
| This type of system has been used pretty successfully for
| nearly a decade on the AMD SOCs used in the XBOX
| consoles.
___________________________________________________________________
(page generated 2023-06-11 23:01 UTC)