I can’t get the full text of that, but it looks like the paper associated with the demo I was thinking of where they attacked VMs using a hair dryer on the RAM chips. The Java security model is a mess in many ways and relies on the immutability of strings in a bunch of places, so being able to flip a bit in a string can let you escape in fun ways. Without a SecurityManager installed, you can trivially call the com.sun.Unsafe things and do whatever you want, but the SecurityManager uses string comparison in a bunch of places so being able to make two identical strings have different hash codes gives a nice set of escapes.
The surprising thing was how long the system kept working even with incredibly high bit-error rates. It turns out that nothing really cares about most of the contents of memory.
Far be it from me to encourage alternate yet more ethical means than IEEE, though I suspect some sort of science hub might have it. It’s that paper. At the time the paper was one in a series of many that moved me away from spending time on the pursuit of langsec and the one language that would keep me and my memory safe and warm at night and instead look for resilient helmets.
I didn’t document or do the work with the intent of publication, so anecdotally, I had a media storage (GELI+GEOM RAID-3) of a few terrabytes in the mid 2000s to about 2013 or so. I kept a manifest of the checksums of all the items separately, and every year would just naively read each file into memory, overwrite it on disk, write it back from memory. The machine passed memtest each time. Over the course of the years something around 10% of the files no longer matched checksums from the beginning.
i’m not sure if it’s the same one i was thinking of, but i recall a similar exploit. first, fill up the heap with instances of two types of objects, such that every A is one bitflip away from a B. then wait a while until a random bitflip turns one of your As into a B, or vice versa. now due to type confusion you have an arbitrary read/write primitive
I know. It was ‘present’ in Android, but trying to install a non-default one raised an exception. Android, very sensibly, decided to treat the process, not the JVM, as the defensible security boundary.
On the other hand, when Android started transitioning (around 5.0) to another SecurityManager in a different ring, SELinux, the workaround for several years (depending on ODM) was simply to switch enforcement mode to permissible. It seems to still be going strong, https://seanpesce.blogspot.com/2023/05/bypassing-selinux-with-initmodule.html .
I’m kind of confused by the arbitrary constraints here. If you’re including in the set of your possible actions “can solder to the RAM bus”, why would you not just use a reliable and timing-precise method instead? Like, sinking the line to ground or pulling it up with a fast switching MOSFET. You might say “oh but this cigarette lighter antenna requires significantly less/easier soldering”, but that’s only because this is being done on an unrealistic target with non-soldered RAM and fairly slow timings. I’m kind of surprised that even for DDR3 this doesn’t already cause signal reflection / impedance matching problems.
It was just the first thing that worked. The “final product” if such a thing ever exists will probably use a MOSFET, but I don’t anticipate that increasing the reliability of the exploit much, if at all.
I’ve been working on it today actually, and I haven’t yet got the pulse duration right. It’s a lot more fiddly.
My very first attempt was to use a chipwhisperer, but that did cause signal integrity issues.
It reads like the constraints is just for the flair of the cigarette lighter gimmick rather than any serious concerns for signal integrity outside of ‘it works kindof sortof for long enough’. Dig far enough on the Chinese sites you can probably find elastomere test sockets cheap enough to work around the restrictions for soldered RAM like how Ang Cui et. all did it with the ice-ice baby cold boot setup.
Nice to see people preparing hardware exploitation techniques in advance of Switch 2 ..
Reminds me of one of my favourite papers: Using memory errors to attack a virtual machine
I can’t get the full text of that, but it looks like the paper associated with the demo I was thinking of where they attacked VMs using a hair dryer on the RAM chips. The Java security model is a mess in many ways and relies on the immutability of strings in a bunch of places, so being able to flip a bit in a string can let you escape in fun ways. Without a SecurityManager installed, you can trivially call the com.sun.Unsafe things and do whatever you want, but the SecurityManager uses string comparison in a bunch of places so being able to make two identical strings have different hash codes gives a nice set of escapes.
The surprising thing was how long the system kept working even with incredibly high bit-error rates. It turns out that nothing really cares about most of the contents of memory.
Far be it from me to encourage alternate yet more ethical means than IEEE, though I suspect some sort of science hub might have it. It’s that paper. At the time the paper was one in a series of many that moved me away from spending time on the pursuit of langsec and the one language that would keep me and my memory safe and warm at night and instead look for resilient helmets.
I didn’t document or do the work with the intent of publication, so anecdotally, I had a media storage (GELI+GEOM RAID-3) of a few terrabytes in the mid 2000s to about 2013 or so. I kept a manifest of the checksums of all the items separately, and every year would just naively read each file into memory, overwrite it on disk, write it back from memory. The machine passed memtest each time. Over the course of the years something around 10% of the files no longer matched checksums from the beginning.
i’m not sure if it’s the same one i was thinking of, but i recall a similar exploit. first, fill up the heap with instances of two types of objects, such that every A is one bitflip away from a B. then wait a while until a random bitflip turns one of your As into a B, or vice versa. now due to type confusion you have an arbitrary read/write primitive
The java SecurityManager is deprecated since java 17 and will be removed in the future https://openjdk.org/jeps/411
I know. It was ‘present’ in Android, but trying to install a non-default one raised an exception. Android, very sensibly, decided to treat the process, not the JVM, as the defensible security boundary.
On the other hand, when Android started transitioning (around 5.0) to another SecurityManager in a different ring, SELinux, the workaround for several years (depending on ODM) was simply to switch enforcement mode to permissible. It seems to still be going strong, https://seanpesce.blogspot.com/2023/05/bypassing-selinux-with-initmodule.html .
I thought this was going to be about tying up the sysadmin and threatening to burn their fingers off unless they tell you the password.
Nah, that would be a wrench.
I’m kind of confused by the arbitrary constraints here. If you’re including in the set of your possible actions “can solder to the RAM bus”, why would you not just use a reliable and timing-precise method instead? Like, sinking the line to ground or pulling it up with a fast switching MOSFET. You might say “oh but this cigarette lighter antenna requires significantly less/easier soldering”, but that’s only because this is being done on an unrealistic target with non-soldered RAM and fairly slow timings. I’m kind of surprised that even for DDR3 this doesn’t already cause signal reflection / impedance matching problems.
It was just the first thing that worked. The “final product” if such a thing ever exists will probably use a MOSFET, but I don’t anticipate that increasing the reliability of the exploit much, if at all.
I’ve been working on it today actually, and I haven’t yet got the pulse duration right. It’s a lot more fiddly.
My very first attempt was to use a chipwhisperer, but that did cause signal integrity issues.
It reads like the constraints is just for the flair of the cigarette lighter gimmick rather than any serious concerns for signal integrity outside of ‘it works kindof sortof for long enough’. Dig far enough on the Chinese sites you can probably find elastomere test sockets cheap enough to work around the restrictions for soldered RAM like how Ang Cui et. all did it with the ice-ice baby cold boot setup.