2008-11-16
Checking systems with RPM verification (part 2)
There are at least two useful tricks beyond basic RPM verification that can be useful in some situations.
The first is that RPM's verification doesn't have to use the system
database; instead it can get the MD5 checksums from a .rpm itself.
This is done with 'rpm -V -p <rpm>'. Naturally the .rpm had better
be the same version that's installed, and of course prelinking is
still an issue if you don't trust the system
that much.
The second is RPM's --root argument, which causes it to do all its
work against a filesystem tree located somewhere other than /. This
is useful if you want to verify something that you're not currently
running, whether for disaster recovery or forensic analysis. This can be
combined with the first trick to verify a system where you're dubious
about both the system infrastructure and the version of the RPM database
that the system has.
If you have to do this in the presence of prelinking, I think that
for most people the best thing you can do is to un-prelink the system
and then verify what's left (with __prelink_undo_cmd set to
something like /bin/cat, just in case). A really clever attacker
might still be able to hide things, but fortunately those are rare.
(If I had to do better than this, I'd create a custom version of
prelink that has a --root argument and then hard-code it as the
__prelink_undo_cmd when I was doing the verification.)
As a general disclaimer for people thinking about going to this much work: note that you should always bear in mind the basic principle of analyzing compromised machines. You can't really trust anything running on the machine itself; to the extent that you do, you are gambling that your attacker is not clever. In many cases you will win this gamble, because I don't think that very many cracker toolkits are exploiting RPM prelinking or bothering to compromise RPM and its database of checksums. However, it only takes one cracker to put together a toolkit that does it, and sooner or later someone will.
(Your odds are significantly worse if you believe that someone is specifically targeting RPM-based distributions with their attacks. I would be especially nervous about a package targeted specifically at Red Hat Enterprise Linux machines.)
A hint for email providers
Here is something that I shouldn't have to say to all sorts of email providers but apparently need to:
If someone says that you have spammed them, your first reaction should not be to proclaim that you are a legitimate business (and that you don't spam and that you have strong policies and so on); your first reaction should be to profusely apologize and attempt to open a dialog so that you can fix the situation.
There are a number of reasons for this, assuming that you are a legitimate business and actually want to deal with any spam problem that you have. First, any public comments are the tip of an iceberg of your problem; for every person who says something in public that you can find there are probably at least ten who have just quietly done something about your email. This means that you have a bigger problem than you can see and you need to do something about it fast, and so you actually need the information that this person might be able to provide if you approach them nicely.
The second reason is that it is good public relations. Regardless of what actually happened, you have done something that annoyed this person. If you go around proclaiming your innocence, you are coming very close to also calling them a liar, which rarely goes down well with the already irritated; you are unlikely to do anything except harden their unfavorable reaction to you. By contrast, apologizing and working to solve the situation both acknowledges their situation as real and is more likely to leave them feeling positively inclined towards you.
(Hint: it does not matter if you did not actually, technically, spam them. What matters is that you left someone with the belief that you did.)
The final reason is that it doesn't work. Regardless of the facts of your specific case, this particular well is already poisoned; too many spammers have spent too much time proclaiming their innocence for anyone to believe you. This includes bystanders, and remember that under almost all situations, the person you are trying to 'correct' can have the last word if they want to.
(This general advice is applicable in situations beyond spam, of course. For example, technical support.)