Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

SquirrelMail Repository Poisoned

Posted by kdawson on Tue Dec 18, 2007 02:47 PM
from the nuts-to-that dept.
Security IT
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."
+ -
story

Related Stories

Submission: SquirrelMail Repository Poisoned by SkiifGeek (702936)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

SquirrelMail Repository Poisoned 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • When a member of the team arrived for work (Score:4, Funny)

    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]

  • SquirrelMail team's first response after discovery (Score:5, Funny)

    by Anonymous Coward on Tuesday December 18 2007, @02:52PM (#21742726)
    ...of the breech: "Aw Nuts!"

  • You know... (Score:5, Interesting)

    by mdm-adph (1030332) <<mdmadph> <at> <gmail.com>> on Tuesday December 18 2007, @02:59PM (#21742852) Homepage
    ...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.
        • That will probably help if the problem's been discovered already. It won't help much if it comes up with legit download sites and no news about the breach. Still, it's another thing to check.

    • 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.

      • Re:You know... (Score:5, Informative)

        by D'Arque Bishop (84624) on Tuesday December 18 2007, @04:01PM (#21743864)
        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...
    • 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.

    • ...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...

      • Re:beyond md5 (Score:4, Informative)

        by plague3106 (71849) on Tuesday December 18 2007, @03:09PM (#21743008)
        If you read the article, or even the summary, it was someone checking the MD5 that discovered the poisioning. So... I'd say it certainly helped.

          • Re: (Score:3, Informative)

            by el americano (799629)
            With a Hollywood movie hacker, you mean. It is theoretically possible for this to be done, but researchers have not accomplished it yet. Just last month someone came close, but it required altering the original program to match the new MD5 collision value: Software Integrity Checksum Vulnerability [win.tue.nl]

            But I'm sure it would be no problem for your über-hacker or for Chuck Norris.

        • Re:beyond md5 (Score:4, Informative)

          by DarkHelmet433 (467596) * on Tuesday December 18 2007, @03:20PM (#21743214)
          Yes. The article is vague, and the title on /. is worse - implies the source repository. It seems people have been easily mislead as a result. Always read the actual article, not a 2nd or 3rd hand summary.

          From there:

          "The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised. "

  • 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.

    • Re:Ouch. Is RoundCube stable yet? (Score:4, Informative)

      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.

    • 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."

    • Re:Ouch. Is RoundCube stable yet? (Score:5, Informative)

      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.

  • 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?

    • Re:Bad design (Score:5, Funny)

      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.

  • Thank Heaven For Open Source (Score:5, Insightful)

    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.

    • Re:Thank Heaven For Open Source (Score:4, Interesting)

      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.
      • 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

      • Re:Thank Heaven For Open Source (Score:5, Insightful)

        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.

  • Has the compromised account been secured? (Score:4, Interesting)

    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?
  • Male Suppository Poisoned."....
    • 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!

  • 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.
      • Source Control / Configuration Management. In a perfect ( an utopia! ) system no code is ever added to anything going to production but to test systems. All code changes are tracked, traceable and documented against set of rules. All changes are are authorized, not by developer but for example lead or architect. Once accepted code changes are locked, can not be modified or deleted. Much what is done for example in Linux Kernel except usually in closed source systems you can (mostly, excluding some for any r
      • Source Code/Change Management. It's a generic term like Version Control System. Basically, at the level of discussion, the poster didn't want to be tied to the specifics of RCS, CVS, SCCS, Subversion, Git, Perforce, or some other package.

        That's one of the great things about SourceForge, though. CVS and Subversion are part of the repository they provide to projects hosted there, so your developers only have to be users and not worry about administration of a version control system. They also provide a bug tr

  • Don't trust squirrels! (Score:5, Funny)

    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]
  • 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].

  • Open vs. Closed Source Security Implications (Score:3, Insightful)

    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)

      by D'Arque Bishop (84624)
      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

  • 1.5.1 was compromised as well... (Score:5, Informative)

    by D'Arque Bishop (84624) on Tuesday December 18 2007, @04:29PM (#21744270)
    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...

  • 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.
    • They know the tune...

      If it ain't broke, don't fix it.

    • Or maybe your servers run Debian Etch (which would give you precisely Squirrelmail 1.4.9a) and so only gets security fixes and not functional updates.

    • Re:Good thing UWRF techies are lazy (Score:4, Informative)

      by D'Arque Bishop (84624) on Tuesday December 18 2007, @03:44PM (#21743612)
      Actually, when 1.4.11 and 1.4.12 were released, they were uncompromised. Sometime after one of the developers' accounts was hacked, and the compromised versions were uploaded.

      So, if someone (like your techies) had installed 1.4.12 within a few days of its release, chances are they would have gotten an uncompromised version. I had installed 1.4.12 a couple of hours after release, and after the compromise was found I checked and found mine was an authentic release.
    • Are you talking about the rather pathetic and obvious attempt to insert a patch into the kernel with uid=0 rather than uid==0 (assignment, rather than comparison)? I don't think that ever got past the "doh? how stupid do you think we are?" stage and I can't even remember if it was the kernel or something like just a patch for a module posted to the LKML or something.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.