Q: Very Confused

There are no Mac rootkits.

It is true. There are a handful of "Trojan Horses" for MacOS X. But those are malicious programs that you must download and install yourself. Sometimes they try to be clever to trick you into running them - "You need this codec to play the video" - but you still have to install it and provide your admin password in order for them to work. Any virus scanner you run on the Mac will check for those 5 or 6 malicious Mac programs and the more than one million viruses that exist for Windows. Your chances of getting some kind of malicious Mac program are therefore greater than one in a million - but not much greater.

One of the most serious Mac trojans is the DNSChanger that redirects all of your web requests to ads or p**n. It can be removed in a few minutes. There is nothing on the Mac that even approaches a rootkit.

Get rid of your Mac anti-virus software. Chances are, it does more harm than good.

First off and in all seriousness, how current are your Mac OS X backups?  Not because I think you have a problem (and I don't), but because backups are both part of your normal operations and part of recovering from a breach.  If your backups aren't current, then go work on that right now.  (Folks can get dazzled and simply forget to have and to keep current and keep deep backups.)

It is exceedingly unlikely you have a rootkit, and the tool you are using here can show false positives.

The paths I've seen used for all of the Mac breaches I've worked have been weak passwords, disabled or wide-open security, or folks that were installing stuff from untrusted sources.  Trojans.  Stuff that they knew they shouldn't be loading, in discussions.  (This is also where the Mac App store approach is headed, too.  Curation.  To help reduce the likelihood that folks will be loading random cruft.)

The /dev stuff is where the devices reside in Mac OS X and most Unix systems.  Specifically, those /dev/fd entries are file descriptor devices.  They're not directories.  /dev/fd/0, /dev/fd/1 and /dev/fd/2 are stdin, stdout and stderr channels, and the others are file system entries for whatever else happens to be active; that's a virtual view into the current process's channels.  Most commonly encountered when you're noodling around in bash scripts.

And that rootkit tool you're running?  Not to make you paranoid, but do you trust the package?  It has been authenticated for and now has root access, after all.  These sorts of security tools are certainly good and classic means for installing trojans, and both ignorance and fear and greed have been used to get users to load their trojans.

Review the source code and see what the details of the failed test were.  I suspect spurious.  Barring cases where you've been exploring areas of the 'net you probably should not (and downloading and loading and authenticating questionable bits), I suspect you're wasting your time looking for rootkits.  Work on your backups, on improving your passwords and on your operational security.

The chances that you have a rootkit? Exceedingly slim.

/dev/fd/nnn is a pseudo directory that contains the current list of open file system file descriptors (0, 1, 2, 3, ...) for a process.  Each process sess ONLY their own open file descriptors.

when you looked at /dev/fd/* all you see are the open file descriptors for the program you used to look at /dev/fd/*, so of course would not have seen what Rootkit hunter saw, as only Rootkit hunter can see its open file descriptors.

0 is standard input

1 is standard output

2 is standard error

after that they can be anything include the executable program's file, any data files currently opened, any current network connections, etc... Basically any I/O operation involved an open file descriptor.

So a program that reports something suspecious about /dev/fd/nnn is reporting that it thinks itself to be suspecious.  Or to put it another way, the program is "Brain Dead" and the authors did not bother to learn about the operating system they wrote the program for, and did not test their program very well, or they would have seen this issue for themselves.

Following on from BobHarris' excellent response, I'd still be concerned - since any 'competent' rootkit hunter author would know these issues it raises a huge doubt in my mind as to the veracity and authenticity of the tool you used.

This almost stinks of the 'brain-dead' 'anti-virus' tools that spew across the web alerting you to all kinds of viruses, malware, etc. that can only infect Windows machines, even though you're running a Mac. More often than not these fake tools are nothing more than a front-end to get you to install their 'security' software which actually installs more malware.

Since this tool clearly doesn't understand the point of /dev/fd/ it makes me wonder whether it's legitimate at all, and what else it might have installed under the guise of checking your system.

Look carefully at the source of the tool you used. Is it legitimate? If you're not sure, post a link so others can't verify.

Making a backup of your system after it's been compromised doesn't help much.

Your post does a good job of highlighting the dangers of security paranoia on a Mac.

One would think that a tool designed for Linux would be smart enough not to scan the device tree. Apparently, not this one. One would also think it comes with a database of known good MacOS X system files and hashes - not this one. The tool hasn't been updated for a couple of years. At a minimum, it could only check one particular version of 10.5. Some of the files it checks are Linux files that don't even exist on MacOS X. The original rootkit hunter is GPL. However, I can find no source to the Mac version. That is a violation of the GPL. I inspected the installer and it does appear to contain the original rootkit hunter. It also contains a compiled executable that requires administrator privileges. You are giving root access to your computer to some person you've never met, who lives in another country, writes rootkit programs, and violates the GPL by not publishing the source to said program so you can inspect it.

The only danger from malware on a Mac is from trojan horses where you hand over your admin password in order to install some tool that is supposed to provide some benefit, but really just installs its own payload. That is exactly what you have done.

To be honest, this rootkit hunter program is probably safe and probably doesn't install a rootkit itself. Of course, since the source isn't available, there is no way for me to say for sure. However, it has been sitting out there for years, so it probably isn't malicious - but it definitely isn't useful either.

Actually, rkhunter is a fairly well respected tool (as is chkrootkit) by security auditors.  The problem here is summed up in a seemingly innocuous line from the article to which richardfromhinckley refers:

{code}

I wouldn’t recommend trying to get rkhunter installed on your Mac since it will require some enhanced Terminal-fu.

{code}

rkhunter is a generic *nix security tool.  The only proper way to get it to work is to install and run it on a system known to be secure and then "tweak" it's output to account for the ways that OS X diverges from a standard BSD unix base.  For example, it normally gives a warning about a potential rootkit infection (the name of the specific rootkit escapes me off-hand) based on the existence of the files /etc/sshd_config and /etc/ssh_host_key.  The issue here is that those are locations this rootkit actually uses, and the standard locations for those files on a normal BSD unix system are /etc/ssh/sshd_config and /etc/ssh/ssh_host_key.  There is a standard way of dealing with this issue involving whitelisting the specific files and adding a properties check to ensure they aren't replaced later.  Similarly, if there are no system startup files (/etc/rc.d and so on) rkhunter will complain.  So you deal with it by configuring the program not to expect startup files.

There are ways to deal with all the OS X specific differences from a standard unix base, by modifying the configuration files.

However, rkhunter is a tool for professionals (ie, people who understand how the operating systems they are auditing work, how the tool works and how to use the command line properly).  I suspect the problem here is with the "OS X Rootkit Hunter" wrapper, not rkhunter.  And with that article, since it glosses over the difficulties of using rkhunter by making it seem as though the GUI tool will magically make those difficulties vanish.

And for what it's worth, I have rkhunter installed and properly configured, and have never had any warnings about /dev/fd or any of the file descriptors it holds.

My general advice, however, is to stay away from professional security and auditing tools, unless you actually want to go to the trouble of learning how to use them properly.  And be wary of wrappers that GUI-fy those tools in an attempt to insulate you from their complexity - often it can't be done without crippling the tool, as they are complex only from a certain point of view.

g_wolfman wrote:

 

Actually, rkhunter is a fairly well respected tool (as is chkrootkit) by security auditors.  The problem here is summed up in a seemingly innocuous line from the article to which richardfromhinckley refers:

 

{code}

I wouldn’t recommend trying to get rkhunter installed on your Mac since it will require some enhanced Terminal-fu.

{code}

But that is the original rkhunter. If you are Terminal-savvy you can read the scripts to see exactly what it does. You can't do that with the MacOS X version as part of it is a compiled executable. I sincerely doubt it is anything more than a compiled GUI wrapper, but this is security and rootkits we are talking about. To verify a system is free of malware requires a chain of trust and this is a big red flag.

Also, the "code" tags are deprecated in the new Apple Support Communities. The best solution is to create a post with the quotes and other constructs you want to use and make an archive of that. Then you can paste the content you need directly into the editor window.

I think we're in violent agreement on this issue...

In fact there's only one thing I think worse than programs like this "OS X Rootkit Hunter" that try and make computer security appear so simple and easy that people ignore real security issues.  And that's bloggers like the one hawking "OS X Rootkit Hunter" that don't seem to understand the concepts of a threat/risk assessment or risk mitigation strategies.

As for code tags...hmm, yes, well apparently I missed that.  So is there a quick and easy way of indenting quoted blocks at all in the new forum?  Or is it archived posts and/or straight html tags only?

EDIT:  Never mind, I just found the advanced editor link...easy enough...

Message was edited by: g_wolfman

It is not even that. There is no issue (configuration or security) at all.