Bug 449929 (CVE-2008-3323)

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?

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.

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.

  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?

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.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: dave.korn
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....

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" <dave.korn>
To: "'Derek Callaway'" <decal>,
	<dave.korn+cygwin>
Cc: <me>,
	<corinna>,
	"'Brian Dessent'" <brian>
References: <000301c8ca91$1ca938e0$55fbaaa0$@com>
<030c01c8cd44$71ee6c20$2708a8c0.COM>
Subject: RE: Cygwin Vulnerability Information
Date: Tue, 17 Jun 2008 13:13:32 +0100
Message-ID: <04e901c8d073$90221bb0$2708a8c0.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.COM>
Thread-Index: AcjKkRuzwL8RukMrRyyPa809ACc1owCsMpvQAKcbZUA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Return-Path: dave.korn
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....

Added reporter, Derek Callaway, to this bug.

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

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

Also note that setup.exe and the software which generates the package lists is
pure GPL and not owned by Red Hat.

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

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?

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

Hey everyone..

I just got the CVE number from MITRE:

CVE-2008-3323

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

Now public, opening bug
http://www.security-objectives.com/advisories/SECOBJADV-2008-02.txt