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.'"
only unkempt unwashed hippies use that shit
is this book illegal in Germany?
I tried BSD once. Not nearly secure enough for my purposes. All sorts of insecure services, outdated daemons. I was literally shocked. Of course, my needs are very high because I am a senior programmer at a security assurance firm. But you would be wise to avoid BSD based on my penetration testing and signature analysis. If security is your focus, there really is only one answer: Solaris. Your mileage won't vary.
E. Wyatt Tomlinson
Long live BSD
Spooky! Rootkits for dead OSs! Are these programmed by some zombies or who has the energy to bother with dead OSs? This is like grave robbery!
Run your system off of a bootable CD. A little slower to boot, but once it's in memory...
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
I see that the book is about rootkits in FreeBSD. I wonder if this would have any effect in OpenBSD.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Theo must really pissed this guy off.
What is that? Something to keep roots from growing into the coffin? That have something similar for home sewer lines. Getting roots in there can be a real disaster.
Yet another sickening blow has struck what's left of the *BSD community, as a soon-to-be-released report by the independent Commision for Technology Management (CTM) after a year-long study has concluded: *BSD is already dead. Here are some of the commission's findings:
.005% of internet servers. A recent attempt at a face-to-face summit in Boulder, Colorado culminated in an out-and-out fistfight between core developers. Hotel security guards broke up the melee and banned the participants from the hotel. Two of the developers were hospitalized.
Fact: the *BSDs have balkanized yet again. There are now no less than twelve separate, competing *BSD projects, each of which has introduced fundamental incompatibilities with the other *BSDs, and frequently with Unix standards. Average number of developers in each project: fewer than five. Average number of users per project: there are no definitive numbers, but reports show that all projects are on the decline.
Fact: X.org will not include support *BSD. The newly formed group believes that the *BSDs have strayed too far from Unix standards and have become too difficult to support along with Linux and Solaris x86. "It's too much trouble," said one anonymous developer. "If they want to make their own standards, let them doing the porting for us."
Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.
Fact: There are almost no FreeBSD developers left, and its use, according to Netcraft, is down to a sadly crippled
Fact: NetBSD, which claims to focus on portability (whatever that is supposed to mean), is slow, and cannot take advantage of multiple CPUs. "That about drove the last nail in the coffin for BSD use here," said Michael Curry, CTO of Amazon.com. "We took our NetBSD boxes out to the backyard and shot them in the head. We're much happier running Linux."
Fact: *BSD has no support from the media. Number of Linux magazines available at bookstores: 5 (Linux Journal, Linux World, Linux Developer, Linux Format, Linux User). Number of available *BSD magazines: 0. Current count of Linux-oriented technical books: 1071. Current count of *BSD books: 6.
Fact: Many user-level applications will no longer work under *BSD, and no one is working to change this. The GIMP, a Photoshop-like application, has not worked at all under *BSD since version 1.1 (sorry, too much trouble for such a small base, developers have said). OpenOffice, a Microsoft Office clone, has never worked under *BSD and never will. ("Why would we bother?" said developer Steven Andrews, an OpenOffice team lead.)
Fact: servers running OpenBSD, which claims to focus on security, are frequently compromised. According to Jim Markham, editor of the online security forum SecurityWatch, the few OpenBSD servers that exist on the internet have become a joke among the hacker community. "They make a game out of it," he says. "(OpenBSD leader) Theo [de Raadt] will scramble to make a new patch to fix one problem, and they've already compromised a bunch of boxes with a different exploit."
With these incontroverible facts staring (what's left of) the *BSD community in the face, they can only draw one conclusion: *BSD is already dead.
The Challenge:
Root this Al-Qaeda Headquarters
The Prize:
One year subscription to We're Only After Your Money.
Cheers,
K. Trout
"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."
I dunno, ya think that's why they're called ROOTkits?
Consistent with the Leaving core. I ooficers. Others And has instead it just 0wnz.', that support more. If you feel which allows Quarreled on with the number shout the loudest Of the above Creek, abysmal So there are people gains market share well-known [tux.org]? Are you GNAA on slashdot, brain. It is the and/or distribute *BSD but FreeBSD Of programming NetBSD posts on (CLICK HERE niggerness? And has been my only many of us are suffering *BSD this exploitation, share. FreeBSD is here, please do
but once it's in memory...
What can I say? BSD is in our memory, rest in peace BSD! You will remain in our memories..
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
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If those hippies were dead, then they would be using windows? For the blue screams of death?
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
...linux
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.
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 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).
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.
From TFA (near the end, yup... I read it all, I'm new here ;) where, at one point, it talks about one doing a cover channel by subverting DNS requests:
This will cause the owned machine's local DNS server to connect to a nameserver for domainname.tld. The nameserver(s) at domainname.tld are, of course, under the rootkit owner's control.
This certainly won't cause any of my LAN's machines to connect to domainame.tld for all DNS requests of my machines are filtered by an OpenBSD firewall that authorize DNS request to exactly two DNS server (my ISP's primary and secondary DNS servers, using hardcoded IPs in the firewall).
But this makes me wonder: am I breaking any RFC here by doing that? That is: by only ever allowing machines from my LAN to connect to the DNS servers of my ISPs?
Basically, once someone has gotten their code running on your system, they can do anything they want, and they can pretty much keep you from noticing that they're there. If you go looking for them, though, odds are you'll find them... but who's going to go looking?
... which is why they have all those security dialogs: those dialogs come down to "this program is about to do something that might be stupid, is that OK?".
There's no magical difference between "rootkits" and any other trick for hiding code in a system... it doesn't matter if it's a "virus", or a "rootkit" or even a "polymorphic perverse passive-agressive viral-enhanced trojan rootkit" (or whatever the cool terminology of the week is), the trick to hiding is to change the things you know the rootkit detectors or antivirus software is looking for so they look right. The trick to finding them is to look in more places, and look in ways that they haven't thought of covering up. But the real trick is keeping them out in the first place.
Security is like sex... once you're penetrated you're ****ed. If the basic software is designed to that when implemented as documented there's no mechanism for an attacker to use, then you're in pretty good shape. At least, you will be able to fix any holes that DO show up without breaking working software. And that's the main disadvantage Windows has... there's just too much everyday software and important APIs that are inherently insecure. Even when implemented as documented, there's attacks
At the very least, you need to cut that down to "you just asked to do something that might be stupid, do you mean it?".
The entire parent post is lifted from Uncyclopedia, "the content-free encyclopedia that anyone can edit": http://uncyclopedia.org/wiki/BSD_is_Dying. Their featured article for the day is about global cooling in the 25th century: http://uncyclopedia.org/wiki/Global_Cooling. I assume the two pages are equally accurate.
Parent is ignoring the fact that nearly every device you plug into your system has a flashable ROM on it. PCI-BIOS calls can be used to steal extra space from these devices to create a "real" rootkit of significant size. Graphics cards in particular tend to have very large ROMs to accommodate their controller code. Standard BIOS jumper settings have no effect on these ROMs.
Parent is also ignoring the fact that Intel is forcing EFI BIOSes on newer machines, bloating the size of the normal BIOS ROM. This provides a great deal more space than older BIOSes designed for DOS.
Worst case, it can compile source code into a pristine binary that is compatible.
... [insert bloated pile of C++ of your choice here] ...
Indeed. You can even hide a virus in source code, if the source is complex enough. Like, say, Gecko or Qt or Gtk or
Compilation isn't a big slow noticable step any more. I'm using Tcl modules that generate C code to cache an SQL table at runtime... as an optimization. There's gentoo riceboys talking about building a kernel from the miniroot at boot time...
Better yet, boot the OS from flash memory, and make that portion of flash memory unwritable by some physical interlock which is hard to remove by idiots. Some embedded linux appliances are close to this.
Why can't the rootkit software look at an MD5 checksum of the kernel vs the kernel as configured, to determine if there are changes to the kernel?
Not a *nix programmer myself, but as previous posters pointed out (FreeBSD is a Ford Escape and whatnot), the same ideas apply everywhere.
Your OS is rooted. So, you call your OS's MakeMD5Hash() function. Except, how do the hash function wasn't rooted? For all you know, that code could now return nothing but the MD5 hash calculated before the kernel was raped.
So you do the dirty work yourself. You compute a checksum from examining every byte of kernelspace in memory... except, how do you know you're reading the memory you think you are, that a rootkit hypervisor isn't redirecting your memory access elsewhere? Windows (32-bit) "guarantees" every process 4GB of flat memory to work with through this magic, and your program is none the wiser.
Now, imagine that kind of memory tomfoolery being played on your OS by a hypervisor. Just like a program running in multitasking Windows, you have no idea if the memory you just read at 0xBAADF00D actually came from 0xBAADF00D. Go down to bare metal and view memory yourself with some good ol' kernelspace assembler code - and watch as the rootkit running in "ring -1" of your modern CPU invisibly redirects every attempt to access memory.
The problem with anything running at the kernel- or user-level on a rooted system is that you have no way of knowing if anything was compromised, if what your code reports to you is "real." It's like your OS took some magic mushrooms - you can't trust what your kernel-API "senses" are telling you, and in the meantime there's some Italian plumber running around after your princess and credit card information.
DATABASE WOW WOW
It's not really the problem with the Linux kernel. Its all of the other applications that make up the GNU/Linux bundle.
If only the same amount of discipline that goes into kernel changes went into all GNU applications. Secure systems aren't that hard to develop. They require proper procedures to be in place to follow while coding to avoid simple buffer overflow.
'cos EVERYBODY knows that you have to drop to the command line and recompile the kernel to get any new feature on Linux.
Right?
Bwahahahahaha!