The backdooring of SquirrelMail

SquirrelMail advertises itself as "webmail for nuts." It is a PHP-based package which is in wide use; most distributions include a SquirrelMail package. Security problems in SquirrelMail are certainly not unheard-of; even so, the announcement that the source distribution for version 1.4.12 had been compromised raised some eyebrows. Initially the project downplayed the problem:

It only took one day, though, before Uwe Schindler pointed out that, in fact, the changes made to the source opened a remote-execution back door into deployed SquirrelMail systems. Somewhere along the way, the project discovered that the 1.4.11 release had also been tampered with. The SquirrelMail developers released version 1.4.13 to close the vulnerabilities.

There have not been any public reports of systems being compromised by way of this vulnerability. Additionally, it would appear that all of the distributors which shipped the affected versions got their version of the code prior to the attack. So the episode would appear to have ended reasonably well - as far as we know. There are some lessons that one can take from this attack, though.

The downplaying of the problem initially was a potentially fatal mistake. If somebody has been tampering with the sources, there is no excuse not to go into red-alert mode immediately, even if the developers involved do not understand the attack. When a project has been compromised at such a fundamental level, one must assume the worst.

The compromise was discovered after a user noticed that the tarballs on the download site did not match the posted MD5 checksums. Your editor suspects that very few of us actually verify checksums in the packages they take from the net. Doing so more often would be a good exercise in software hygiene for all of us.

That said, the project got lucky this time around. A smarter attacker would have replaced the checksums after adding the back door, making the changes harder to detect. Longer-term, the increasing doubts about the security of MD5 suggest that relying on it to detect changes to tarballs might not be entirely safe. Far better to use public-key signatures; they should have a longer shelf life, and, if the keys are managed properly, they are impossible to replace. It seems that the project has posted GPG signatures for 1.4.13, though the Wayback Machine suggests that this is a recent practice. Your editor was unable to find the public key needed to verify the signatures.

The modifications to the tarballs were done using a compromised developer's account. The specific changes made were not put into the SquirrelMail source repository. The project has said nothing, though, about what has been done to ensure that no other changes were made there. Some sort of statement from the project along these lines would be most reassuring to SquirrelMail's users.

Perhaps the most encouraging conclusion, though, is this: there have been several attempts to compromise source distributions over the years. Many of them have succeeded in getting bad code into high-profile packages. But none of these attacks - so far as we know - have escaped detection for any significant period of time, and none of them have led to any sort of wide-scale exploit. As a whole, we would appear to be reasonably resistant to this kind of attack, even when the front-line defenses fail. With luck, and continued vigilance, that trend will continue. Both will be required, though: there is no doubt that the attackers will keep trying.

Index entries for this article
Security	Backdoors
Security	Web application flaws

---

to post comments

And, also add the size of the files.  Might as well make things even a little more difficult
to the attacker by reducing even more the set of possible streams he can use...

Sadly it's been shown that using both hashes doesn't increase the work factor by very much.

One has to take into effect that when most times people say that it doesn't increase the work
load they are talking about order of magnitude things... and that it doesn't increase the
factor if certain factors are true. Finding a match between SHA1 and 'pull out unrelated of my
butt' Hash might only extend the time to see it by months or years versus decades... and is
not non-trivial.. may only be 'trivial' to the mathmetician who was testing it against a
theoretical 10^20 years to find a match.

Wouldn't it be helpful if the <a> tag could include a hash/signature (I'll refrain from
suggesting which one), that the browser could use to verify the download automatically?

Whilst that wouldn't plug the hole completely (the attacker may be able to compromise both the
web site and the tarball), from the reading of this article it would have meant all
downloaders would have been alerted to the compromise.

I've been proposing this for some years now - http://www.gerv.net/security/link-fingerprints/
- and we even got as far as a draft RFC but it received a chilly reception from the IETF. :-(

Gerv

I wanted to make it part of the URI syntax because then it could be used even in non-HTML
contexts - for example, in plain-text emails. But yes, perhaps if that's not going to be
achievable, we could get a significant proportion of the benefits by going via WHAT-WG or W3C
and adding a new attribute to HTML.

Gerv

I uploaded a package this morning -- zfec v1.3.1.  If give the following hyperlink to the
"easy_install" tool, as in:

easy_install
http://pypi.python.org/packages/source/z/zfec/zfec-1.3.1....

Then easy_install will check that the md5 fingerprint of the resulting tarball matches the one
in the URL fragment and stop with an error message if they don't match.

Exactly. How do we know that someone didn't crack the workstation of an apache or firefox
developer, didn't slip a backdoor into the code and currently isn't waiting for the highest
bidder to sell the access to these computers? Yes, I know, there is peer review, but it
obviously didn't work in the case of SquirrelMail...

 The quoted section of the initial announcement is a little worrying: 
compromising the release packages involved effort on someone's part and, 
as a motivation for that effort, introducing an exploitable vulnerability 
is a far, _far_ likelier goal that adding a random bug. So the initial 
position should probably be to assume that whoever made the changes 
intended them to be exploitable and therefore to act as though there 
were a compromise introduced until those changes are fully understood. 
That is, the healthy initial reaction is "what have I missed?" rather 
than "this doesn't seem to do anything".

The trouble is that the checksums and source files tend to be on the same server -- so if you
can 'fix' one, you can fix the other.

However, as Jon says: most people don't bother to check check sums, if they were held on
another machine then even fewer would bother. Whatever is done has to be easy to use.

I was just in the process of updating a little project of mine, and had decided on an extra
bit of security for the published hashes, when I took a break and read lwn.

What I'll do with my project is to run a daily script comparing the remote pages (the ones
containing hashes) with the local copies. Should a "diff" happen, all hell will break loose
here and the remote tarballs pulled asap.

Mats Johannesson