Rowhammer rides again as FPGA attack, RSA again reportedly up for sale, anti-theft kit to nuke laptops, etc Welcome to the New Year: here are some security headlines that may have slipped past you during the gorging season. Tesla Wi-Fi taken for a ride by hackers The team at Tencent Keen Security Lab has done it again: hacking Tesla's Model S, in which the security shop's parent company has a significant stake. This time the Tesla …
> If a miscreant tries to snatch your machine and run off with it, the cord would pull out and the remaining USB key would trigger a udev command
And the USB key wouldn't pull out?
If the answer is "yes but pulling out the whole USB key triggers the wipe command anyway" ... well then you can make literally the same thing out of a regular $5 USB stick and some chain? The whole "run commands on plug/unplug" thing is literally what udev already does for all devices.
If the answer is "no it'll stay in the USB port", no, I rather doubt it will - unless it's a brand new laptop which hasn't had much USB intercourse yet at all. Or unless the special USB key is glued in, or customized in a way that is unlikely for $20.
The "breakaway" part is a USB cable. The actual USB device is at the other end, right by your belt etc.
The point is that USB sockets are sometimes a bit stiff and USB sticks fragile, so you want to make certain that your security key is definitely going to disconnect and trigger the udev rules.
Otherwise the guts of the $5 USB stick might just stay in the socket while the chain and case dangles from your belt, until the miscreant finds their rubber ducky.
It's easy enough for the disconnect script to prompt for a "cancel the wipe" password with a few seconds grace to do so.
Or for it to actually be a "lock bitlocker" type thing, as anyone that worried about the security of the data on their machine would of course be using disk encryption. Probably with multiple honeypot partitions.
Heritage Company will not be re-opening. It seems the cost of recouping the data and getting everything back up and running was too much
It seems crooks have yet to learn from nature. You only cause enough damage to your host to make them want it to stop. (i.e. Pay up) Killing your host lowers the chance of propagation (i.e. getting paid).
Is this the driver to finally get ECC as standard in servers AND consumer devices?
AWS papers suggest the premium for ECC memory (i.e. ~1.25x cost of additional memory versus the current 2-3x premium) would all but disappear if consumer devices were fitted with ECC as standard.
The increases in stability would likely cover those costs as memory sizes increase (assuming error rates in the 2000-6000 errors/Gbit per billion hours of operation is still valid).
Having read through the post, I'm not sure I understand what they are proving.
My understanding is that Rowhammer allows you to flip bits by repeatedly cycling adjacent bits, potentially allowing you to effect the memory space of other processes. ECC allows you to detect 1/2/more (depending upon implementation - I would assume two-bit implementation would be suitable for general purpose cases)
With ECCploit, you appear to be able to effect sufficient bits that ECC is unable to correct them resulting in a hard error that can be detected but not corrected. In addition, it takes significantly more time to hammer the memory until it achieves the desired result (1 week versus less than 1 hour).
They also note that manufacturers ECC vary significantly - I believe HP Itanium/IBM Power systems are able to detect and recover from 1/2 bit errors in every 4-bit symbol by splitting bits across two RAM modules, so there are likely to still be solutions although they will come with an increased cost.
Anyway...I'm being greedy, I want the improved stability of ECC without the cost...
On Real Enterprise Systems (i.e. not your average consumer laptop or wannabe "server" that's barely hanging on to its upgrade from a desktop design) a hard ECC error triggers such fun as:
Marking the RAM stick faulty and shifting the workload off of it, if possible, or killing the affected processes (or system) if not
Setting a visible hard fault event, basically calling attention to the hardware folks that the box needs help now.
And that's not going into the constant spew that should be showing up in the system logs from all the soft errors being corrected.
That makes the attack both very noisy and very unlikely to succeed. Even some of the old lower end servers will respond to a hard ECC fault by issuing an immediate system reset, though it sounds like this (wanted) behavior was dropped somewhere along the line?
I do know from first hand experience that on Power boxes with Linux if your RAM is generating hard ECC faults the system will mark the stick faulty and literally not use it on the next boot cycle. It does this even if it's generating a bunch of soft ECC faults. Given that, the attack seems most likely to work on machines that are configured to not detect or simply ignore ECC errors, and at that point the organization using such machines has bigger problems to worry about.
After doing more reading, the main examples I can find are:
Parity RAM - detects a single bit error per symbol where a symbol is usually 8 bits. Included for completeness.
ECD RAM - corrects a single bit error and detects two-bit errors per symbol using either 16, 32 or 64-bit symbols based on Hsaio or hamming codes. Hamming with SEC-DED is most common and uses an additional parity bit to ensure any two bit error can be identified for a total of 10 bits for every 8 bits of data (i.e. 72-bit ECC for 64-bit memory buses or 144-bit ECC for 128-bit memory buses).
RAID - RAM banks are mirrored with additional parity to detect errors in one bank
Chipkill - each bit in a symbol is written to individual DRAM chips with BCH coding used to correct one bit errors in a 4-bit symbol or detect 2-bit errors in a 4 bit symbol. This also has additional hardware steps such as hourly scrubbing to detect problem DRAM chips.
Note: there are more - Hsaio//hamming/BCH codes all allow for correcting/detecting higher bit counts with additional bits per symbol but finding if they are implemented is time consuming.
RAID/Chipkill should be immune to Rowhammer/Jackhammer/ECCploit as they target flaws in individual DRAM chips causing adjacent bits to flip - while the bit flipping should still happen given enough time, it will likely be caught and corrected be the correction schemes. EDC will fail if you manage to flip 3 bits or more (i.e. the target bit to change plus its two neighbours).
In addition, DDR4 was thought to be less vulnerable to Rowhammer than DDR3 due to differences in how refreshes are carried out (for scaling sizes, targeted row refresh is used) and although there are still vulnerabilities with specific data patterns, combining DDR4 and EDC is likely to reduce the potential for a successful attack (which is hinted at on the ECCploit site as they don't specifically test DDR4 with ECC due to the number of variables required to test i.e. getting sufficient DDR4 hardware, determining the ECC scheme used for each tyope and then finding the pattern required to trigger the fault with targeted row refresh enabled)
As much as I would like that, I doubt it, as a prerequisite of these attacks is for the attacker to already have their code running on the victims computer. In the case of consumer devices it's already game-over at that point. The only place these attacks are really a concern is situations such as cloud computing where you share the hardware with untrusted third parties, or perhaps DRM where the untrusted party is the owner of the hardware.
Having worked at IBM ~15 years ago, I implemented ECC-code generation. The standard then was that any one-bit error was correctable, and any two-bit error was detectable. By default, such errors would result in a machine fault interrupt, which were generally considered non-recoverable (outside a reboot).
Memory was periodically read & written back to ensure that one-bit errors would be corrected.
So, I don't consider rowhammer-class attacks to be serious if ECC memory is in use, except possibly (possibly) as a DOS attack.
On the other hand, on shared hardware, this becomes yet another headache. In addition to the destructive performance loss of these software hurdles against Specter-class attacks, now you need to pay for ECC memory (and the performance loss in keeping it fresh). Go with dedicated boxes, and you can avoid all of this...
So, we can send people to the moon, build electric autonomous vehicles, create anti-biotics, do advanced surgery, build ever increasingly terrifying weapons, sometime ago we even somehow managed to figure out how to create fire when we were still smashing rocks together
Yet, we are incapable of putting out a fire in Australia
Humans aren't just amazing, we're brilliant, we are legends in our own teabreak!
"Yet, we are incapable of putting out a fire in Australia"
Imagine fighting a fire across an area 3/4's the size of Scotland and capable of not only moving at the speed of the wind but also generating enough heat to generate thermals and cause it to become elf-propelled for short periods of time.
Getting out of its way and cleaning up as best you can afterwards is a pretty good option unless the rain comes.
I was curious if that Buskill would work on Windows, and it turns out, it does!
1) Open Event Viewer, and drill down to "Application and Service Logs - Microsoft - Windows - DriverFrameworks-UserMode"
2) We need the "Operational" log which is disabled; to enable, right click -> Properties, tick "Enable Logging", OK
3) Find a spare memory stick of a make/model that you don't otherwise use. Plug it in, wait a few seconds and unplug.
4) Refresh the view, then open the latest entry with EventID 2102
5) Switch to the "Details" tab, then "XML View". You will need the the data from the "InstanceID" field
6) Paste the following XML into your editor of choice (you can remove the extra white lines; the forum inserts those automatically on line-breaks):
***Begin XML***
<QueryList>
<Query Id="0" Path="Microsoft-Windows-DriverFrameworks-UserMode/Operational">
<Select Path="Microsoft-Windows-DriverFrameworks-UserMode/Operational">*[System[(EventID=2102)]]
and
*[UserData/UMDFHostDeviceRequest/InstanceId="Your Instance ID"]
and
*[UserData/UMDFHostDeviceRequest/RequestMinorCode="23"]
</Select>
</Query>
</QueryList>
***End XML***
Replace "Your Instance ID" with your InstanceID data from the event log, then replace all special characters with their ASCII hex codes. For example, my InstanceID of:
SWD\WPDBUSENUM\_??_USBSTOR#DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_PMAP#50E549C695A4BF10698DA240&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}
Became:
"SWD\WPDBUSENUM\_??_USBSTOR#DISK&VEN_KINGSTON&PROD_DATATRAVELER_2.0&REV_PMAP#50E549C695A4BF10698DA240&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}"
7) Copy your completed XML. Open Task Scheduler, create a new task. Create a new "Trigger" and from the "Begin the Task" drop-down, select "On an event", Select "Custom" and click the new event filter button. Switch to the XML tab and tick the "Edit query manually box". Paste in your XML from above.
8) OK back out a couple of times, and finish setting up your task. I set my Action to lock my computer: Action: start a program; program: "rundll32.exe"; Add arguments: "user32.dll, LockWorkStation"
9) Tweak final settings, mainly allowing the task to run if not on AC power, and you're done :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
