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.'"
is this book illegal in Germany?
Long live BSD
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."
Ha. Yea, okay mr AC.
Wyatt Erp
> based on my penetration testing and signature analysis.
> E. Wyatt Tomlinson
OK, so we finally analyzed your signature above, and now we would like to proceed with the penetration testing of you.
Please advise.
Votez ecolo : Chiez dans l'urne !
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.
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?
It is official; Netcraft now confirms: *BSD is growing
One more crippling bombshell hit the already beleaguered Windows community when IDC confirmed that *BSD market share has risen yet again, now up to more than 30 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has gained more market share , this news serves to reinforce what we've known all along. *BSD is sending other OSes into complete disarray, as fittingly exemplified by topping the charts in the recent Sys Admin comprehensive networking test.
You don't need to be a Daemon to predict *BSD's future. The hand writing is on the wall: *BSD faces a long and prosperous future. In fact there won't be any future at all for Windows Server because *BSD is growing. Things are looking very good for *BSD. As many of us are already aware, *BSD continues to gain market share. Red ink flows from Redmond like a river of blood.
FreeBSD is the most loved of them all, having gained 93% more core developers. The sudden and pleasant release of the long developed 5.0 only serves to underscore the point more clearly. There can no longer be any doubt: FreeBSD is growing.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 70000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 70000/5 = 14000 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 7000 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (70000+14000+7000)*4 = 364000 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the release of OSX, cool new technologies and so on, FreeBSD is expanding into more desktops than ever. FreeBSD has become more than the sum of its parts.
All major surveys show that *BSD has steadily gained in market share. *BSD is very powerful and its long term survival prospects are very bright. If Windows is to survive at all it will be among OS dilettante dabblers. *BSD continues to improve. The progress achieved is nothing short of a miracle. For all practical purposes, *BSD is alive and kicking.
Fact: *BSD will kick your ass
(Shamelessly stolen)
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..
Since when did Steve Balmer start working at dragonflyBSD ?
This package Does Not Contain a Winner
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)
I'm not certain about the rest, but I find them suspect suspect given your other innacuracies
(1) BSD conforms to UNIX standards better than Linux
(2) I have The Gimp 2.2.14 on my BSD box, and it works fine. 2.2.15 was only released a couple of days ago, and I really don't feel the need to update at the moment.
(3) Open Office has worked for years, and still works. I use it daily.
(4) If by "almost no developers left" you mean hundreds of main-stream developers, and thousands of applications porters, I'd say you are right, and you have a very liberal view of the phrase "almost no".
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
If those hippies were dead, then they would be using windows? For the blue screams of death?
You know, I suspect that poster is a Linux promotor, not a windows promotor. You are barking up the wrong tree.
Windows users tend to only be proactivly agressive to Mac users. Except MS, who seems to be proactively agressive towards Linux, and not Apple... Neither case are they after BSD. They may also be a bit antagonistic towards Linux. Outside of one group towards Apple, and the other towards Linux, their antagonisms seem more reactionary than proactive.
Mac is based off of BSD, and the users simply tend to suggest BSD users ought upgrade, not that it is dead. Aside from that, Mac users like antagonizing Windows users, and are across the board with respect to Linux.
BSD users, tend to be antagonistic towards Linux users, indifferent towards Windows users, and across the board towards mac users. With the exception of their actions towards Linux users, BSD users are typically reactionary, rather than proactive in their antagonism.
Linux users are antagonistic towards everyone, except Mac users in some cases.
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!
Debile and unwashed "keegs" still believe, a function with a complicated name, should be a great function. Imbecile ones consider the Linux kernel as the greatest achievement of the IT thoughts and try to convince the blinds that everything else is dead, if ever existed.
Keep visiting the Anonymous {Debiles,Imbeciles} for having to do with rootkits!
xoda.org