Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security IT

SquirrelMail Repository Poisoned 182

SkiifGeek writes "Late last week the SquirrelMail team posted information on their site about a compromise to the main download repository for SquirrelMail that resulted in a critical flaw being introduced into two versions of the webmail application (1.4.11 and 1.4.12). After gaining access to the repository through a release maintainer's compromised account (it is believed), the attackers made a slight modification to the release packages, modifying how a PHP global variable was handled. This introduced a remote file inclusion bug — leading to an arbitrary code execution risk on systems running the vulnerable versions of the software. The poisoning was identified by a difference in MD5 signatures for version 1.4.12. Version 1.4.13 is now available."
This discussion has been archived. No new comments can be posted.

SquirrelMail Repository Poisoned

Comments Filter:
  • by Anonymous Coward on Tuesday December 18, 2007 @02:49PM (#21742678)
    This was the first sign of trouble: http://i23.tinypic.com/2ezqkht.jpg [tinypic.com]
  • by Anonymous Coward on Tuesday December 18, 2007 @02:52PM (#21742726)
    ...of the breech: "Aw Nuts!"
    • Unfortunately the Horde doesn't require intervention at in the code repo to be compromised. One of my clients has a Horde:IMP install has been compromised three different times this year with three different versions.
  • You know... (Score:5, Interesting)

    by mdm-adph ( 1030332 ) on Tuesday December 18, 2007 @02:59PM (#21742852)
    ...I've never made sure to always check my MD5 signatures, but I damn sure am now.
    • Re:You know... (Score:5, Insightful)

      by KiloByte ( 825081 ) on Tuesday December 18, 2007 @03:10PM (#21743032)
      What's the point? If you download the signatures from the same website as the packages, you won't catch any but most lazy/inept attackers. The ones here were that stupid, but come on, this trick works only once.

      In fact, if an attacker can tamper with the website on any point (including a router/proxy on the way), they can change the md5 whenever they change any other communication if they only care enough. For any resilience, you'd need public key cryptography; but even then you will be only as safe as the least safe private key.
      • check my MD5 signatures

        What's the point?

        What's the point, indeed. We should have moved away from MD5 signatures years ago. It's only a matter of time before some maliciously inclined asshat starts forging MD5 signatures on FLOSS packages, just to prove a point.

        MD5 is broken [schneier.com] and should [wikipedia.org] not be used [cryptography.com]. It's time the FLOSS world went to at least SHA-224, if not SHA-512 (for future proofing, lots of bits). And just for reference, there is an open call [nist.gov] for a new secure hash [schneier.com].

      • When you use the MD5's you check against the main site. to see if the mirror was compromised. If the main site is compromised then there is nothing MD5 can do to help you. nor can SHA256 help you there either. What you need is a full on asymmetric digital signature, with a well trusted key posted long before releases are signed. So they can be verified independently.
    • Re: (Score:3, Interesting)

      by araemo ( 603185 )

      ...I've never made sure to always check my MD5 signatures, but I damn sure am now.

      Unfortunately, the next guy will just edit the .md5 files to contain the correct signature.

      (For those who don't get it: MD5 only caught it because the 'hacker' didn't think to check for MD5 signatures. They're trivial to regenerate after you change the file.)

      GPG signing is more secure, but if the secret key is compromised, they can be faked as well. That said, there are at least revocation procedures that can catch it even if you don't read the news.

      • Re: (Score:3, Interesting)

        by Nasarius ( 593729 )
        Exactly! I don't understand why GnuPG signatures aren't in common use in the open-source world. Gentoo and other distros use them to sign packages, but if there's a weak link upstream, that's no good. It requires some extra infrastructure (a central key server for well-established developers/release engineers would be nice), but once you had that set up, verifying any package would be automatic.

        GPG signing is more secure, but if the secret key is compromised, they can be faked as well.

        And that's relatively

        • Debian uses GPG to sign packages as well. I don't know about RedHat's RPM system, although I assume it must use some sort of cryptographic validation on binary packages; it's just too much of a weak link to ignore completely.
          • by Intron ( 870560 )

            rpm --checksig <package_file>

                                This checks the PGP signature of package to
                                ensure its integrity and origin.
      • Re:You know... (Score:5, Informative)

        by D'Arque Bishop ( 84624 ) on Tuesday December 18, 2007 @04:01PM (#21743864) Homepage
        Unfortunately, the next guy will just edit the .md5 files to contain the correct signature.

        (For those who don't get it: MD5 only caught it because the 'hacker' didn't think to check for MD5 signatures. They're trivial to regenerate after you change the file.)


        Correction: MD5 caught it because the MD5 files are stored on the main SquirrelMail server and the packages that were altered were stored on SourceForge. The "hacker" didn't have access to the former, so he couldn't change them.

        Hope this helps...
        • by dbc001 ( 541033 )
          So it sounds like the lesson here is to store your signatures on a server that's separate from your release server - that's actually good news. It means that relatively trivial security can go a long way towards detecting these kinds of attacks. In fact, if the releases are posted on a website other than sourceforge, you can probably limit any damage to a very small group of people, even if you do get compromised.
    • by brunes69 ( 86786 )
      If the attacker had access to the main download site and was not a complete ass, they would have just changed the MD5 as well.
    • by MikeyVB ( 787338 )

      ...I've never made sure to always check my MD5 signatures, but I damn sure am now.

      Sort of like backups, isn't it? We all know we should do it, but we never really do until it is too late...

    • Just a note. The continued reliance upon MD5 is an issue in itself, given the advances in hash analysis over the past decade. At this point it would be wise to go with SHA-256, or if you really want to reduce the number of bits, the first or last 128 bits from a SHA-256 hash.
    • Even the Ubuntu community doesn't seem to be concerned about a MD5 discrepancy. The CD-ROM image for the newest Kubuntu, found at http://torrent.ubuntu.com6969/ [torrent.ubuntu.com6969] shows that the MD5 hash is:
      6709ff39ea47d3563b537b67153f60ee0c932a93

      When I downloaded the ISO through BitTorrent, though, I found this instead:

      kwtm@host ~/isocd$ md5sum kubuntu-7.10-desktop-i386.iso
      ae9b209fe4b9caf545fa2011631de797 kubuntu-7.10-desktop-i386.iso

      I mean, this is coming through BitTorrent, so other than myself, there must be thousands o
      • found at http://torrent.ubuntu.com6969/ [torrent.ubuntu.com6969] shows that the MD5 hash is: 6709ff39ea47d3563b537b67153f60ee0c932a93

        That's funny, because an md5 checksum is always 128 bits, i.e. 32 bytes. Read the bottom of the page: info hash: SHA1 hash of the "info" section of the metainfo (*.torrent) Try "sha1sum" next time, and on the correct file.

      • 6709ff39ea47d3563b537b67153f60ee0c932a93 is the info hash of the torrent.

        This is NOT a MD5 of the file it is a SHA1 hash of the info section of the torrent which contains the SHA1 hashes of the individual peices of the file and some other metainformation.
  • Anyone been using it for a while without any problems?

    I've not evaluated it recently. Horde is a PITA to set up and this doesn't give me confidence in the SM team.
    • by pembo13 ( 770295 ) on Tuesday December 18, 2007 @03:18PM (#21743162) Homepage
      I love it, it it very nice on eyes as compared to SquirelMail. I do not use if regularly, but I trust it for whenever it is needed.
    • Re: (Score:3, Informative)

      by mlwmohawk ( 801821 )
      Anyone been using it for a while without any problems?

      I use it on my site and install it for customers. You won't build a "hotmail" with it, and a rich user client like Thunderbird is almost always a better choice for users, but for those who need web access to their email, it is absolutely great.

      • by Nimey ( 114278 )
        How's it work with PDAs? Squirrelmail sucks balls on a PDA-sized screen.
        • How about any open source imap client for that matter?

          There used to be some IMAP to WAP client based on PHP, but it had all kinds of crazy problems like you had to hardcode your login to the config file. It also was read only - you couldn't send mail from the phone.

          Is there anything new on the market for mobile users?
          • by mashade ( 912744 )
            Check out the Claros InTouch suite @ http://claros.org/ [claros.org]

            Their stuff runs on Java with Tomcat, but is reasonably good. The mobile client is decent (Claros Mini). If you dig Tomcat, that is ;)
    • by pongo000 ( 97357 )
      and this doesn't give me confidence in the SM team

      Then you should probably stay away from Debian [linuxinsider.com], Sendmail [cert.org], Apache [apacheweek.com], or...well, hell, just stay away from Open Source, period, if a server/distro compromise is the measuring stick you use to measure "confidence."
    • by coryking ( 104614 ) * on Tuesday December 18, 2007 @04:34PM (#21744334) Homepage Journal
      Why is this modded as a troll?

      Roundcube has great potential, but it isn't nearly as mature as SM. It does seem to be getting better though. The big problem I have with Roundcube is it doesn't have plugins. No plugins = no Sieve filters (avelsieve), which is a big deal to me. No plugins = no other cool things that Squirrelmail has like importing and exporting address books from all kinds of crazy places, no admin plugins, etc...

      Someday though. It has always looked and functioned way nicer than squirrelmail, it just needs more backend sysadmin goodness.
    • Re: (Score:2, Informative)

      by RemyBR ( 1158435 )
      I'm using it for some weeks now... small user base though, about 25 people. Runs fine after I did some small fixes on the identity management and auto user creation features, which had minor bugs on the release I got. But overal it's a great piece of software.
    • Re: (Score:2, Informative)

      by tux0r ( 604835 )
      I thought of RoundCube the instant I saw this article.

      I've just installed Round Cube 0.1-RC2 on my webserver to get reliable access to my non-work email. Apart from the dubious 0.1 version number (way to instil confidence in the end users: call an otherwise stable first release 1.0!) it is significantly more reliable than beta1 and even more crisply polished than before.

      SquirrelMail and Horde are mature, yes, but they seem to bloat. I just want a lightweight, well-designed web access system so I don't have
  • Bad design (Score:5, Funny)

    by Anonymous Coward on Tuesday December 18, 2007 @03:05PM (#21742944)
    Whoever decided that sending mail by using squirrels as couriers through these series of tubes is just damn wrong. Even worse, who are these sick bastards poisoning squirrels?
    • by Technomonics ( 970384 ) on Tuesday December 18, 2007 @03:31PM (#21743418)
      STP (Squirrel transport Protocol) suffers from the same inherent problems as IPOAC(IP over Avian Carrier) in that they are both very vulnerable to a a CITM (Cat In The Middle) attack. If however you were to implement STP over RHB (Roving Hamster Ball), the packet may still be intact yet there may occur an indeterminate amount of delay.

      FWIW
    • Whoever decided that sending mail by using squirrels as couriers through these series of tubes is just damn wrong. Even worse, who are these sick bastards poisoning squirrels?

      The problem first started when they missed the fact that tubes were designed with mice and hamsters in mind.
    • Even worse, who are these sick bastards poisoning squirrels?
      Probably the Iranians. They're already on to the West's previous attempts [msn.com] in the region. It is only natural they'd move to "cyber warfare." It's the newest thing in espionage circles. All the trendy countries are doing it. Iran isn't going to be left out.

    • by piojo ( 995934 )

      Even worse, who are these sick bastards poisoning squirrels?
      I think one of them may have been Tom Lehrer.
  • by mpapet ( 761907 ) on Tuesday December 18, 2007 @03:08PM (#21742988) Homepage
    If this were to happen to a proprietary application you wouldn't get an honest answer from the vendor. The bigger the vendor the worse the response.
    • by DigitAl56K ( 805623 ) on Tuesday December 18, 2007 @03:20PM (#21743208)
      Really? How many vendors of proprietary applications have their source repositories sitting on the Internet with a visible public interface and developers who may never have even met each other logging in from all over the world?

      I also like how you blanket-troll all vendors of proprietary applications as if none posses basic ethics.
      • by mpapet ( 761907 )
        How many vendors of proprietary applications have their source repositories sitting on the Internet with a visible public interface and developers who may never have even met each other logging in from all over the world?

        What's wrong with anything you just described? These are all good traits. It maximizes cooperation toward a common goal. It's terribly misleading to ignore the fact that the public access is read-only.

        I also like how you blanket-troll all vendors of proprietary applications as if none po
      • by 99BottlesOfBeerInMyF ( 813746 ) on Tuesday December 18, 2007 @03:46PM (#21743628)

        Really? How many vendors of proprietary applications have their source repositories sitting on the Internet with a visible public interface and developers who may never have even met each other logging in from all over the world?

        Considering the trend for outsourcing, probably more than you'd think. A lot more yet simply ship the code off to India or Latvia or somewhere, get it back, perform no real reviews of the code, and ship it out.

        I also like how you blanket-troll all vendors of proprietary applications as if none posses basic ethics.

        He does paint with a bit of a broad brush; but he also has a point. Commercial, closed source vendors are running a business and their primary motivation is money. Sadly, that often means hiding security breaches from users, even when that places those users at risk. OSS projects may have commercial motivations as well, but because of the process they cannot easily hide this type of problem... which is good for users.

      • by Intron ( 870560 )

        How many vendors of proprietary applications have their source repositories sitting on the Internet with a visible public interface and developers who may never have even met each other logging in from all over the world?


        Nobody knows.
      • by m2943 ( 1140797 )
        Really? How many vendors of proprietary applications have their source repositories sitting on the Internet with a visible public interface and developers who may never have even met each other logging in from all over the world?

        What does that have to do with anything? The repository was compromised because one of the developer's accounts was compromised. This also happens in companies.

        In addition, I suspect that corporate developers are more likely than FOSS developers to put in backdoors themselves--bec
  • by Ambiguous Puzuma ( 1134017 ) on Tuesday December 18, 2007 @03:09PM (#21743002)
    If the vulnerability was introduced through a compromised account, is there any assurance that that account is no longer compromised? I see no mention of that.
  • They got lucky (Score:4, Insightful)

    by sqlrob ( 173498 ) on Tuesday December 18, 2007 @03:09PM (#21743004)
    MD5 was on the same server. What prevented the attacker from changing that as well?
    • Re: (Score:2, Informative)

      by tokul ( 682258 )

      MD5 was on the same server.
      Nope. They are on different server.
    • Re:They got lucky (Score:4, Informative)

      by broken_chaos ( 1188549 ) on Tuesday December 18, 2007 @03:14PM (#21743092)
      I don't think they are. MD5 is on the main SquirrelMail site, package is hosted on SourceForge.
  • Male Suppository Poisoned."....
    • by rts008 ( 812749 )
      LOL!! I thought I saw something similar at first also, but your version was better than mine!

      I'm NOT going to try to give any squirrel (male or female) a suppository!! It seems like it would have similar results to sticking your hands in a running garbage disposal in your sink.

      There's bound to be a better way to poison your male squirrels than suppositories!
  • by Anonymous Coward
    1.4.11, 1.4.12 and 1.5.1. Same attack bassed on CGI 1.1 specification implemented by PHP.
  • He has a proclivity for poisoning pigeons...maybe he's branched out to squirrels.
  • Makes me wonder (Score:3, Insightful)

    by tuomoks ( 246421 ) <tuomo@descolada.com> on Tuesday December 18, 2007 @03:12PM (#21743068) Homepage
    Good catch but it makes me wonder how the SC/CM is managed today? Open or closed source is vulnerable for developer access. I can understand that open source projects don't always have resources to run full SC/CM systems but I don't see full control even in some closed source environments I know. It is not difficult but needs some planning and computer resources, not human resources! Almost only places I have seen that kind of system controls are some insurance, banking (less often) and governments (often a mess). It is not just security, mistakes happen, and on long run it always pays back, try to tell that to management(heh!) Maybe I'm biased but after a couple of mishaps a long time ago we implemented a SC/CM system to protect against unverified and/or untested systems going to production and several other companies started using similar methods after us. It really can be automated with some planning. First everybody hates it and 6 months later they love the benefits, as I said, everybody makes mistakes and one command recovery is very nice when that happens before anything goes wrong.
  • by Jester998 ( 156179 ) on Tuesday December 18, 2007 @03:21PM (#21743236) Homepage
    I, for one, refuse to trust my mail to any creature that can be this devious. [maniacworld.com]
    • by GWBasic ( 900357 )

      I, for one, refuse to trust my mail to any creature that can be this devious.

      That obstacle course looks like it could be a level in Super Mario Galaxy. Instead of Mario grabbing the star, the squirrel grabs the nut!

  • Poisoned distributions? Nasty indeed. Anyone got any idea how it happened? I'd imagine that targeting a specific developer just when he's doing a release, and being able to make a change to that release that causes a hole to be opened up, is quite challenging. Doing it twice is very nasty indeed; someone worked hard at this.

    Actually, I think I know one way of doing this that doesn't require the distribution builder's machine to be compromised and which also means that matching even simple signatures like an
  • Weeee... (Score:2, Informative)

    by ender_01 ( 1145117 )
    For anyone that doesn't get the 'andweeeeeee' tag may I refer you to http://www.threebrain.com/weeeeee.shtml/ [threebrain.com].
  • by tfskelly ( 1205060 ) on Tuesday December 18, 2007 @04:04PM (#21743906)
    I recently wrote a paper arguing that open source is more secure than closed source because finding and fixing flaws is easier in open source. I'm not sure if this incident supports or refutes that argument. In one post at SquirrelMail's blog, they say that 1.412 is compromised. In the next post, they say that 1.411(released Sept 29) and 1.412(released Dec 5) are compromised. If the time between the first compromised release and the fix is 9 days, nice job. If the time between first compromised release and the fix is 2.5 months, I'm not too impressed. Regardless, it looks like the time between discovery of the flaw and patch is only 1 day, which is pretty outstanding. Why did it take so long to find a MD5 error when the MD5 hashs and downloads are posted right next to each other for several months? Did no one check them for that long? Is this the developer's responsibility, or the responsibility of the implementing community? What measures can be taken to prevent this kind of oversight from happening again? I'm not so worried about the compromise itself - projects will get hacked. But there are safeguards to prevent this exact hack from being too effective, and those safeguards didn't work. Why not?
    • Re: (Score:3, Informative)

      The issue is that you're working from a bit of a flawed premise. :-)

      1.4.11 and 1.4.12 were released uncompromised. In very late November, someone hacked a developer's SourceForge account and uploaded compromised versions of 1.4.11, 1.4.12, and 1.5.1. As soon as the problem was found in the stable branch, an announcement was made and the original 1.4.x versions restored. As soon as someone came onto Freenode #squirrelmail and explained the EXACT security implications of the poisoned releases, 1.4.11 and 1
  • by D'Arque Bishop ( 84624 ) on Tuesday December 18, 2007 @04:29PM (#21744270) Homepage
    One thing that wasn't covered in the story...

    Yesterday morning it was discovered that the 1.5.1 (development) release had been compromised as well. It hadn't been discovered until then as the hacker had modified a different file in a slightly different way. If you're running a version of 1.5.1 that had been downloaded after sometime in late November, then it would be a good idea to remove it or replace it with a SVN release (which was not compromised).

    There's no official announcement yet, but 1.5.1 has been pulled from distribution and an official announcement will probably be forthcoming.

    Hope this helps...
    • the hacker

      Me thinks that was a probably a cracker, not a hacker.

      Cracker: Malicious, illegal, wants to do damage (usually for their benefit)

      Hacker: Just wants to help fix security holes in unorthodox way, play as well, and do no damage.

  • Surely there's a better way to keep them off the bird feeder than poisoning them. And why just the males?
  • Slashdot tags are now officially funnier than the posts themselves.

  • hehe, i checked out of curiousity since none of us really use the web access.

    Our cheesy email provider is on 1.4.9a.
    Horde is the other choice and a newer version than when i last tried to use the web interface, looks confusing for any of our users now.

    How would one set up their own email server with something like this? Would i want to since this only cost $150/year? Just use outlook that will come with the small biusiness server next year?
  • Alternative webmail? (Score:3, Interesting)

    by Tweekster ( 949766 ) on Tuesday December 18, 2007 @08:58PM (#21747300)
    Seriously, the state of webmail is pretty sad. Is there any promising projects for a MODERN webmail system out there? (Not a full collab package, or a heavy HEAVY ajax system)

    OSS or closed source, it doesnt matter to me, just anything that is good. Squirrelmail is what I use right now, and well its ugly and it doesnt seem like they ever plan on making it look like a modern webmail client should.
  • by tkid ( 821402 )
    developer that somehow allows some crackers into the system or network.. no pun intended. My present employer now, we had a developers machine get compromised, it was sweet walking over to his machine and unplugging his network cable while he was working, along with the phrase, "we'll let you know when you can plug it back in after we wipe your machine."
  • Wouldn't it be pretty simple for whoever compiled the release to have a known good MD5 and periodically check that what people are downloading is good? A script that runs daily from somewhere else (even on your home PC) like this maybe:

    Download package
    Check for matching hash
    If hash doesn't match, send notification email/SMS/whatever

    Even if the site is compromised and the hacker (cracker!) changes the .md5 file you'd still find out pretty quick if something was amiss. Someone commented that this has been a

The truth of a proposition has nothing to do with its credibility. And vice versa.

Working...