|Summary:||CVE-2008-3323 Cygwin installation and update process can be subverted|
|Product:||[Other] Security Response||Reporter:||Mark J. Cox <mjc>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED UPSTREAM||QA Contact:|
|Version:||unspecified||CC:||blc, dave.korn+cygwin, decal, dj, glamb, me.redhat, rcvalle, security-response-team, vinschen|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-12-23 22:04:17 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Mark J. Cox 2008-06-04 10:29:44 UTC
Derek Callaway from Security Objectives contacted the Red Hat Security Response Team on 25th May 2008 to report a security issue with Cygwin. "Tarball software packages are installed and updated via setup.exe. This program downloads a package list and packages from mirrors over plaintext HTTP or FTP. The package list contains MD5 checksums for verifying package integrity. If a rogue server answers the HTTP request responsible for package updates and responds with a modified MD5 string setup.exe will download and install a malicious package." He included a proof-of-concept and stated that he notified vulnerability co-coordinator iDefense about this issue. iDefense responded that they did not consider this a vulnerability because "The installer prompts you to select a repository, and it is clear that HTTP/FTP is being used. Any site that allows a user to download applications over HTTP allows for similar attacks. " But Derek disagrees and his company plans to publish a formal advisory stating that the download mechanism used by Red Hat is insecure.
Comment 1 Mark J. Cox 2008-06-04 10:33:25 UTC
Brendan wrote: Packages and package lists are unsigned- there is no authentication provision in Cygwin packaging- just md5sums to ensure archive integrity. The Cygwin installer uses FTP/HTTP, and is about as secure (The document calls for the use of DNS spoofing, ARP redirection, TCP hijacking, etc). A proper fix would require signed packages and installer authentication (In other words, a complete redesign of the Cygwin packaging system). DJ wrote: The original protocol wasn't intended to provide authentication. It just downloaded files off the Internet, like any other free software / open source project. The MD5 checksums aren't authentication, they only check against mistransmitted files. (Users) who are concerned about security may use their own authentication mechanisms to download the files to a local mirror, then use setup to update from there. Adding a secure authentication mechanism on top of cygwin's distribution mechanism would be a considerable effort, I don't think we could justify it as part of our net-release maintainership. I also suspect that needing to sign each package would deter other contributors. Perhaps we could just sign the file containing the MD5 signatures?
Comment 3 Brendan Conoboy 2008-06-05 18:27:46 UTC
DJ and I discussed further (Corinna is still on PTO)- We can conceivably link in OpenSSL to the setup program, allowing HTTPS or other PKI options. Package signing, or md5 list signing are options, but tricky. Most packages come from community members. While some of us have an armchair understanding of crypto issues, we require advice from the SRT to create a sensible policy.
Comment 4 Chris Faylor 2008-06-08 17:31:13 UTC
Is this being reported for official Red Hat distributions of cygwin? It isn't clear that the original reporter understands that http://cygwin.com/ is not Red Hat. If this is in reference to the public project, where setup.exe is maintained by people outside of Red Hat, isn't this a problem for every other package distributed from sourceware.org/gcc.gnu.org? Nearly every tarball that you download contains a shell script which could be subverted. And, then you could start worrying about the packages distributed by sourceforge. However, if Red Hat is volunteering to add SSL support, that would be a welcome addition. I'd just like to have the changes reviewed by the setup.exe maintainers. I can't force anyone to do this work but I will ping a couple of the developers about it.
Comment 5 Dave Korn 2008-06-09 13:55:34 UTC
Hi, for any here who don't know me, I'm one of the cygwin maintainers for setup.exe and I'm here to help. I also have some security and crypto background and I'm willing to contribute patches to implement signature verification in setup.exe to help resolve this. I have a couple of questions: - Is there an official channel/liaison we should use to communicate with the reporter? It might be helpful to discuss potential mitigation strategies with him. I would understand if RH want to manage the external communications. - Can someone perhaps attach to the PR, or send me in private mail, a copy of the actual report from Mr. Callaway and the PoC he offered?
Comment 9 Dave Korn 2008-06-13 11:02:30 UTC
FTR, I have just sent Derek the following email after discussions between the setup maintainers off-list about the best approach to fix this problem: [CC'd Brian Dessent, Corinna Vinschen, Chris Faylor] Received: from ALBATROSS ([192.168.8.39]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 11:58:43 +0100 From: "Dave Korn" <dave.korn AT artimi.com> To: "'Derek Callaway'" <decal AT security-objectives.com>, <dave.korn+cygwin AT artimi.com> Cc: <me AT cgf.cx>, <corinna AT cygwin.com>, "'Brian Dessent'" <brian AT dessent.net> References: <000301c8ca91$1ca938e0$55fbaaa0$@com> Subject: RE: Cygwin Vulnerability Information Date: Fri, 13 Jun 2008 11:58:43 +0100 Message-ID: <030c01c8cd44$71ee6c20$2708a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000301c8ca91$1ca938e0$55fbaaa0$@com> Thread-Index: AcjKkRuzwL8RukMrRyyPa809ACc1owCsMpvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Return-Path: firstname.lastname@example.org X-OriginalArrivalTime: 13 Jun 2008 10:58:43.0275 (UTC) FILETIME=[71EAE9B0:01C8CD44] Derek Callaway wrote on 10 June 2008 01:30: > Greetings all, > > > > I was referred to you by Mark Cox. I have attached a > summary and proof-of-concept tarball to this e-mail encrypted with my GPG > key. Please let me know how you would like to proceed. My company > (Security Objectives Corporation) will be drafting up an advisory soon. I > will also be contacting MITRE for a CVE number. Hi again Derek, We've designed (and I've begun implementing) a scheme that we hope will close the loopholes in the cygwin distribution mechanism. Please let us know if you agree this should be watertight: - Implement code-signing of setup.exe. This should guarantee the integrity of setup.exe and therefore of the public key we will embed in it. - Sign all new versions of setup.ini and setup.bz2 with the corresponding private key when released. - Setup.exe will verify the signature of setup.ini/bz2 that it downloads and refuse to proceed if it isn't valid. - Verification of setup.ini guarantees the integrity of its contents and hence of the enclosed md5sums for the distributed packages. - Verifying the md5sums the guarantees that the packages haven't been tampered with. We believe this will prevent the kinds of interception or corruption of, or tampering with the packages distributed via the mirrors that you have identified in your advisory. Note that we are aware that md5 is a weak checksum, but as far as we understand the current state-of-the-art would require an attacker to control creation of both the original file and a malicious variant, and that it is not yet simple to modify an arbitrary file in a way that allows controlled contents to be inserted while matching the original md5. However we still propose to address this in a second stage of work where we will extend the setup.ini grammar to allow us to use stronger hashes or even keyed HMACs. Do you need more details? I imagine you'd like some idea of a schedule? By good fortune I happen to have a few days off work, and I'm able to dedicate myself to this full time. I'd expect to have a beta version of the new setup.exe available by the other side of the weekend and wonder if you'd like to help by testing it against your PoC setup? cheers, DaveK -- Can't think of a witty .sigline today....
Comment 10 Dave Korn 2008-06-17 12:26:02 UTC
For the audit record: I have created setup_crypto_branch in the cygwin-apps repository and implemented code-signing on HEAD; I have backported the fix to the release branch (not yet committed) and prepared a snapshot of it, and I have circulated email (appended) to let Derek Callaway know that we've got something for him to test. I haven't had any response from Derek to the two emails I sent last week yet. Could somebody please send him a ping and ask if he's received my mail or if it got toasted in an overzealous spamfilter somewhere? ------------------------------------------------------------------------------- Received: from ALBATROSS ([192.168.8.39]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jun 2008 13:13:32 +0100 From: "Dave Korn" <email@example.com> To: "'Derek Callaway'" <firstname.lastname@example.org>, <email@example.com> Cc: <firstname.lastname@example.org>, <email@example.com>, "'Brian Dessent'" <firstname.lastname@example.org> References: <000301c8ca91$1ca938e0$55fbaaa0$@com> <030c01c8cd44$71ee6c20$2708a8c0@CAM.ARTIMI.COM> Subject: RE: Cygwin Vulnerability Information Date: Tue, 17 Jun 2008 13:13:32 +0100 Message-ID: <04e901c8d073$90221bb0$2708a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <030c01c8cd44$71ee6c20$2708a8c0@CAM.ARTIMI.COM> Thread-Index: AcjKkRuzwL8RukMrRyyPa809ACc1owCsMpvQAKcbZUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Return-Path: email@example.com X-OriginalArrivalTime: 17 Jun 2008 12:13:33.0761 (UTC) FILETIME=[901BB310:01C8D073] Dave Korn wrote on 13 June 2008 11:59: > Derek Callaway wrote on 10 June 2008 01:30: > >> Greetings all, >> >> >> >> I was referred to you by Mark Cox. I have attached a >> summary and proof-of-concept tarball to this e-mail encrypted with my GPG >> key. Please let me know how you would like to proceed. My company >> (Security Objectives Corporation) will be drafting up an advisory soon. I >> will also be contacting MITRE for a CVE number. > > Hi again Derek, > > We've designed (and I've begun implementing) a scheme that we hope will > close the loopholes in the cygwin distribution mechanism. > I'd expect to have a beta version of > the new setup.exe available by the other side of the weekend and wonder > if you'd like to help by testing it against your PoC setup? Hi again Derek. I've now prepared the fix and placed a copy of the new setup.exe on the cygwin website in the test directory: http://cygwin.com/setup/snapshots/ The executable is http://cygwin.com/setup/snapshots/setup-2.573.2.2.exe and the source is in http://cygwin.com/setup/snapshots/setup-2.573.2.2.tar.bz2 The executable isn't code-signed yet, but it is feature-complete and of beta quality. Can you confirm for us that it fixes the vulnerability demonstrated in your advisory and PoC? cheers, DaveK -- Can't think of a witty .sigline today....
Comment 13 Mark J. Cox 2008-07-22 14:30:46 UTC
Added reporter, Derek Callaway, to this bug.
Comment 14 Derek Callaway 2008-07-22 15:42:33 UTC
Hello all, I am the original reporter. Sorry for the delayed response. I have been on the road lately and just returned from the Last HOPE conference. I tried testing the attack against an early snapshot of 2.573.2.2 but there was a bug where it was not including a forward slash in concatenated download URL's. I've since tested 2.573.2.3 and it appears to be resistant against my proof-of-concept code, although there still seems to be something weird going on with the forward slash appendage (there are two slashes before the filename in the URL being downloaded.) Mark, There are a lot of open source (and commercial) projects that are implementing secure software update mechanisms nowadays. Both Debian APT and Gentoo's Portage Tree implement GPG signing of their packages and Mozilla Firefox uses SSL. IIRC, the BSD's digitally sign their portages as well. Also, the success of attacks that utilize the DNS cache poisoning approach has recently been compounded by Kaminsky's birthday paradox technique (CVE-2008-1447.) I've published a blog post about this subject on my company's blog at http://systemofsystems.wordpress.com/2008/05/25/updating-the-updater/ Chris, I understand that Cygwin is not part of the RedHat Linux distribution but how exactly is RedHat affiliated with Cygwin? I see this at the bottom of the cygwin.com web page, "Cygwin DLL and utilities are Copyright © 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc." Derek Callaway Security Objectives GPG Key ID: 1024D/00372170
Comment 15 Chris Faylor 2008-07-22 15:49:04 UTC
Red Hat holds the copyright similarly to the way that the FSF holds the copyright for things like gcc, gdb, and other packages. I don't work for Red Hat. See: http://cygwin.com/licensing.html
Comment 16 Chris Faylor 2008-07-22 15:51:06 UTC
Also note that setup.exe and the software which generates the package lists is pure GPL and not owned by Red Hat.
Comment 17 Dave Korn 2008-07-22 16:08:15 UTC
> I've since tested 2.573.2.3 and it appears to be resistant against my > proof-of-concept code, although there still seems to be something > weird going on with the forward slash appendage (there are two slashes > before the filename in the URL being downloaded.) Nothing weird, just lazy coding; we don't bother to test whether the supplied URL ends with a slash before appending the relative URI to the setup ini files. I have an (unverified) memory that the rfc says this is valid syntax, albeit non-canonical; in practice we haven't seen any servers that complain about it, and the only place in POSIX where '//' doesn't just mean an empty (null, ignored) path component is at the root of the FS, and nobody should have their webroot pointed there! I'll tidy it up when I get a spare minute, just for neatness' sake.
Comment 18 Derek Callaway 2008-07-24 06:04:22 UTC
So if Cygwin isn't RedHat then why is this bug being discussed on RedHat's Bugzilla? Also, is there a timeframe for the release of the new setup.exe version?
Comment 19 Mark J. Cox 2008-07-24 09:06:49 UTC
> So if Cygwin isn't RedHat then why is this bug being discussed on RedHat's > Bugzilla? There is currently no private list used by the Cygwin developers, and therefore they had no place to discuss a private issue. I set up this bug to help track the issue through completion.
Comment 20 Derek Callaway 2008-07-25 16:06:35 UTC
Hey everyone.. I just got the CVE number from MITRE: CVE-2008-3323
Comment 21 Dave Korn 2008-08-05 09:07:37 UTC
Hey everyone. We've released the new setup.exe into the wild now, so as far as I'm concerned there's no further reason to have this bug marked as embargoed. Unless anyone objects could someone with the necessary admin privs open it up? cheers, DaveK
Comment 22 Mark J. Cox 2008-08-05 09:52:44 UTC
Now public, opening bug http://www.security-objectives.com/advisories/SECOBJADV-2008-02.txt