Slashdot Mirror
100kb of Unusual Code Protecting Nuclear, ATC and United Nations Systems
An anonymous reader writes: For an ex-academic security company still in the seeding round, startup Abatis has a small but interesting roster of clients, including Lockheed Martin, the Swiss military, the United Nations and customers in the civil nuclear and air traffic control sectors. The company's product, a kernel driver compatible with Windows, Linux and Unix, occupies just 100kb with no dependencies, and reportedly achieves a 100% effectiveness rate against intruders by preventing unauthorized I/O activity. The CEO of Abatis claims, "We can stop zero day malware — the known unknowns and the unknown unknowns." The software requires no use of signature files, white-listing, heuristics or sandboxing, with a separate report from Lockheed Martin confirming very significant potential for energy savings — up to £125,000 per year in a data center with 10,000 servers.
Sounds legit.
It just automatically turns the machine off whenever you power it on! Foolproof!
Litteraly : "lèche un très gros pénis" but "suce une très grosse bite" would be a more common way to say it.
Chris Howden and John Plumb are the author and approver (respectively) from Lockheed..... Chris and John are lousy scientists.
The kindest way I can figure it is that the driver simply disables disk IO... hence there may be a small power savings from the lack of writes. Less kindly, they happened to measure lower power, and are reporting experimental noise as a solid result (see www-plan.cs.colorado.edu/diwan/asplos09.pdf for instance). We have no error bars (or even a # of runs), so it really isn't possible to say, but disabling disk writes could conceivably reduce power draw. The methodology section is sketchy enough to make solid conclusions impossible; the reporting of experimental details is worse.
Of course, this doesn't (and they admit it) stop me from hacking them in RAM... nor does it stop persistent firmware attacks (e.g. http://www.wired.com/2015/02/n...), nor does it stop me from trapping to ring 0, then trapping to SMM, then just ignoring their F*ING CODE BECAUSE I"'M IN SMM MODE BITCH!!! I GOTZ MY OWNZ ATA CODEZ
Or something.. I'd recommend just cutting the write-enable line on an old IDE drive, or rebooting periodically and running Tripwire from non-writable media (CD?). It's likely cheaper, and probably just as effective.
I'd really like to know on what principles this 'security driver' is based on
From TFS I'm going for homeopathy. It's tiny (less than 100 kb, compared to several GB for an OS installation), has no known mechanism of effectiveness ("the software requires no use of signature files, white-listing, heuristics or sandboxing"), uses meaningless techno-babble to explain how it works ("by preventing unauthorized I/O activity"), makes unrealistic claims of effectiveness ("reportedly achieves a 100% effectiveness rate against intruders ... The CEO of Abatis claims, 'We can stop zero day malware — the known unknowns and the unknown unknowns'") and also claims to save the world (" very significant potential for energy savings").
> it sounds like AppArmor
Or SE Linux, as others have noted.
It is possible to achieve high levels of security through integrity checking and behavior(al) control. It just costs a bit in performance and memory. And if you write something in very tight C, it's not going to be large.
I may have mentioned this here before; if so, I apologize. But a million years ago, back when MS DOS 5 came out, a friend and I developed something called the ARF Utilities. (To my endless amusement, you can still find it in a Google.) Our approach was integrity and behavior blocking.
One reason why DOS was so vulnerable at the time was because Microsoft kept rebuilding and reusing the same code. The entry point to the DOS kernel (the old INT21h interface) didn't change from DOS 5 through 6.22. Our integrity blocker did a simple search to find that in memory, then *patched* DOS to send all calls through the behavior blocker, which was resident in memory. We also hooked and examined a bunch of other stuff inside the kernel (including the INT 21h interface and the SHARE hooks -- the latter was a terrible security vulnerability and only the appearance of Windows 95, and the rapid demise of DOS, kept it from being exploiting widely and wildly.) The blocker was written in assembler and could fit in about 2K of memory, as I recall.
It also checked itself, and the integrity of an executed program's file, at startup, and each time a program was terminated. By "check," I mean it literally scanned its own code in memory, compared random CRCs taken of different blocks to generated values stored earlier and would instantly warn if DOS, the terminating program or itself had been tampered with. (You don't just do one "checksum" of a fixed length; you do different blocks, chosen at random, generated on the fly at system startup.)
We couldn't find a virus that could get around it. The worst we ever experienced was a hang that required a hard reboot. But the system wasn't altered. And yet, the Official Anti-Virus Community (which, at the time, was BIG business) rejected our approach, called us interlopers and marginalized us. Everyone back then wanted scanners, scanners, scanners. All of the tests were on scanners.
In sum: I have no idea if this particular company's code is snake oil or the Real Deal(tm). But don't just dismiss them. If you think outside the box, it is possible to find better ways to do something.
Just my opinion and worth every penny of what you paid for it. :)
Cogito, igitur comedam pizza.
Based on the exclusions, it sounds like a Rule-based anomaly detection engine with some sort of self-training module. Ironically, this is one of the first types of IDS systems created, and is counted as one of the first works by Dorthy Denning (http://webpages.cs.luc.edu/~pld/courses/447/sum08/class9/denning.intrusion_detection_model.pdf). The most successful implementations have used the Markov chain based model. Their down side is that they require a degree of 'training' before the IDS model may go active; however, in a well understood environment like that of a windows server running windows applications, its possible the training could be done in the back-end shop and shipped to customers as part of the COTS product.
Sorry to break it to you, but the only reason no virus got around that is that no one bothered working around a blocker no one uses. In DOS, all it takes to duplicate OS calls is to copy their code, as every process has full access to the hardware and can do everything on its own. And then, any process can write to every location in memory, defeating any anti-virus or precaution imaginable. You would have to reimplement Bochs and interpret every opcode in software, effectively emulating a more secure platform. You can't securely run untrusted code without a MMU of some kind.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.