| |||||||||||||||||||
SquirrelMail 1.4.13 released - older versions compromised
All, Due to the package compromise of 1.4.11, and 1.4.12, we are forced to release 1.4.13 to ensure no confusions. While initial review didn't uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim's server. This could grant the attacker the ability to deploy further code on the victim's server. We *STRONGLY* advise all users of 1.4.11, and 1.4.12 upgrade immediately. Package MD5s ============ 1a1bdad6245aaabcdd23d9402acb388e squirrelmail-1.4.13.tar.bz2 51ddd67a7ff9272f5a6e1da0b9dfbf18 squirrelmail-1.4.13.tar.gz ed8871a693cc57d5a0d511f7b89f8781 squirrelmail-1.4.13.zip We apologies for the inconvenience this may have caused. -- Happy SquirrelMailing! The SquirrelMail Development Team (Log in to post comments)
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 15, 2007 16:40 UTC (Sat) by vmole (guest, #111) [Link] Uh, it looks like they *do* think there is possibility of exploit, now. Perhaps the summary was based on a previous notice?
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 15, 2007 16:41 UTC (Sat) by nosnilmot (subscriber, #746) [Link] The development version 1.5.1 is compromised too, see here
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 15, 2007 18:32 UTC (Sat) by nirik (subscriber, #71) [Link] FYI, fedora was shipping 1.4.11 in F8 and rawhide, but the source for this version was fetched before the compromise, so that version in fedora is NOT subject to this compromise. In any case 1.4.13 has been pushed out as an update.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 15, 2007 22:16 UTC (Sat) by bangert (subscriber, #28342) [Link] thats actually great to see - then there is no ambiguity as to whether fedora is vulnerable or not. (red) hat's off to the security devs.. :)
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 4:55 UTC (Mon) by wahern (subscriber, #37304) [Link] Why check the MD5 sums? Its trivial to find a collision, so that's sort of useless if you're trying to keep peace of mind wrt to such tampering. (NB. This is tar we're talking about here; appending the random data necessary for a collision makes the attack exceptionally trivial.) I'm baffled why people haven't switch to SHA-1 or better. MD5 has been broken for quite awhile now. Maybe Slashdot needs to send out a memo again.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 6:40 UTC (Mon) by njs (guest, #40338) [Link] AFAIK all the current attacks on MD5 still require that the bad guy gets to pick *both* files. Presumably we can trust that the people posting this security advisory are not auditing and then hashing a file that was supplied by a "bad guy", but are instead working from known-good sources -- so their hashes should be safe to use. That said... seriously, everyone should be moving to SHA-256, just cuz. Convenient access to SHA-1 (in the form of sha1sum) is probably still more widespread, though, and even it isn't everywhere...
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 16:52 UTC (Mon) by wahern (subscriber, #37304) [Link] It's a tarball. The attacker can insert any random data he pleases in creating the collision.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 18:03 UTC (Mon) by proski (subscriber, #104) [Link] I'm afraid you don't get it. Saying that the attacker must pick both files means that the attacker would need to influence the original file in addition to the one created by the attacker. If the attacker can add random data to the original tarball, we have a bigger problem, and the checksum is irrelevant.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 11:14 UTC (Mon) by epa (subscriber, #39769) [Link] If MD5 is so trivial to attack, please demonstrate it by posting another comment with the same MD5 sum as this one but different content.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 12:43 UTC (Mon) by tetromino (subscriber, #33846) [Link] It's not enough to find a collision. The problem is finding a collision that has a similar file size, consists of grammatically valid PHP that looks reasonable to a casual human inspector, and has the same functionality as the old code (modulo backdoor). AFAIK, doing all that, especially the part about making the result look reasonable to a casual human reader, is quite hard. All MD5 collisions I've seen so far were very contrived toy examples.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 17:14 UTC (Mon) by wahern (subscriber, #37304) [Link] The constraint that it must "look reasonable to a casual human inspector" doesn't make sense. The point of the checksum is that you can download the source code and trust it WITHOUT having to inspect it. Indeed, the point of the checksum is that you trust the maintainers, and the checksum serves to link that trust with the tarball, with the presumption that the source code as last checked by the maintainers was what they checksummed. Also, we're dealing with tar+gzip+PHP code. Certainly it would be completely trivial to append arbitrary binary data to the tar file which may or may not (depending on the tar implementation) give a warning when unpacking. I'm not even going to bother analyzing this, because its pointless; an attacker need only find one avenue which meets his criteria. As for file size. This may or may not pose a problem. Certainly from a practical standpoint I doubt it. This is a relatively huge tarball. The requisite additional data is at most 512 bits, IIRC--the internal block size of MD5--maybe less. People who manually download the tarball--and bother to check the hash--will also likely ignore the file size, and rightly so. Any secure cryptographic algorithm isn't sensitive to the input size; if it is, its not secure, by definition. I'm not familiar enough with the weakness of MD5 to judge the complexity of an attack which doesn't just use a suffix. It may be simply slightly marginally more difficult to find a collision if you modify the tail instead of appending; I dunno. Point is, the MD5 checksum is useless, because you cannot trust it anymore.
Point is - you know nothing about cryptograpy, right ? Posted Dec 17, 2007 22:46 UTC (Mon) by khim (subscriber, #9252) [Link] I'm not familiar enough with the weakness of MD5 to judge the complexity of an attack which doesn't just use a suffix. It may be simply slightly marginally more difficult to find a collision if you modify the tail instead of appending; I dunno. It's quite easy to find a collision if you can just modify something in the middle of file (like piece of documentation noone cares about or just some picture). But all such attacks will only work if "black hat" can alter the tarball after it's created and official signature is created. If "black hat" can alter your tarball at this stage then you have a lot of much bigger problems then just MD5 collision: he or she can just add backdoor directly to source, create tarball and sign it - why bother with MD5 collisions at all ?
Point is - you know nothing about cryptograpy, right ? Posted Dec 18, 2007 6:33 UTC (Tue) by njs (guest, #40338) [Link] >if "black hat" can alter the tarball after it's created and official signature is created. I think you mean, "after [the tarball] is created *but before* the official signature is created". I.e., they need to perform some sort of complicated swaparoo on the people doing the security announcement, and if you can do that, then you don't need a hash collision. MD5's weaknesses are just completely irrelevant to this use case. Maybe if we try another way of explaining... when people say MD5 is broken, what that means (for now) is that I can: take that tarball from the website with hash A, and then use it to create two new, different tarballs, that have the same hash B. Critically, A and B will be different (and I can't pick what B will be ahead of time). So: there are *three* files here: 1) the original, valid tarball, which has hash A, 2) one of my "evil" "copies", which has hash B, 3) the other one of my "evil" "copies", which also has hash B. The result is that if you have a file with hash B, you don't know whether that's file (2) or (3) above, but if you have a file with hash A, then you can be certain that it is file (1). The security announcement is there to tell you what hash A is.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 18, 2007 2:59 UTC (Tue) by tetromino (subscriber, #33846) [Link] > The constraint that it must "look reasonable to a casual human inspector" doesn't make sense. The constraint makes sense in the specific context of a php script. Too many times, I have been bitten by an update to a webapp that broke my customized setup. Therefore, whenever I install an update for a webapp, I look at the diff. Now, I am not a php expert and I don't analyze it in detail, so it's quite likely that I will miss a subtle backdoor. However, if I see 100000 lines of garbage that were introduced just to make the md5 sums coincide, I will become extremely suspicious. I am sure thousands of other people who perform due diligence when installing updates will notice the same thing.
SquirrelMail 1.4.13 released - older versions compromised Posted Dec 17, 2007 17:27 UTC (Mon) by wahern (subscriber, #37304) [Link] As for toy examples, I fail to see how two X.509 certificates which collide, and two PDF documents which collide, to be toy examples. In neither case where the structures or content arbitrary from the standpoint of the recipient viewer. Indeed, the published attack requires on its face only that you can add an arbitrary suffix of maximum 512 bits (64 bytes). That gives you tremendously wide latitude. Indeed, I fail to see how there could be such a thing as a toy example, anyhow. The purpose of a cryptographic hash is that you can make reasonable declarations about the qualities of the algorithm without reference or qualification to the structure or content of the input. You cannot do that now, so its no longer a secure hash. Period. Why people are defending this is beyond me. Its broken. People shouldn't be using it, particularly for such a use (as opposed to simply for one-wayness).
Can you cite the sources, please Posted Dec 17, 2007 22:40 UTC (Mon) by khim (subscriber, #9252) [Link] The purpose of a cryptographic hash is that you can make reasonable declarations about the qualities of the algorithm without reference or qualification to the structure or content of the input. Sorry, but this is piece of bullshit. The main purpose of cryptographic hash is to guarantee immutability of signed data in most cases (including distribution case). It's called Second preimage resistance. And both MD5 and SHA1 are not broken in sense that second preimage attack is implementable. What the hoople is all about then ? MD5 and SHA1 were found not collision resistant. Yes, there are exist application where this is requirement. For example you can not use it to prove that you've sent file A and not file B. But signing of tarbals is not such an application: if attacker can alter original tarball on ftp site before it's signed up - you have much bigger problem then just problems with collisions. While it becomes easier and easier to find collisions preimage attack is still quite hard (preimage attack is not just "slightly harder" then collision attack - it's "billions of billion times harder" then collision attack initially and thus still far from being cracked). Of course now it's not the time to be complacent (I'm pretty sure the next stage will be preimage attack), but from practical viewpoint MD5 is still not broken...
|
|||||||||||||||||||