Hacker News Reader

Comment by commenter23 | Hacker News Reader

No, that's wrong.

A rootkit is the thing you install once you have root - not a way to get root initially. It usually gives the attacker a means to access the machine in the future, even if the vulnerability she used is fixed in the future.

Rootkits are designed to hide themselves. They are essentially attacker installed backdooors.

A backdoor is basically a rootkit that is part of the original software as written by the original developer. The words have different connotations (rootkit is extremely negative, backdoors slightly less).

View on HN

No, that's wrong. Wikipedia has definitions that match my own knowledge, so i'll link and quote those.

https://en.wikipedia.org/wiki/Rootkit

"A rootkit is a collection of computer software, typically malicious, designed to enable access to a computer or areas of its software that would not otherwise be allowed (for example, to an unauthorized user) while at the same time masking its existence or the existence of other software."

https://en.wikipedia.org/wiki/Backdoor_(computing)

"A backdoor is a method, often secret, of bypassing normal authentication in a product, computer system, cryptosystem or algorithm etc. Backdoors are often used for securing unauthorized remote access to a computer, or obtaining access to plaintext in cryptographic systems.

A backdoor may take the form of a hidden part of a program,[1] a separate program (e.g. Back Orifice may subvert the system through a rootkit), or may be a hardware feature.[2] Although normally surreptitiously installed, in some cases backdoors are deliberate and widely known. These kinds of backdoors might have "legitimate" uses such as providing the manufacturer with a way to restore user passwords."

No, that is really wrong. Rootkits aren't for privilege escalation, see the paragraph immediately following your quote:

"... an attacker can install it once they've obtained root or Administrator access."

Calling BO a backdoor is a major corruption of the word, as you loose the only word for describing intentionally weakened security - so that you may describe a thing which already has several more explicitly defining names: malware, trojan, dropper, etc.

The installation of the rootkit is different from its purpose. A rootkit may require a root permission to install, perhaps piggybacking on another legitimate install such as in the famous Sony BMG rootkit. Or it may use an exploit to gain root access and install.

However, once installed, the purpose is the same: To provide the attacker with root permissions. It will also typically use its access to root permissions to hide itself from detection.

> A rootkit may require a root permission to install...

This sort of phrasing is misleading. If your OS restricts security sensitive kernel functions to the root user (hint: 99% of OSes do), then it isn't "may" - it is "must". Are there wrapper scripts that run privilege escalation exploits before installing the rootkit? Yes. Doesn't that make the exploit part of the rootkit? No, they are two very different things performing two different functions and are capable of operating independent of one-another.

> ...the purpose is the same: To provide the attacker with root permissions.

No, it is to allow code to run at the same privilege level as the kernel itself. Unrestricted loadable kernel modules. Think that is a distinction without a difference? OSX disagrees, as does Windows.

Regardless, the point of a rootkit is to provide an execution context with escalated privileges. Whether that means root user, kernel space, System user is I would think depends on the specific rootkit. (Whose name, of course, points to "root" privileges.) Which was my original definition and is inline with the posted definition from Wikipedia.

Well I guess we won't come to an agreement, because it seems that whatever reason you prefer a very loose definition. For example, you just couldn't help yourself in confusing the privilege escalation point: "...context with escalated privileges." The rootkit isn't escalating anything, in the same way that LKMs, bootloaders, tracetools, or drivers don't escalate - it executes at or below its own privilege level.

I'm obviously not communicating my point well. Let's try this:

A backdoor executes in a remote machine. It allows attackers to access that machine.

A rootkit executes in a "remote" privileged context. It allows attackers to access that privileged context. It's in this context that I refer to escalation; it allows the attacker in a non-priviledged context access to a privileged context; aka escalation. And yes, the actual escalation already happened in the past, when the rootkit was installed. However, a non-priviledged user is still gaining illicit access to a privileged context at the moment that the rootkit is utilized.

Also, at this point I think we're splitting semantic hairs that don't really matter, aside from pedantry.

Well I do appreciate you trying, but I disagree with you that it is pedantry that doesn't matter. This conversation is the best possible example of why we can't allow the corruption of previously well defined words - it causes confusion for no good reason.

A backdoor doesn't need to be remote and the user isn't necessarily an attacker. It is simply a secret method of access that the designer put in place, it isn't designed for end-user use. It is almost always security through obscurity, and it is always a bad idea. It can be activated in a variety of ways: port knocking, hardcoded passwords, preinstalled remote software, shorting ground to some magic pin, an undocumented serial terminal, etc.

A rootkit doesn't need to be remote and the user isn't necessarily an attacker. It doesn't need to have any functionality for user interaction - which means no "escalation" occurs (It could simply scan memory for passwords and log them to a file). It runs above user space, and can therefor be completely hidden (but it isn't always, see DTrace). It runs with the same privileges as the OS that it is part of. That is important to keep in mind, the rootkit becomes part of the running OS - that could mean any of the OSes running in your tower (CPU, HD firmware, BIOS, etc).

Your definitions work fine in a vacuum, but they quickly fall apart in real world usage. For example, by your definition: a remotely accessible privileged service is a rootkit, because an unprivileged internet user can interact with it - accessing data and executing code in the service's privileged context. 'sudo nginx' is not a rootkit.

> A rootkit doesn't need to be remote and the user isn't necessarily an attacker.

No one said a rootkit needs to be remote. (I used "remote" in quotes just to align it to the backdoor.) And in the context of security, it is definitely an attack. If there's not a user executing unauthorized commands, then it's simply installed and authorized software.

> It doesn't need to have any functionality for user interaction...

This is true, and I can see how some of my statements were maybe a bit more specific about this than they needed to be. The point is still to give an attacker a context with elevated permissions; it need not be an interactive context.

> It runs with the same privileges as the OS that it is part of.

This I still think is overly restrictive. I don't think running in ring 0/1/2 with the kernel and drivers is a necessary component; having "root" access such that it can invoke kernel functionality necessary to achieve its goals is sufficient. Now, it may use "root" access to modify kernel files and drivers, which is perhaps what you're referring to and where the line blurs and pedantry beings. If "root" access gives you unfettered access to the system, including modifying kernel executable files, then there is basically no difference between "root" and ring 0.

> For example, by your definition: a remotely accessible privileged service is a rootkit, because an unprivileged internet user can interact with it - accessing data and executing code in the service's privileged context. 'sudo nginx' is not a rootkit.

More pedantry. Clearly intended and authorized access to a service is just normal operation. This is why I'm very explicit about the usage being unauthorized and label the user an "attacker".

I think that we're as close as we'll get to agreeing - the main contention being the "attacker" part. I'd describe Symantic's data protection product as a rootkit, regardless of who installed it. I'd say the same for the LKMs that I've installed in honeypots.

I think you are spot on for rootkit, but you are absolutely wrong on backdoor.

You say "This conversation is the best possible example of why we can't allow the corruption of previously well defined words - it causes confusion for no good reason." when YOU(and others like you) are the one corrupting the meaning of backdoor.

Backdoor has meant for ages to be a way to access a computer/program while bypassing the normal authentication method, whether added by the designer or by someone else. You are trying to redefine it to mean only methods of bypassing normal authentication added by the designer. If you find it confusing that both types of backdoor are backdoors, then make up a new word that can be considered a subtype of backdoor don't try to coop an existing word and change its meaning.

> ... whether added by the designer or by someone else.

Your exception seems to hing on the word designer. I'd describe the individual responsible placing the backdoor as the designer. So if you place a modified version of /usr/sbin/sshd, then you've designed the backdoor for that system. I see no redefinition.

Your post further up in the thread:

> Calling BO a backdoor is a major corruption of the word, as you loose the only word for describing intentionally weakened security - so that you may describe a thing which already has several more explicitly defining names: malware, trojan, dropper, etc.

Thinking in that context, it sounded like you were arguing further for the fact that backdoors should only be describing intentionally weakened security. Have you changed your mind about that?

> Have you changed your mind about that?

No. Unlike a rootkit, context really matters in the case of a backdoor - not so much the implementation means. BO is no more a backdoor than vnc or sshd. Now if Dell decides to secretly package BO in their product line, then it is a backdoor.

> ...backdoors should only be describing intentionally weakened security.

I can't think of a backdoor that does not meet that description, do you have anything in mind?

There are too many "No, that's wrong"'s here for a bunch of people that aren't getting this quite correct. You do not need root access to install a rootkit, you simply need to exploit a security flaw that allows you to install, run, and avoid detection. This is easiest done by modifying the host to disable it's ability to even find you on the device. This is much more difficult on modern systems, so for most modern systems, they're installed as trojans using the privilege escalation of another application or install.

The connotation difference is the difference between getting hit with a 10mm and a 9mm. Negligible, as it's leaving a hole that you really don't want there.

Reply on news.ycombinator.com