Forgot your password?
typodupeerror
Security Operating Systems BSD

A Look at BSD Rootkits 98

Posted by Zonk
from the under-the-devil's-horns dept.
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.'"
This discussion has been archived. No new comments can be posted.

A Look at BSD Rootkits

Comments Filter:
  • by Numbah One (821914) on Thursday May 31, 2007 @02:48PM (#19341693)
    is this book illegal in Germany?
    • by jd (1658)
      So long as you read between the lines and not the text itself, you should be ok.
    • by stsp (979375)

      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 :)
  • by Nom du Keyboard (633989) on Thursday May 31, 2007 @02:53PM (#19341757)
    Run your system off of a bootable CD. A little slower to boot, but once it's in memory...
    • by mulvane (692631)
      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...
    • ... it can still be rootkitted.
    • by AKAImBatman (238306) * <akaimbatman.gmail@com> on Thursday May 31, 2007 @03:07PM (#19342031) Homepage Journal
      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 (Score:4, Interesting)

        by Anonymous Coward on Thursday May 31, 2007 @04:14PM (#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 (Score:4, Informative)

          by AKAImBatman (238306) * <akaimbatman.gmail@com> on Thursday May 31, 2007 @04:37PM (#19343397) Homepage Journal

          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.
          • by Sancho (17056)

            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 co

            • (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

              • by Sancho (17056)
                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?

                • 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

                  • Re: (Score:3, Interesting)

                    by Sancho (17056)

                    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

                    • Re: (Score:3, Interesting)

                      by AKAImBatman (238306) *

                      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 throu

                    • Re: (Score:3, Informative)

                      by Sancho (17056)
                      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: (Score:2, Insightful)

                      by AKAImBatman (238306) *
                      And thank you for keeping it civil and on topic. :-)
        • Re:bogus remarks (Score:5, Informative)

          by AKAImBatman (238306) * <akaimbatman.gmail@com> on Thursday May 31, 2007 @05:12PM (#19343975) Homepage Journal

          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.
        • by bendodge (998616)
          Well, with the increase in sector size, boot sector viruses would increase. But I guess that still wouldn't affect Live CD's.
        • by MRAB54 (1109973)
          To expect everybody to run from a live cd is ridiculous. This is NOT a solution to the problem for any real purposes.
      • You only have one CD-ROM drive in your system??
    • Re: (Score:2, Interesting)

      by BosstonesOwn (794949)
      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 t
      • by drsmithy (35869)

        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.

    • by Anonymous Coward
      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: (Score:3, Funny)

      by dedazo (737510)
      Good idea, as long as it's not a Sony CD...
    • Re: (Score:3, Interesting)

      by DaMattster (977781)
      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.
      • by tlhIngan (30335)

        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 ca

        • by ultranova (717540)

          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 m

    • 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.
  • I see that the book is about rootkits in FreeBSD. I wonder if this would have any effect in OpenBSD.
    • Re: (Score:3, Informative)

      by stsp (979375)

      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.
  • Theo must really pissed this guy off.
    • by grub (11606)
      *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: (Score:3, Informative)

        by bberens (965711)
        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.
  • "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?
  • rootkit detectors (Score:4, Informative)

    by Random Walk (252043) on Thursday May 31, 2007 @03:23PM (#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: (Score:3, Insightful)

      by jimicus (737525)
      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.
      • by Sancho (17056)
        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: (Score:3, Interesting)

        by Random Walk (252043)
        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
    • 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?
      • 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 ra

  • by Anonymous Coward
    There is also an audio interview with Joseph Kong:
    http://bsdtalk.blogspot.com/2007/05/bsdtalk113-des igning-bsd-rootkits.html [blogspot.com]
  • got root (Score:3, Informative)

    by packetmon (977047) on Thursday May 31, 2007 @03:25PM (#19342309) Homepage
    www.infiltrated.net/scripts/venomous ... Easily portable to BSD
  • by jd (1658) <[moc.oohay] [ta] [kapimi]> on Thursday May 31, 2007 @03:33PM (#19342467) Homepage Journal
    ...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.

    • by AKAImBatman (238306) * <akaimbatman.gmail@com> on Thursday May 31, 2007 @03:43PM (#19342623) Homepage Journal

      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.)
      • 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...
        • by DrSkwid (118965)
          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: (Score:3, Funny)

      by nuzak (959558)
      > 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 (Score:2, Interesting)

    by davidwr (791652)
    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" requ
  • by jpl (58317)
    ...linux
    • by LurkerXXX (667952)
      ... can also be rootkit'ed. It's not magic. Just more secure than a vanilla Linux install. Get over it.
  • Oh please.. (Score:2, Interesting)

    by pair-a-noyd (594371)
    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.
  • by Anonymous Coward
    BIOS is mentionned nowhere in TFA (the author has some clues)... Yet several people here warns that "it's impossible to have a clean system, your system can have a rootkit in the BIOS".

    Bullsh*t.

    Urban fsck*ng legend.

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

    I'll also mention that a lot of "beige PCs" motherboard require a jumper to be toggl
  • BSD Systems (Score:3, Interesting)

    by DaMattster (977781) on Thursday May 31, 2007 @04:38PM (#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.

    • by archen (447353)
      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 neces
  • 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?".

Prediction is very difficult, especially of the future. - Niels Bohr

Working...