Slashdot Mirror
A Look at BSD Rootkits
blackbearnh writes "Windows has a reputation for being easily exploited by rootkits, but just because you're using Linux or BSD doesn't mean you're safe from infection. In an interview on O'Reilly's ONLamp site, Joseph Kong (author of Designing BSD Rootkits ), talks about how to build and defend against Rootkits under BSD. 'I know a lot of people who refer to rootkits and rootkit-detectors as being in a big game of cat and mouse. However, it's really more like follow the leader — with rootkit authors always being the leader. Kind of grim, but that's really how it is. Until someone reveals how a specific (or certain class of) rootkit works, nobody thinks about protecting that part of the system. And when they do, the rootkit authors just find a way around it. This is what I meant earlier when I said rootkit hunting is hard — as you really have to validate the integrity of the entire system.'"
And what do you do if you need your CD-ROM drive back? Also, some forms of malware install at the BIOS/hypervisor level. You can't even *detect* that from inside the OS! Some malware dynamically patches the kernel at runtime. So if you access settings on the hard disk or flash drive at all (and how could you not?) the malware can simply install itself after you boot.
The big question is how this malware gets there in the first place. The "towards verifiable systems" presentation linked to from the article listed such options as users who run attachments (merde), malicious employees who intentionally install kits (!), and use of a stolen password. These are all problems that can't be stopped, only mitigated. A malicious employee with physical access to a machine has everything they need, and you can't stop them. You can mitigate the problem by checking for things like tampering with the case and BIOS resets (to clear the password), but these are not foolproof solutions. Same with a stolen password. If you don't know its stolen, a window will always exist in which it can be used.
It *is* possible to build technology that does not suffer from trivial problems like buffer overflows, but you can't stop someone who has clear access to a machine. Authority is authority, and there will always be methods to steal and/or abuse that authority over a machine.
Javascript + Nintendo DSi = DSiCade
He says that the only detectors he is aware of are chrootkit and Rootkit Hunter. As he correctly points out, these are signature based - they look e.g. for specific files in userspace (chrootkit also does a generic check for hidden processes). However, the samhain integrity checker also has two different modules to check for kernel-mode rootkits. First, it can check the kernel syscall table to detect syscall redirection within the kernel (on FreeBSD and Linux), and second, it can detect hidden processes (basically in the same way as chrootkit). Also, if checking file integrity, samhain compares the number of hardlinks of a directory with the number of subdirectories to detect hidden subdirectories.
There is also an audio interview with Joseph Kong:s igning-bsd-rootkits.html
http://bsdtalk.blogspot.com/2007/05/bsdtalk113-de
www.infiltrated.net/scripts/venomous ... Easily portable to BSD
Infiltrated dot Net
Step 1: Analyze NVidia or ATI graphics driver for buffer overflows or similar security issues.
Step 2: Construct an OpenGL call to exploit the issue and create an easy access point into the kernel.
Step 3: Use new access point to patch the kernel or BIOS code.
Step 4: Close the doors and clean up the mess so that there is no evidence of tampering. Just a regular kernel running regular modules and processes. No one knows that the kernel has actually been modified.
Step 5: ??? (Contact foreign terrorists? Skim partial pennies into a swiss bank account? Use for DDoS operations?)
Step 6: Profit!
Note that this potentially works for modules other than graphics modules. It's just that they're the most complex and therefore easier to exploit.
Two problems:
1. This would make binary modules impossible.
2. The current ABI must be documented in a machine-readable form somewhere on the system. The rootkit installer can modify the patch before installing it. Worst case, it can compile source code into a pristine binary that is compatible. (Since you'd be required to have a compiler on your system.)
Javascript + Nintendo DSi = DSiCade
The odds are pretty good if you can steal a Ford Escape, you can steal other cars using the exact same methodology. Maybe not every car, and maybe not even every other Ford car, but certainly other cars. That's why the title makes sense.
Check out my lame java blog at www.javachopshop.com
This is a possibility, but you're assuming that the system contains enough RAM to store all the necessary applications and datasets for the operation of the computer. Your anecdote does not prove that every machine can afford to load a complete OS into memory.
Like it or not, security researchers consider it a real threat.
If you have a physical block in place, then one would think that you should be safe. Not all systems have this jumper, or have it set to prevent flashing by default. Also, an attacker with physical access could change the jumper setting. (See my original post above.)
If you were paying attention, I addressed that issue. If the computer stores settings anywhere (either a hard drive OR removable flash drive), then it is vulnerable. And let's be honest. How many users are going to create a new system layout and reburn it every time they want to change their system? Unless we're talking about an appliance device, not many.
Javascript + Nintendo DSi = DSiCade
I just spent a few minutes reading this paper from the same fellow who introduced BIOS rootkits. It's quite interesting:
The paper goes on to explain the *exact* steps necessary to implement such a rootkit. Ouch.
Javascript + Nintendo DSi = DSiCade
All fair points, though I tend to think that a few of the cases are a little contrived or, as you point out, sophisticated enough to only target a few users. Certainly interesting to consider. Thanks for the discussion!