My Sacrosanct Kernel

Dave G. | July 17th, 2006 | Filed Under: Defenses, Industry Punditry, Malware

I rarely find myself disagreeing with Greg Hoglund, but I think he needs to put down his Rootkit bible for a minute and consider his latest rootkit commentary.

Rootkits aren’t complicated, I’m sorry to say. The only thing that is complicated is the constant push-pull of the bi-polar security industry. If you want my opinion, my opinion is this: Let Symantec, Kaspersky, F-Secure, and all the others use rootkit technology, it only makes their anti virus products more effective. Let anti-spyware companies like Sunbelt use rootkits against rootkits. Use fire against fire.

Here are my issues:

  1. Subterfuge. This doesn’t have to be fire against fire —- it can be fire against fireworks. Why bother to install a rootkit if one is already there to leverage? And since AV software will have to be aware of the fact that there is ‘Rootkit Enabled’ software on there, attackers can easily go undetected.

  2. Confusion. When the software we trust behaves like the software we don’t trust, we increase the the likelihood that we won’t notice bad software.

  3. Reliability. How many rootkits does one person want/need on their machine? If it’s ok for people to develop software that uses rootkit techniques to hide, it’s natural that multiple pieces of software will try to use similar techniques. We know this has incredibly bad consequences for end users. So I dont want 5 pieces of software mucking with my kernel. And while I might wax nostalgic about the good old days of DOS memory conflicts, or System 7 Extension conflicts, I am not actually looking to relive them. Of course, maybe the logical answer to this is a Rootkit Manager program that can help resolve rootkit gridlock. Greylock, Battery, you listening?

  4. Arms Race. Ok, so this is true of all things security. But, when combined with the above issues, this quickly becomes a losing proposition.

I don’t agree w/ people who say such approaches take away an administrators capability to administer a box. To solve the administrator problem, you only have to do one thing: Treat your rootkit features as a black box and uninstall them with the rest of your product. If an administrator doesn’t want your product, then he can uninstall it. You aren’t taking anything away.

The administrator (or security analyst or forensics investigator) isn’t always given that choice. It is important that organizations understand the software installed on their machines. Especially when they have thousands of them.

Listen to this: THE KERNEL AND THE OPERATING SYSTEM ARE NOT SACRICINT - every product developer has the right to modify the system for the needs of his or her product. If you disagree, perhaps you are a kernel developer who has grown too comfortable with your religion. We aren’t slaves to the machine, even if the software we install enslaves the machine.

The right?! I think that’s a strong statement ;). Beyond that, it’s actually a dangerous attitude. The right to modify my operating system is granted to software by consumers. It can be taken away. Vendors should tell us what they are doing so we can make an informed decision as to whether or not we should buy their software.

The deeper applications go into the operating system, the greater the risk. We should be encouraging developers to not muck with the kernel any more than they absolutely have to. I am tired enough of having vulnerabilities that give attackers SYSTEM privileges, do we really need more ring0 vulnerabilities?

When the software we install hides, or installs rootkits for attackers “in advance”, we then become slaves to that software. Software that installs rootkits that modify the system in a way that is opaque to the administrator is a terrible idea. What happens when one of the many pieces of security software that is ending up on machines these days detects valid software as being a rootkit and quarantines it? Doesn’t that happen enough already?

6 Comments so far

  • Thomas Ptacek

    July 17th, 2006 6:30 pm

    Someone has to make the case for how a rootkit makes anti-malware “more effective”. And they have to do that without defining the term “rootkit” down to the point where it includes virtualization in general.

  • hoglund

    July 17th, 2006 9:08 pm

    Trust isn’t based on the technology used. You trust your own code don’t you? After all, you did write it? Or, someone you trusted wrote it? There is some inherent trust in, say, Symantec, when you install their software, right? Do you really believe that using similar technology implies similar intent of the user? You probably are for gun control too? BTW, I have always maintained the concept of one-rootkit one-system. I agree with you that reliability suffers when multiple programs (lets just call them programs for the moment, OK?) try to use undocumented methods to interface w/ the OS (for example, rootkits, firewalls, debugging tools). If the administrator isn’t given the choice to uninstall said program, then the term “administrator” needs to be decoupled from “authority”. So, my point still holds - if the authority allows it, then where is the problem? And you honestly think developers don’t have the *right* to use undocumented, unsupported features of the OS?? Wow - all I can say is - I don’t feel that way, not at all. I won’t be signing up for that. You say that makes the software opaque to the administrator, but let me posit that ALL software is opaque to the administrator – furthermore, they LIKE it that way. They aren’t reverse engineers. They want the stuff to work as advertised and not crash while doing it. And in regards to bugs, all developers are to blame for those, not just vendors. You are right, of course, that you should have the choice. Just as I pointed out very clearly in my original post, you have the right to install or uninstall a product on your precious operating system. If you don’t trust the vendor to make good, then don’t install their code. I make that choice all the time. There are vendors I refuse to use, and programs that I loathe (from personal experience w/ them or knowledge about their bug loads). I don’t carry a rootkit bible – although if I could write one I would – I just don’t think there is enough material. I am just standing up and stating what I believe, I’m sorry you don’t agree – you aren’t the first and won’t be the last. Oh, and Ptacek, I (actually Jamie and I) have formally defined what we are talking about, and it’s not virtualization, which can be read on one of the very blog postings that Dave is apparently responding to here. You can read it yourself at: http://www.rootkit.com/blog.php?newsid=440 and more of my opinions on this matter are posted as a news item at http://www.rootkit.com/newsread.php?newsid=504 .

    Cheers,
    -G

  • Thomas Ptacek

    July 17th, 2006 9:44 pm

    Greg, vendors aren’t normally allowed to install kernel debugging tools either.

  • Dave G.

    July 18th, 2006 10:18 am

    I think there is some confusion here. For me, this isn’t about rights. This is about what’s best for industry. This is less about whether I trust Symantec to ‘do the right thing’ with a rootkit and more to do with the practical impact of having one preinstalled on a system. Additionally, by telling the industry that this is ok, we are just asking for a ton of reliability problems. Once it’s accepted practice, more and more vendors start installing rootkits by default. I am not against rootkit technoloogy in commercial software because I think it’s morally wrong. I am against it because I don’t think it makes much sense. How do you propose to enforce a one rootkit, one system rule?

    ps: The rootkit bible comment wasn’t a slam, it was a plug :)

  • Josh Daymont

    July 18th, 2006 12:02 pm

    This seems like a good time for me to weight in on the subject with the declaration that I will not take any sides in this argument until another great security industry debate is resolved: tastes great or less filling

  • ivan

    July 18th, 2006 11:37 pm

    what’s best or the industry? you gotta be kidding!
    what’s best is what helps the industry to grow revenues (and not necesarilly decrease cogs)

    the fact is that every AV vendor out there installs a bunch of crap in kernel without really telling anyone what is going on. And most of these kernel stuff is hostile to other kernel stuff, trying to enforce the “one kernel, one av” principle that Greg replaces with a reference to rooktkits.

    If I were against rootkit technology (I haven’t made up my mind sorry) it would be because by its very nature it fosters secrecy and lack of transparency to the user, disregarding of what the technology is used for (attack, defense, neutral).
    Proposing rootkits as a valid/legitimate security mechanism is a plea in favor of security by obscurity. On principle I don’t subscribe to that.

    • Leave a reply