'R2D2' stops disk-wipe malware before it executes evil commands Purdue University researchers reckon they've cracked how to protect data against “disk-wipe” malware. Led by Christopher Gutierrez, the team has created a shim of software that analyses write buffers before they reach storage, and if the write is destructive, it steps in to preserve the data targeted for destruction. Dubbed …
Now, I'm all in favor of methods which can prevent nasty software from achieving its goal(s) but the whole snapshot mechanic isn't exactly new, so quite honestly I don't understand what the big fuss is about.
Snapshotting file systems has become pretty mainstream, even Windows has supported this service for many years already (starting in Windows XP and it become more mainstream in Windows Vista / 7). I've encountered quite a few malware infections (ransomware) on Windows where the solution was simply to roll the system back to a previous snapshot. Which, out of precaution, were made every 2 hours.
It's the integration of introspection into the constant flow of I/O of the device(s). Doing it on the fly continuously can be cheaper than doing the same snapshots every two hours albeit a longer operation to execute and, further, less useful. Rollback of small snapshots is very inexpensive. I also like the whitelisting. The example given of reinstalling the OS is a valid point, if not one I'd pick.
This doesn't seem to do much against encrypting malware though - ultimately there's no way to know what counts as "destructive", any write operation destroys _something_. Unless you're prepared to use an infinitely versioning file system that preserves anything and everything ever written (yeah good luck with your storage medium capacity) the only viable solution I see is lots of decoy files, monitored by a watchdog that immediately trips and alerts as soon as any of them is written. It would still be an arms race about obscuring vs. detecting which files are the "trap" ones of course...
This doesn't seem to do much against encrypting malware though
Most data files and all executables have a fixed header, encryption will generally corrupt that so it should be possible to detect most cases of encryption on the fly.
Just look to see if the first few bytes of a file change, if so backup the original and then if there are a lot more similarly affected files stop the operation and ask the user if it was intentional.
The idea needs refinement but it should be possible to make it work pretty well.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
