Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Look at BSD Rootkits

Zonk posted more than 7 years ago | from the under-the-devil's-horns dept.

Security 98

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

cancel ×

98 comments

Sorry! There are no comments related to the filter you selected.

BSD is dead (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19341649)

only unkempt unwashed hippies use that shit

Let me guess (0)

Anonymous Coward | more than 7 years ago | (#19342631)

If those hippies were dead, then they would be using windows? For the blue screams of death?

Illegal Book? (5, Funny)

Numbah One (821914) | more than 7 years ago | (#19341693)

is this book illegal in Germany?

Re:Illegal Book? (1)

jd (1658) | more than 7 years ago | (#19341841)

So long as you read between the lines and not the text itself, you should be ok.

Re:Illegal Book? (1)

stsp (979375) | more than 7 years ago | (#19342679)

is this book illegal in Germany?
I saw a copy of it at linux tag (in Berlin) today. I think I'm gonna grab it tomorrow while I still can :)

Pardon me, but I'm not surprised (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19341713)

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

Re:Pardon me, but I'm not surprised (0)

Anonymous Coward | more than 7 years ago | (#19341763)

Ha. Yea, okay mr AC.

Wyatt Erp

Re:Pardon me, but I'm not surprised (5, Funny)

jalet (36114) | more than 7 years ago | (#19341823)

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

Re:Pardon me, but I'm not surprised (1)

Dik Zak (974638) | more than 6 years ago | (#19348907)

I was literally shocked
Yeah, no software will prevent you touching open wires.

Linux is dead.. (0, Troll)

mulvane (692631) | more than 7 years ago | (#19341727)

Long live BSD

How can you hack a dead OS? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19341755)

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!

Re:How can you hack a dead OS? (1)

betso.net (950024) | more than 7 years ago | (#19362903)

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!

Run your system off of CD (4, Funny)

Nom du Keyboard (633989) | more than 7 years ago | (#19341757)

Run your system off of a bootable CD. A little slower to boot, but once it's in memory...

Re:Run your system off of CD (1)

mulvane (692631) | more than 7 years ago | (#19341795)

I actually have a few systems booting from read only mounted CF cards. Updates are easy as I can create an image, stick it on CF and reboot with it...

Re:Run your system off of CD (1)

deftcoder (1090261) | more than 7 years ago | (#19341941)

... it can still be rootkitted.

Re:Run your system off of CD (5, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19342031)

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.

bogus remarks (4, Interesting)

Anonymous Coward | more than 7 years ago | (#19343081)

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 (3, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19343397)

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.

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.

I seriously doubt that, today, a BIOS malware could be sufficiently advanced to act as a real root-kit.

Like it or not, security researchers consider it a real threat [blackhat.com] .

And you explain me how you remotely install a BIOS on a system that requires changing a jumper before you can flash the BIOS.

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.)

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?

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.

Re:bogus remarks (1)

Sancho (17056) | more than 7 years ago | (#19344661)

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.
Ignoring, for the moment, your assertion that the BIOS could be compromised (though your link doesn't show that security researchers are concerned at all--just one researcher who was looking to be published), storing settings, which are data isn't going to recompromise the system unless there is a vulnerability in the software which reads and uses that data. Just having the hard drive there isn't going to cut it.

In the event of installed software, assuming the malware compromises these files, yes, that could do it. I wonder how many livecds have an easy way to install new software to a partition, how many people would use this functionality, and how many rootkits would look for binaries in these directories to compromise.

Re:bogus remarks (1)

AKAImBatman (238306) | more than 7 years ago | (#19344763)

(though your link doesn't show that security researchers are concerned at all--just one researcher who was looking to be published)

His full paper on the matter is here: https://www.blackhat.com/presentations/bh-federal- 06/BH-Fed-06-Heasman.pdf [blackhat.com]

Also, I made another post right below this one that contained a link to a paper he did on storing extra code in the PCI cards themselves.

storing settings, which are data isn't going to recompromise the system unless there is a vulnerability in the software which reads and uses that data.

Q: How are settings loaded under Unix systems?
A: Executable Shell Scripts.

"Just" having the hard drive available will do nicely.

Re:bogus remarks (1)

Sancho (17056) | more than 7 years ago | (#19346691)

Yes, your links to the papers support my point. One person is concerned with these exploits, and he has an agenda (getting published).

Q: How are settings loaded under Unix systems?
A: Executable Shell Scripts.

"Just" having the hard drive available will do nicely.
I don't understand. Can you give an example of how the data in your settings which is set by an executable shell script is going to compromise my machine unless there is a vulnerability in the shell script? Are you suggesting that during the LiveCD boot process, the LiveCD will run scripts which are located on the hard drive without user intervention?

Re:bogus remarks (1)

AKAImBatman (238306) | more than 7 years ago | (#19346809)

One person is concerned with these exploits, and he has an agenda (getting published).

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.

Can you give an example of how the data in your settings which is set by an executable shell script is going to compromise my machine unless there is a vulnerability in the shell script?

The simplest example is a .bashrc file. Login with your username, and it executes out of your home directory. If that directory is mounted as a persistent data storage, the exploit will be able to add itself to the resource file and get executed. Same thing with the X Resource file, and dozens of other user-modifiable files. If a /etc directory is saved to disk then combined at runtime (there's a special Linux FS for that who's name I forget), then the exploit can use that to add itself to the startup scripts.

Obviously, these items are more detectable than a persistent patched kernel, but not so detectable as to be obvious.

Re:bogus remarks (2, Interesting)

Sancho (17056) | more than 7 years ago | (#19346969)

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 (2, Interesting)

AKAImBatman (238306) | more than 7 years ago | (#19347755)

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 password, etc.)

As I mentioned in my original post at the top of this thread, the completely unprotectable scenario is anyone with direct access to the machine (e.g. again the "rogue employee") could save the rootkit to disk, rejumper the BIOS, reflash it with a bootloader exploit, and no one would be the wiser. Or he could replace the boot CD with a compromised version with the reasonable expectation that no one will verify its contents. (Especially if the CD is an off-the-shelf CD-R that can't be identified by its label.)

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.

One does need to keep in mind that these are Slashdot posts, not formal papers. As much as I'd love to take the time and write out a formal paper for every response, that is not feasible. So you'll have to excuse me if I occasionally generalize or fail to make a point as clearly as I had intended. I'm usually happy to clarify as long as one stays civil in their response as you have. :-)

Re:bogus remarks (2, Informative)

Sancho (17056) | more than 7 years ago | (#19347785)

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!

Re:bogus remarks (2, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#19347803)

And thank you for keeping it civil and on topic. :-)

Re:bogus remarks (0)

Anonymous Coward | more than 7 years ago | (#19376409)

I really enjoyed this debate.

Re:bogus remarks (4, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19343975)

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).

I just spent a few minutes reading this paper [ngssoftware.com] from the same fellow who introduced BIOS rootkits. It's quite interesting:

Many PCI cards contain an expansion ROM that holds additional code required to initialise the card during execution of the system BIOS. This code is also responsible for carrying out the device-specific self-test and hooking required interrupts. The presence of an expansion ROM is determined via the Expansion ROM Base Address Register within the PCI function's Configuration Header.

It is worth noting that the expansion ROM does not necessarily hold x86 code nor does it have to contain a single ROM image. The code type field within the ROM data structure within the image specifies the presence of x86 code or OpenBoot interpretive code (documented in the Open Firmware standard).

The expansion ROM is stored on either an EPROM, or more commonly on an EEPROM. EPROMs require that the chip is removed from the card and erased via exposing it to strong ultraviolet light before it can be reprogrammed. EEPROMs, however, can be erased electrically, in-circuit, thus the card need not be removed from the system and can be re-flashed from the operating system.

In order to perform this, the user must have the SeTcbPrivilege and call the undocumented Native API function, NtSetInformationProcess with a process information class of ProcessUserModeIOPL. Once the user can perform unrestricted I/O, they can potentially re-flash the card without having to load a driver.

This raises the possibility of (1) a remote attack that yields LocalSystem privilege (such as the server service vulnerability patched in update MS06-040) being used to deploy a malicious expansion ROM, (2) a browser exploit, that, if the user is running under the administrative context, obtains SeTcbPrivilege and re-flashes a card.

The paper goes on to explain the *exact* steps necessary to implement such a rootkit. Ouch.

Re:bogus remarks (1)

bendodge (998616) | more than 7 years ago | (#19345893)

Well, with the increase in sector size, boot sector viruses would increase. But I guess that still wouldn't affect Live CD's.

Re:bogus remarks (1)

MRAB54 (1109973) | more than 7 years ago | (#19346997)

To expect everybody to run from a live cd is ridiculous. This is NOT a solution to the problem for any real purposes.

Re:Run your system off of CD (2, Funny)

that this is not und (1026860) | more than 7 years ago | (#19344871)

You only have one CD-ROM drive in your system??

Re:Run your system off of CD (2, Interesting)

BosstonesOwn (794949) | more than 7 years ago | (#19342063)

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.

Re:Run your system off of CD (1)

drsmithy (35869) | more than 6 years ago | (#19350613)

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.

If a system's boot time has any impact on your services' availability, your architecture is broken.

but once it's in memory... (1, Funny)

Anonymous Coward | more than 7 years ago | (#19342157)

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

Re:Run your system off of CD (2, Funny)

dedazo (737510) | more than 7 years ago | (#19342903)

Good idea, as long as it's not a Sony CD...

Re:Run your system off of CD (2, Interesting)

DaMattster (977781) | more than 7 years ago | (#19343585)

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:Run your system off of CD (1)

tlhIngan (30335) | more than 7 years ago | (#19344419)

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.


You know, you can pick up a CD/DVD-ROM drive fairly cheap (or free from a friend)... unless someone has a magic new technology that can turn a reader into a rewriter using just a bit of software.

Re:Run your system off of CD (1)

ultranova (717540) | more than 6 years ago | (#19349307)

You know, you can pick up a CD/DVD-ROM drive fairly cheap (or free from a friend)... unless someone has a magic new technology that can turn a reader into a rewriter using just a bit of software.

With mass production, running one production line is cheaper than running two. That's why it is entirely feasible that the readers and rewriters are actually identical as far as physical components go, and the only differences are in the control board software. In which case simply patching that software would make the reader into a fully functional rewriter.

System in ROM (1)

logicpaw (868693) | more than 7 years ago | (#19346589)

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 is it a problem on a Linux OS (0)

Anonymous Coward | more than 6 years ago | (#19349155)

'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!

OpenBSD? (1)

AltGrendel (175092) | more than 7 years ago | (#19341847)

I see that the book is about rootkits in FreeBSD. I wonder if this would have any effect in OpenBSD.

Re:OpenBSD? (2, Informative)

stsp (979375) | more than 7 years ago | (#19342757)

I see that the book is about rootkits in FreeBSD. I wonder if this would have any effect in OpenBSD.
From TFA:

Is the book focused on FreeBSD only?
Joseph Kong: The book is focused on FreeBSD, however, the methods covered will work on other OSes.

A BSD rootkit? (2, Funny)

wumpus188 (657540) | more than 7 years ago | (#19341855)

Theo must really pissed this guy off.

Re:A BSD rootkit? (1)

grub (11606) | more than 7 years ago | (#19341927)

*BSD is more than one OS, each with different guts. The author said he works with FreeBSD so the thing should be called "A Look At FreeBSD Rootkits". It'd be like writing "How To Steal A Car" when the only car discussed is a Ford Escape.

Re:A BSD rootkit? (2, Informative)

bberens (965711) | more than 7 years ago | (#19343303)

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.

Re:A BSD rootkit? (0)

Anonymous Coward | more than 7 years ago | (#19344101)

Get the source for FreeBSD and OpenBSD then look a the internals. Cut'n'paste exploits won't work. Sure the IDEAS are similar but that's like saying a Linux root kit will work out of the box on MacOSX.

Re:A BSD rootkit? (1)

RazzleDazzle (442937) | more than 7 years ago | (#19344643)

Maybe it should be "OS Rootkits" vs "BSD Rootkits".

Who cares? BSD is dying anyways right? :)

A BSD rootkit? (0)

Anonymous Coward | more than 7 years ago | (#19341915)

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.

*BSD developers leave behind trail of corpses (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19341923)

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:

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 .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: 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.

Re:*BSD developers leave behind trail of corpses (0)

Anonymous Coward | more than 7 years ago | (#19342101)

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 [slashdot.org] )

Re:*BSD developers leave behind trail of corpses (0)

Anonymous Coward | more than 7 years ago | (#19342733)

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.

Re:*BSD developers leave behind trail of corpses (3, Funny)

BosstonesOwn (794949) | more than 7 years ago | (#19342165)

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.


Since when did Steve Balmer start working at dragonflyBSD ?

Re:*BSD developers leave behind trail of corpses (0)

Anonymous Coward | more than 7 years ago | (#19462593)

Since when did Steve Balmer start working at dragonflyBSD ?
Are you saying Steve Balmer works at Windows?
 

Re:*BSD developers leave behind trail of corpses (0, Troll)

jimstapleton (999106) | more than 7 years ago | (#19342583)

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

Re:*BSD developers leave behind trail of corpses (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19343575)

BSD is for fags. Then again, OSS is for fags too. So I guess it makes sense.

PS. Are you a fag?

Parent lifted from Uncyclopedia (1)

dewarrn1 (985887) | more than 7 years ago | (#19343861)

The entire parent post is lifted from Uncyclopedia, "the content-free encyclopedia that anyone can edit": http://uncyclopedia.org/wiki/BSD_is_Dying [uncyclopedia.org] . Their featured article for the day is about global cooling in the 25th century: http://uncyclopedia.org/wiki/Global_Cooling [uncyclopedia.org] . I assume the two pages are equally accurate.

Re:*BSD developers leave behind trail of corpses (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19349937)

Fact:

You are a fucking stupid troll, and not even a very good fucking stupid troll.

Slashdot Hacker Challenge: +1, Informative (0)

Anonymous Coward | more than 7 years ago | (#19342023)


The Challenge:

Root this Al-Qaeda Headquarters [rnc.org]

The Prize:

One year subscription to We're Only After Your Money [whitehouse.org] .

Cheers,
K. Trout

Durr? (1)

nsanders (208050) | more than 7 years ago | (#19342047)

"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?

Re:Durr? (1)

simm1701 (835424) | more than 7 years ago | (#19342173)

You mean your windows admin user isn't called root?

Re:Durr? (1)

dartmongrel (855947) | more than 7 years ago | (#19347437)

don't you refer to your c:\ are your root dir?

rootkit detectors (3, Informative)

Random Walk (252043) | more than 7 years ago | (#19342267)

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 [la-samhna.de] 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.

Re:rootkit detectors (2, Insightful)

jimicus (737525) | more than 7 years ago | (#19344203)

Could someone explain how exactly a rootkit detector can guarantee to be even vaguely reliable on a rooted system? By definition, once rooted you can't trust any of the underlying libraries or even the kernel to do as you expect.

My understanding was the best you can do is boot from CD and then examine the hard disk which actually has the OS installed.

Re:rootkit detectors (0)

Anonymous Coward | more than 7 years ago | (#19345157)

Actually, since a rootkit might be loaded from an EPROM and load into memory but not change the original files on the hard drive, the best thing you can do is take the hard drive out of the suspect machine and analyze it on a known clean system (booted from a CD or it's own known clean drive).

Re:rootkit detectors (1)

Sancho (17056) | more than 7 years ago | (#19346999)

They can't guarantee anything, but they can get ahead of the latest rootkits until such time as the rootkits learn their tricks and hide from the new version of the detector. Yes, it's cat-and-mouse, unfortunately, but so is all security.

Re:rootkit detectors (1)

jimicus (737525) | more than 6 years ago | (#19349031)

Sounds exactly like every mainstream virus scanner in history.

Re:rootkit detectors (2, Interesting)

Random Walk (252043) | more than 6 years ago | (#19348991)

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.

Re:rootkit detectors (1)

ubuwalker31 (1009137) | more than 7 years ago | (#19346001)

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? I know that there are issues with 'hooks' and such...but, whats the real difficulty here?

Kernel changes (1)

Z34107 (925136) | more than 7 years ago | (#19347315)

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.

got root (2, Informative)

packetmon (977047) | more than 7 years ago | (#19342309)

www.infiltrated.net/scripts/venomous ... Easily portable to BSD

Re:got root (0)

Anonymous Coward | more than 7 years ago | (#19347015)

You, sir, are an idiot. Stop posting your stupid script.

There is no fundamental reason (3, Interesting)

jd (1658) | more than 7 years ago | (#19342467)

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

Re:There is no fundamental reason (4, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19342623)

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.


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.

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.

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.)

Indeed... compilation is not barrier... (1)

argent (18001) | more than 7 years ago | (#19345055)

Worst case, it can compile source code into a pristine binary that is compatible.

Indeed. You can even hide a virus in source code, if the source is complex enough. Like, say, Gecko or Qt or Gtk or ... [insert bloated pile of C++ of your choice here] ...

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

Re:Indeed... compilation is not barrier... (1)

DrSkwid (118965) | more than 6 years ago | (#19351835)

patch gcc to do it for you, and for all copies of gcc compiled from then onwards, no need to have it visible in the source code of anything. When was the last time you checked your compiler's binary ?

Re:Indeed... compilation is not barrier... (1)

argent (18001) | more than 6 years ago | (#19353041)

You wouldn't be thinking of this [acm.org] ?

Re:There is no fundamental reason (2, Funny)

nuzak (959558) | more than 7 years ago | (#19343833)

> Have the compiler randomize the kernel's ABI.

I believe this is called the Linux Kernel Development Process. It even scrambles the API's pretty good between iterations.

Minimalist OS (2, Interesting)

davidwr (791652) | more than 7 years ago | (#19342801)

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.

SE... (1)

jpl (58317) | more than 7 years ago | (#19342927)

...linux

Re:SE... (1)

LurkerXXX (667952) | more than 7 years ago | (#19345179)

... can also be rootkit'ed. It's not magic. Just more secure than a vanilla Linux install. Get over it.

Oh please.. (2, Interesting)

pair-a-noyd (594371) | more than 7 years ago | (#19343183)

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.

Re:Oh please.. (0)

Anonymous Coward | more than 7 years ago | (#19343727)

"I mean really. You really have to work hard to allow your BSD or Linux box infected."

You don't ACTUALLY believe that drivel you just wrote do you? BSD, Linux and most other OS's are FULL of unpatched escalation vulnerabilities that make it trivial for most root kits to get installed even from "suposedly" limited user accounts.

"You have to intentionally do something bad, IE circumvent standard security procedures to let this happen."

No you have to intentionally do all sorts of extra, non obvious and draconian things to your system if you want to actually be safe and assured that you have a reasonable well protected system, people like yourself that are under the false belief that by default they are secure are the reason that *nix variant rootkits are still incredibly successfull to this day.

Re:Oh please.. (1)

k3vlar (979024) | more than 7 years ago | (#19346269)

<sarcasm>

CHMOD 777 *

The command is short, so it can't be too bad, right?

</sarcasm>

Re:Oh please.. (0)

Anonymous Coward | more than 7 years ago | (#19346709)

I know you're being sarcastic, but I know from experience that some software (I can't remember which, something inside Gnome or KDE) will refuse to start if the permissions to key configuration files are wrong. I can remember this well, b/c it took me a long time to find the problem and fix it. Also, ruby, for example will generate lots of annoying warning messages if it finds any permissions in its path that it doesn't like.

The point being that some software checks for unsafe permissions before continuing.

Re:Oh please.. (0)

Anonymous Coward | more than 7 years ago | (#19348273)

That's a real nice post you made there. Know what'd make it even better? Knowing that your crappy little desktop machine running gtk-gnutella has different security requirements than an internet-facing server. It's a whole new ballgame when you've got services running.

BIOS rootkits are a myth (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19343219)

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).

Re:BIOS rootkits are a myth (0)

Anonymous Coward | more than 7 years ago | (#19343527)

Try these papers, you dip:

http://www.blackhat.com/presentations/bh-federal-0 6/BH-Fed-06-Heasman.pdf [blackhat.com]

http://www.ngssoftware.com/research/papers/Impleme nting_And_Detecting_A_PCI_Rootkit.pdf [ngssoftware.com]

Also, TFA links off to the Invisible Things website which DOES mention BIOS rootkits.

MOD PARENT DOWN (0)

Anonymous Coward | more than 7 years ago | (#19344195)

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.

Re:BIOS rootkits are a myth (1)

bWareiWare.co.uk (660144) | more than 7 years ago | (#19345229)

Sun wz2100 - and considering it can't even run its fans properly without a BIOS patch this may have been a good think

BSD Systems (2, Interesting)

DaMattster (977781) | more than 7 years ago | (#19343407)

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:BSD Systems (1)

archen (447353) | more than 7 years ago | (#19343789)

I think your average BSD and average Windows rootkit typically have different target victims. Windows is typically a free for all with everyone from grandma to Bill Gates using it. BSD machines typically sit well defended, performing some specific task. Just by sheer market penetration, you're not going to have some random BSD rootkit spread itself all over the internet. So most BSD rootkits are probably dedicated attacks with a brain watching how things transpire - in this scenario FreeBSD isn't necessarily easier to defend, especially if your running something like canned php software.

about covert channel using fake DNS requests (0)

Anonymous Coward | more than 7 years ago | (#19343427)

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?

Once you're penetrated you're ****ed. (4, Insightful)

argent (18001) | more than 7 years ago | (#19343489)

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?

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

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

Re:Once you're penetrated you're ****ed. (3, Funny)

turing_m (1030530) | more than 7 years ago | (#19347043)

"Security is like sex... once you're penetrated you're ****ed."

I think a car analogy would work better here... at least cars are something most people here have a passing familiarity with.

GNU is the problem, not Linux (0, Offtopic)

Benaiah (851593) | more than 7 years ago | (#19347485)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>