Wandering Thoughts archives

There is a balance between optimism and paranoia for compromised machines

There is an important proviso for the first principle of analyzing compromised machines: in practice, most attacks are not that good or that thorough. In real life, as opposed to mathematically correct security advice, there is a tradeoff between your caution level and the amount of work you have to do (either in analyzing a machine or in reinstalling it) and sometimes it is appropriate to take some risk in exchange for doing less work.

The truly paranoid will reinstall machines from scratch (and never mind the disruption) if there is a chance of system compromise, such as you know that an account has been compromised. You do this because you make the most cautious assumptions possible; assume that the attacker knows some way of getting root that is undetected and unpatched, you assume that they were sophisticated and successfully hidden their traces, and so on. Even if you detect something, you can never assume that you have detected everything.

(At this level of paranoia, you should probably be using two factor authentication with smartcards and randomly reinstalling machines every so often, just in case. I suspect that few people are this paranoid.)

In my world it is often appropriate to be more optimistic about the lack of competence about our attackers (especially if we have detected the compromise in some obvious way, such as noticing a password cracker eating CPU on a login server). So I wind up doing things like simple system verification, and then conclude that the absence of evidence is evidence of absence (to put it one way), despite the zeroth law.

(This is another of the fuzzy compromises necessary for real computer security.)

A realization about the recent Red Hat Enterprise security issue

For those people who haven't heard, Red Hat recently suffered a security breach that allowed an attacker to get some bogus OpenSSH RPM packages signed as valid Red Hat Enterprise Linux packages. Red Hat says that the packages were never added to RHN, the update system for Red Hat Enterprise, but presumably the attacker has copies.

(That the package signing is separate from RHN makes sense to me, since I expect that Red Hat needs to sign various sorts of RPMs for testing purposes well before they may get put into general release in RHN.)

This leaves one with the question of what the attacker can do with these packages. It recently struck me that these packages enable an unpleasant perfect conjunction of three or four security issues, like so:

• as the attacker, you use Dan Kaminsky's DNS bug to persuade your victim system that your server is the RHN update server.

• you exploit an apparent vulnerability in yum's SSL certificate verification code to have your server successfully masquerade as the RHN update server.

  (The apparent vulnerability is mentioned, without any details, in the Attacks on Package Managers FAQ. It's possible that whatever it is, it's not exploitable by an attacker in this way.)

• you serve up package metadata that lists these compromised OpenSSH packages as available updates (and the most current version of OpenSSH).

• because these OpenSSH packages have valid signatures, they will pass all of yum's checks and be installed. Game over.

I suspect that this is one reason that Red Hat has issued a new OpenSSH update; once you install Red Hat's update, these bogus packages will no longer be seen as more recent versions of OpenSSH. Even if the attacker manages to feed them to yum under false pretenses (eg, by claiming in the metadata that they have a different version number), I believe that yum will reject them as older than the installed versions.

(Disclaimer: that's a belief, not a certainty; I have not tested it.)

I suppose this makes a third approach to exploiting unsigned repository metadata.