As many here will already know, kernel.org (one of the websites where Debian users can obtain iso images for installing Debian systems) has been breached, and some software available there has apparently been infected with the Phalanx trojan. See

• Kernel.org Linux repository rooted in hack attack: Rootkit not detected for 17 days
  Dan Goodin, The Register, 31 August 2011
  http://www.theregister.co.uk/2011/08...curity_breach/
• Hackers break into Linux kernel home: Gained root access and deployed Trojans
  Lucian Constantin, The Inquirer, 1 September 2011
  http://www.theinquirer.net/inquirer/...ux-kernel-home
• https://www.linuxquestions.org/quest...5/#post4459320

I run a Debian Lenny system. In early July 2011 I

• upgraded to v. 5.10.0-19lenny5 of perl, perl-base. perl-modules, libperl5.10 (source 128.31.0.36 steffani.debian.org)
• upgraded to v. 7.18.2-8lenny5 of curl, libcurl3, libcurl3-gnutils (source 128.101.240.212 debian-mirror.mirror.umn.edu)

Since then rkhunter has given warnings for perl and curl:
(Both stored hash and inode have changed.)

I have assumed that this is an innocuous glitch due to rkhunter not knowing about the Debian changes, but the recently revealed breach at kernel.org (which is among other things a website where users can obtain upgrades for debs) has impelled me to inquire about this discrepancy. rkhunter does not find evidence of the Phalanx trojan on my system.

I always upgrade promptly and note which repo I use for each upgrade. Fortunately, I have not used the kernel.org repository during the period 1 July 2011 to present, but if the curl and perl packages in Debian isos offered at kernel.org turn out to have been tampered with, the above information may be useful. In this case I will provide the hashes.

Yes, it was posted today already.


The name is Phalanx2 and not Phalanx. Phalanx2 is a rootkit and not a trojan. Rootkits usually do not "infect" stuff (and if any binaries in the kit are contaminated already then it'll be with RST and not much else).


That may be so but if these changes occurred early July 2011 then asking about things two months later means you're not responding promptly to changes. Kind of begs the question why you would run verification in the first place?..


Rootkit Hunter is as distro-agnostic as possible so you mean local changes. And don't assume but make certain. See Rootkit Hunter documentation, the FAQ: 4.4) After performing some updates, all, or some, binaries in the file properties checks are marked with a 'Warning'.


No, if the ISOs changed then the ISOs hash changed and if it was cryptographically signed the signature shouldn't match either. In the absence of anything on that level to compare with, extracting and comparing package contents with upstream should provide evidence.

You are the expert, and I was posting in haste. Thanks for the correction. I agree that these distinctions are important.

Sorry that in my rush yesterday, I didn't state this clearly, but that's why I suspected that the warnings were probably innocuous. I run tripwire and rkhunter immediately after each update so it was clear why rkhunter thought something had changed: something had. I ran rkhunter --update and afterwards still got the warning, so I tentatively concluded that rkhunter simply had no way of knowing about the Debian changes to curl and perl.

Here's what I would have said yesterday if I'd had time: the security updates to Debian Lenny (oldstable) which caused the Rkhunter warnings are
http://lists.debian.org/debian-secur.../msg00143.html
http://lists.debian.org/debian-secur.../msg00138.html

Cause you're the goto guy for RkHunter but you and I seem to suffer from chronic miscommunication, and frankly you can be kinda scary when you become frustrated by my requests for advice/assistance.

Anyway, I think you are saying that the warnings are probably innocuous, but that you can't be sure without getting the source code from the Debian repos. Or the binaries installed on my system?

There's this but I don't even know what to look for:

rkhunter normally gives false positives on brand new 5 min. old installs
normally it is the /bin and /usr/bin links or a script that is used to launch the program .

Not sure I understand. But the question seems to be: should I be concerned that months later I am still getting the warnings? Any other Debian users getting similar warnings?

Auch. 'man rkhunter' tells you that "--update" is for checking for online updates and "--propupd" for updating its data file of stored values.


Thanks for your candor.


What I'm trying to say is that warnings can only be judged innocuous after investigation. If the cause is an update then you will find the binaries' hashes match with those of a known good copy from a trusted repo mirror.

I think you are saying that what I should have done back in July is to download... the perl and curl binaries (?)... or a tarball with the source code?... from some Debian repository... perhaps using a live CD (?)... and check the hashes myself against what is given in the rkhunter log. Could you clarify?

Extra-Mile award to anyone who mentions the known genuine IP address of a specific Debian mirror as a double check. I have good reason to be constantly concerned about DNS hijacking and other surreptitious diversions. I know how to check using a remote server the IP address of what claims to be a Debian mirror... but what if my connection to that server is also diverted?

Cool, if I know how to check that the new hashes are valid, I now know how to update the rkhunter database. My bad for having overlooked that, and that's for pointing it out.

I recognize that you are potentially a source of useful information, so despite our chronic misunderstandings I value your advice, when I understand it.

Yes, you could have downloaded those packages from a known good repo mirror for comparison.

Well, at this point, who knows what might be a "known good" mirror? If kernel.org can be compromised, any mirror can be, eh?

OK, as my ordinary user I did
First surprise: my connections were torified, not neccessarily desirable in this case, but I did intend to torify downloads by my ordinary user (including, how ironic, via curl), so nice to know it sometmes works. When I upload or install as root my connections are not torified (by intention, so I can note the mirror from which I obtain each deb). That's useful to know!

The sha1 and sha256 sums given in the dsc files match the tarballs I downloaded as source. And the dsc files containing these hashes and other information are signed with GPG keys.

But the dsc signature files are not signed with any keys in the apt-keyring or any Debian keyrings or individual debian.org keys I had previously imported, and they did not belong to the persons designated as maintainers. After some digging, I found that

• the curl dsc file is signed by Ramakrishnan Muthukrishnan, who really does have connections with debian.org, but the key in question is only self-signed! So maybe it's him, maybe not, who knows?
• the perl dsc file is signed by Dominic Hargreaves, who really does have connections with debian.org, but not only is the key self-signed but some keys of (presumably) the real Hargreaves (which are signed by others) have been revoked! (Not expired.) So maybe it's him, maybe not, and maybe the revocations suggest that he takes crypto seriously as he should, and also seem to suggest that his comms may have been compromised previously, but who knows?

For what little it may be worth, the binaries I have in /usr/bin have these SHA1 and SHA256 hashes
So now what? Are you saying that I should try to compile (as my ordinary user) curl and perl and then check the hashes of these binaries? Is there any point to trying to chroot or jail that, given the fact that my root user already installed the "suspect" binaries? (Actually, maybe yes...)

And is anyone else worried by the fact that so many keys used to sign Debian related messages are self-signed only, even when the author has other valid keys which are signed by many others? (Maybe this is only a matter of convenience, and if I chase down the self signatures, I'll find that some of the keys used by the self-signing are ones signed by a dozens of others. Still, it seems to introduce another obstacle in the path of anyone who wants to check that the hashes are valid.)

Meanwhile, in my new and partially functional test installation of Squeeze on another PC, rkhunter is throwing up further warnings of the same kind.

Of course, I need only compare the hashes mentioned in /var/log/rkhunter.log with those mentioned in the files
curl_7.18.2-8lenny5.dsc
perl_5.10.0-19lenny5.dsc
which I obtained by running apt-get source curl, perl. And I am glad to say that they do match, so indeed it appears that the explanation is that the debs were updated but rkhunter doesn't know what "Debian" is up to. Which just leaves the matter of verifying the signing keys.

So this is where things stand:

• verified the current hashes against those given in the .dsc files (included with the source)
• found the GPG keys used to sign the ,dsc files and verified the signatures
• but still have some questions about the GPG keys used to sign the ,dsc files

And here's the procedure for investigating this kind of rkhunter warning for a binary such as /usr/bin/foo:

• Code:

  apt-get source foo

• unpack the tarballs and look at the foofile.dsc
• try running
  Code:

  gpg --verify foofile.dsc

  (if it says "Good signature", you are done, but if the key used to sign isn't in your keyring, you'll get an erorr so in that case proceed)
• search on-line to find the owner of the key and get it from a keyserver like http://keys.gnupg.net/
• if you found a textfile holding the public key, import the key into your keyring using something like
  Code:

  gpg --import keyfile

• try again
  Code:

  gpg --verify foofile.dsc

  (you should see "Good signature" from so and so, if so, you are done, if not, proceed)
• if you get a bad signature, sound the alarm!

This answers another question I had: the hashes in the .dsc files refer to the binaries, so no need to compile.

Suggested improvement for apt-get: an argument which makes it just download the isc messages so that you can check this kind of thing without having to download the entire source.

Were it not for the recent news about kernel.org, I'd probably run the rkhunter command suggested by unspawn, but as things stand, I think I should look into those keys a bit more...

Oddly enough, if the key is authentic, rkhunter was complaining about binaries which incorporated security patches; the unpatched binaries were actually the ones unsafe for use. Unless I misunderstand something, rkhunter maintainers can't update their database until the other distros patch their curl and perl packages.

The way RKH offered support for verifying files in 1.3.n differs from 1.2.n as there's no more downloadable hashes. (Maintenance of the 1.2.n hash files was a burden and community support was minimal enough for the feature to perform in a suboptimal way.) Now we leave responsibility for triggering hash updates to the user which is consistent with how say Samhain or Aide runs things. Updating hashes should be done only after verification using 0) a file integrity checker (never rely on one tool only) or 1) your distributions package management tools (that commonly means packages and not source packages).

I fear that your ability to diagnose and solve problems is complicated by your way of looking at things and with all due respect it can only be described as "convoluted".

If I gave misinformation in my previous post, please explain, clearly, what I said wrong.

If you think I gave bad advice, please explain, clearly, what you disagree with and why.

And if you're not capable of maintaining rkh, please pass it on to someone who can.

I said all that needed to be said and as clear as possible. I also advise against you phrasing things like that.


..and given what I said earlier on it would embarrass me considerably to have to respond to such a statement in a way that distracts from the actual problem we here see evidence of.