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.'"

Comments

Re:Run your system off of CD

[BosstonesOwn]

Not so easy in a high availability environment. Where boot times can cost thousands of dollars a second. These root kits can cause havok there.

I work at Sun and some of the worlds largest companies use our gear. I know one case where a heavy iron machine went down and it would have cost over 200 k for the 2 hours the box was down. Thankfully we have a good support crew and they had fail over components , dedicated to that company or it could have been bad.

Of all the *nix variants I have used Solaris seems to fit the bill for me and I run it at home beside the old red hat 7.3 box. The more i work with it on heavy iron the more I get to like it.

There is no fundamental reason

[jd]

...why rootkit writers should ever be ahead of the game. First off, installing code into the kernel should be regulated such that rogue code can't gain all of the necessary rights. Yes, that means legit modules can't auto-install unless you have some multi-key system, such as having modules individually pre-approved, signed by the builder and countersigned by the system admin. Never said it would make your life easier. In fact, making things too easy for you makes it too easy for those you don't want to give access rights to.

Second, all modules should be exposed and visible at all times, along with the connections between modules. This is not hard. You have a hypervisor which doesn't do virtualization, rather it simply queries the OS on what the OS is currently doing. Why have something below the kernel? Because then it cannot be written to by the kernel. It is outside the kernel's memory space. It cannot be trapped, descheduled, replaced, modified or even sniffed by the OS or anything the OS is running. This gives you a covert channel to a monitoring tool that the rootkit cannot disable or interfere with. The OS merely needs to provide some sort of API that the hypervisor can use to supervise the kernel's activities and intercept the information needed to establish the covert channel with the monitoring tool.

Too complex? Ok, then how about a third solution: Have the compiler randomize the kernel's ABI. Totally. Absolutely zero predictability in how parameters are passed. The compiler just needs to make sure ALL calls to a specific function call that function the same way, whether the object is linked in or compiled as a module. It also has to make sure that out-of-tree builds also compile to the correct ordering for each function. Binary-only modules would need to be supplied with the source code for a glue layer that can map the binary's ABI with that of the kernel. Any unauthorized module will make calls that violate the ABI and therefore cannot stay running. They might crash the kernel, but that could be better than unauthorized and uncontrolled activity which might do far more damage.

Last, but not least, the kernel could support trusted computing modules and mandatory access controls for memory. It's the least secure, in some ways, but Trusted IRIX is pretty damn secure and I'd have some measure of faith in any integrity system that came close in design. (SGI released "Open B1" - OB1 - which was some of the code used to make IRIX as hard as it was. Dunno if anybody looked through the code for ideas - it wouldn't have mapped directly into Linux, but ideas are ideas and are OS-independent. Besides, OpenBSD at the time had no mandatory access control support. I don't know how far the other BSDs have got - I know there's some MAC and/or RBAC support in some, but are we talking basics or B1-equiv?)

Maybe a rootkit author could bypass all of these, but I doubt - seriously doubt - that it would be a trivial weekend exercise to bypass Trusted Computing or strong authentication/validation mechanisms.

Minimalist OS

[davidwr]

For some applications, you want a minimalist OS and a minimalist application.

Take an "appliance" web-server for instance.

You need a way for the web server application to read and write to a data store, you need a way for the end-user to access the web server for pages, and you need some way to administer the system. You need to make sure nothing else happens that isn't directly supporting these activities. You also need to make sure any "supporting" activity doesn't do something rogue.

Due to "legacy" requirements including reusing existing code and staff skills, you may need it to "look like" LAMP or some other arbitrary environment to a developer.

That's not an easy task to do right, but it's a lot easier than writing a general-purpose OS like BSD or Linux.

bogus remarks

[Anonymous Coward]

And what do you do if you need your CD-ROM drive back?

Pardon me? Last time I checked I could pass some "toram" parameter to a lot of Live CDs, making the system run perfectly fine, entirely in memory, on my old P4 / 1 GB of ram. No problem to use other CD/DVDs.

Also, some forms of malware install at the BIOS/hypervisor level.

BIOS and hypervisor are two very different things. I seriously doubt that, today, a BIOS malware could be sufficiently advanced to act as a real root-kit. That is, a BIOS malware will not even be able to fool anti-virus running from inside the system. There simply ain't enough room in the BIOS to code such a beast. And you explain me how you remotely install a BIOS on a system that requires changing a jumper before you can flash the BIOS.

That blue pill paper was sensationalism at its worst. An "hypervisor rootkit" should provide a system capable of itself allowing another hypervisor to run. If it's not the case, it's super easy to detect... And even to counter: simply install another hypervisor, like the very fine Xen I'm running now and the hypervisor root-kit can't do anything.

Now another possibility: an hypervisor rootkit allowing another hypervisor to take place: the system would be so slow that the "timing attack" (an attack that has be proven to detect 100% of "hypervisor rootkits", should they ever come to exist) would simply be the user seeing its system so slow that it's clear that something fishy is going on.

Remember that you were replying to someone talking about running a system of a live CD. If the system has no hard disk, explain me where your hypothetical, urban legendary, hypervisor rootkit would reside? I seriously hope you're not implying the BIOS hold enough room to contain an hypervisor rootkit (come take a look at an hypervisor like Xen to see what I'm talking about). Not to mention that should the system have an hard disk and the hypervisor be prevent on the hard disk, I hardly see how a system configured to boot from the CD first would launch your urban legendary hypervisor...

You can't even *detect* that from inside the OS!

Anyone relying on scan ran from inside the OS to detect malware is a fool. An anti-virus running from inside the OS can find some malware and can prevent some kind of infections but thinking that because an anti-virus running from inside the OS reports nothing is a proof that there's no malware present on the system is a fool.

Btw I'm running an hypervisor on several machines, I've got "snort" behind a physically passive tap on my LAN, etc. I think the GP's advice of running a system of a Live CD is a very good advice (even tough you still can get infected... Good luck for malware to persist on the machine) while I think your answer is completely offtopic.

Re:bogus remarks

[Sancho]

If the exploit works, it works. Pure and simple. His papers are referenced by other security researchers (which is how I found out about them) who mention BIOS exploits. By your logic, all researchers are "just looking to get published" whether they advance their field or not. There's so much more to whether it works or not that your statement is absurd. There's difficulty, feasibility, detectibility, reproducibility... at Black Hat last year, a presenter failed (multiple times) to demonstrate his exploit because it was extraordinarly difficult to pull off, and there's speculation that the Maynor wireless exploit wasn't demonstrated for the same reasons. In that latter case, a well respected security firm stood behind two researchers who showed remote, wireless exploitation of device drivers--look how well that turned out.

Also, without trying to be pedantic, this is the first time you've referenced anyone besides the guy who wrote the papers, yet you claimed that security researchers consider it a real threat. A couple of people who consider it a real threat does not give weight to it. The debunking of "Blue Pill" (and a less well-known hypervisor exploit which was also demo'd at Black Hat in Las Vegas last year) demonstrate this. While they're fascinating technical demonstrations, the feasibility of a general-purpose exploit (that is, not targeting a specific platform, software version, etc) is low.

Obviously, these items are more detectable than a persistent patched kernel, but not so detectable as to be obvious. Right. Because you first said, 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. I inferred that you meant that simply having a hard disk in the machine was all that was required. In fact, you said as much: "Just" having the hard drive available will do nicely.

I'm not trying to be rude, but if you formulate and express your opinions a little better, you'll probably get less argument from people. Of course if a home drive is mounted, and .bashrc/.profile/.xinitrc/whatever is autorun, then malware will be capable of reinstalling itself. That's a far cry from the sensationalist arguments presented--that simply having a hard drive installed in the machine is sufficient to allow recurring compromises.

Re:bogus remarks

[AKAImBatman]

There's so much more to whether it works or not that your statement is absurd. There's difficulty, feasibility, detectibility, reproducibility...

True. However, these are not particularly sophisiticated attacks. They assume that a privledge elevation exploit already exists. If one exists, then reflashing the BIOS and/or executing PCI-BIOS commands are straightforward and well-documented. Anyone who has done system-level coding could pull it off without needing to question if it's even possible. Reading through the attacks, they ring true with my experience in system-level coding. There's nothing that would cause me to question how feasible it is. The only issue is how much space is available on the ROM chips. Particularly the main BIOS chip. More on how that can be circumvented below.

Also, without trying to be pedantic, this is the first time you've referenced anyone besides the guy who wrote the papers, yet you claimed that security researchers consider it a real threat.

A fair point. I did reference the specific document in my first post, but looking back I only attributed the methods of attack.

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. I inferred that you meant that simply having a hard disk in the machine was all that was required. In fact, you said as much: "Just" having the hard drive available will do nicely.

That is all that's needed. I was providing a straightforward example in line with my original assertion of "if the computer stores settings on the disk". There are quite a few more scenarios:

Scenario 1: Disk is mounted, but only settings for user applications (e.g. Firefox) are stored.
Exploit: Firefox allows for user extensions to be installed into the settings directory. An attacker could install an extension that runs the kernel-patching exploit each time Firefox is started.

Scenario 2: Disk is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD has features which allow it to pull extra programs from disk, but they are not used.
Exploit: Install the directory structure that the Live CD expects. Make the rootkit one of the packages that gets loaded and executed on startup.

Scenario 3: Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD is locked down to prevent disk loads.
Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small bootloader into the BIOS. This bootloader loads a hypervisor or rootkit from disk and begins execution. The malicious code then loads the kernel from CDROM as if nothing was wrong, but takes pains to modify the kernel before executing it.

Scenario 4:Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. BIOS is jumpered to prevent undesirable reflashing.
Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small piece of code into a PCI ROM Chip. For this example, let's say that it's a video card. When the system loads the video BIOS, it also loads the malicious program. Once executed through a video vector (e.g. Protected mode VESA) the program attempts to load the kernel patch from disk and execute it.

Obviously, these attacks grow in sophisitication with each layer of security added. The greater the sophistication, the more likely it is to only be targetable to a small cross-section of users. However, the original concern I raised was that these rootkits are being installed through vectors that cannot be protected against. (e.g. rogue employee, stolen passw

Oh please..

[pair-a-noyd]

I mean really. You really have to work hard to allow your BSD or Linux box infected.
The system is designed to prevent noobs from doing stupid things.
You have to intentionally do something bad, IE circumvent standard security procedures to let this happen.
You have several chances to NOT do what you know is bad, besides, you have to know what you are doing to be able to do it!

If you manage to end up with your Linux or BSD box infected, you OPTED IN by your own free will so don't whine.

BIOS rootkits are a myth

[Anonymous Coward]

BIOS is mentionned nowhere in TFA (the author has some clues)... Yet several people here warns that "it's impossible to have a clean system, your system can have a rootkit in the BIOS".

Bullsh*t.

Urban fsck*ng legend.

There have been some very lame, very trivial to detect, viruses targetting the BIOS but that's it. There simply ain't enough room to put something approaching a rootkit in the BIOS. There's your reality check.

I'll also mention that a lot of "beige PCs" motherboard require a jumper to be toggled before you can flash a BIOS and that there hasn't been a single Sun box produced where you could flash the "BIOS" without toggling a jumper.

So much for the BIOS rootkit urban legend.

So, moderators, please, would it be possible to mod down all the people whining "BIOS rootkits" everytime an article about security comes up on /.?

I re-emphasis that said FA talks nowhere about BIOS rootkits (probably because TFA author doesn't want to look like a clueless jerk).

BSD Systems

[DaMattster]

BSD Systems are far more immune to rootkit attacks than Windows. A default install of FreeBSD basically gives the administrator the ability to perform a console login. It is up to the administrator to run services as he or she sees fit. By simply tracking the freebsd-security mailing list, you are kept abreast of holes that arise and can patch them very quickly. Honestly, my fear of remote intrusion is a lot lower with FreeBSD than with Windows. Free/OpenBSD's firewalling facilities are so good (assuming they have been configured correctly) that only an absolutely determined intruder would get in and the difficulty of it might make him think time would be better spent on systems with weaker security. But, with that said, a good intruder will be also be able to stop in and cover their tracks completely.

The author of the article also wisely notes that KLDs also can cause problems. I would say that the KLDs included by default are fairly safe. It is the third party ones that you need to be wary of. I disagree with the author on the notion that compiling the support right into the kernel is a good answer. What happens if a remote hole is found in, say IPv6, and you have it hard coded into the kernel. I would rather be able to instantly kldunload the offensive binary rather than have to take an entire server offline to patch, recompile the kernel and continue on.

Re:Run your system off of CD

[DaMattster]

A friend of mine does this on his OpenBSD box designated for routing. It is actually a pain in the rear because he needs to spin off a new CD when patching is necessary for security. Wisely, he does not trust a rewriteable CD. The only advantage realized is that the attacker cannot implant any of his or her programs. It isn't feasible from a manageability standpoint, however.

Re:rootkit detectors

[Random Walk]

In theory, once rooted you cannot trust anything on the system. In practice, in about 99.9 per cent (or more) of all intrusions, the intruder will use some more or less imperfect off-the-shelf rootkit that only performs standard activities (hide itself, open a backdoor, do keylogging or similar). If it's old, signature-based detectors like Rootkit Hunter or chkrootkit will work. If it's new, signature-based detection will fail, but generic detection techniques (like the ones employed by samhain) have a good chance of catching it. You have a pretty slim chance of ever seeing the (theoretically possible) flawlessly programmed rootkit that hides itself perfectly by closing all possible ways of detecting it. As an example, there are plenty system calls that take a PID (or a path, i.e. /proc/PID) as argument and can be used to infer the presence of a process. All kernel rootkits I've ever seen only care to "fix" about half a dozen of the most frequently used of these system calls.