bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Security Breach Alert - CVS Home File Download Area Compromised


From: Conrad T. Pino
Subject: RE: Security Breach Alert - CVS Home File Download Area Compromised
Date: Wed, 26 Jan 2005 14:35:28 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Derek,

I'm editing the CC list since I know Larry and Bernd are list subscribers.

> From: Derek Price
>
> Just a quick thought.  I'm on the road and don't have time for more.
> I've had several complaints in the past that file downloads don't work
> from cvshome.org that turned out to be solved when cookies were enabled
> in the client.

If only it could be that simple!!  Cookies are enabled on my browser and
I have confirmation of that since the http://www.nytimes.com/ remembers
who I am.

> Also, if this is a new client-related issue (not the cookie issue
> above), then why hasn't it cropped up until just now?

My answer to your question is, "I don't know."

I don't see a direct connection between any possible answer that refutes
the evidence now available and therefore don't understand the reasoning
behind the question.
=====================
I'll summarize the evidence now known:

Cases where downloading a binary "*.gz" downloads as "too large":

        Reporter                Platform                Browser
        Conrad Pino             Windows 2000    Internet Explorer 6
        Conrad Pino             Windows 2000    Netscape 4.8

Cases where downloading a binary "*.gz" download as "correct size":

        Reporter                Platform                Browser
        Conrad Pino             Mac OS X                Safari 1.2.5
        Conrad Pino             Mac OS X                Internet Explorer 5
        Conrad Pino             Windows 2000    wget 1.9.1
        Arno Schuring   Windows XP              FireFox 1.0
        Todd Denniston  Linux 2.4.26    Mozilla/5.0

Cases where downloading a binary "*.gz" fails altogether:

        Reporter                Platform                Browser
        Arno Schuring   Windows XP              Internet Explorer 6 SP2

Cases where downloading a binary "*.gz.sig" fails or is zero size:

        Reporter                Platform                Browser
        Conrad Pino             Windows 2000    Internet Explorer 6
        Conrad Pino             Windows 2000    Netscape 4.8
        Conrad Pino             Mac OS X                Safari 1.2.5
        Conrad Pino             Mac OS X                Internet Explorer 5
        Arno Schuring   Windows XP              FireFox 1.0
        Todd Denniston  Linux 2.4.26    Mozilla/5.0

        Reporter                Platform / Browser Reported
        Mäkeläinen Juha IE version 6.0.2800.1106.xpsp2.040919-1003

Cases where downloading a binary "*.gz.sig" succeeds:

        Reporter                Platform                Browser
        Conrad Pino             Windows 2000    wget 1.9.1
        Todd Denniston  Linux 2.4.26    Lynx 2.8.4rel.1

In cases tried so far Todd Denniston (1 case) and I (2 cases) are able
to verify PGP signatures when "*.gz" is correctly sized and "*.gz.sig"
can be downloaded.

Arno Schuring sent MD5 data for 7 files and I can confirm 4 of the 7
as correct.  I don't have reference MD5 data for:

        3986d5a825cfb82436e7934b4bf71287 *cvs-1.11.18-AIX.gz
        e07f84dceb46e0b5a8a12dabd648d8e1 *cvs-1.11.18-HP.gz
        f91de7cbed9dedb794b078ee32a0ebf4 *cvs-1.11.18-SUN.gz

which are files posted by Larry.

And let's not forget the "too large" and bad "*.gz.sig" behaviors are
specific to CVS Home only.  These behaviors are NOT universal on CVS
Home.  They only affect specific file types, file extensions and/or
specific download areas.  Source tar balls aren't affected.  Windows
binary file area isn't affected.
=====================
IMHO the accumulating evidence is pointing AWAY from a compromised
system and TOWARDS an unreliable download system.
=====================
Here are the policy questions I have that I'd like to see addressed:

1. What's the point of maintaining a binary download area if we can't
provide a reasonably convenient method to authenticate the files?

        All I'm saying is what we have in place today isn't working
        for a VERY popular browser and a VERY popular platform.

        Yes, I have the latest patches for both platform and browser.

        Yes, I have virus scanned ALL my systems with freshly updated
        Norton and TrendMicro virus scanners.

2. Assuming we delete "*.gz.sig" files from the binary areas, how do
we explain to users what to expect of downloaded content?

        Internet Explorer 6 downloads an uncompressed file whose size
        matches the expected uncompressed size and compares with the
        uncompressed original.

        Netscape 4.8 downloads an apparently uncompressed file whose
        size DOES NOT match the exacted uncompressed size.  The Windows
        2000 "comp" utility reports different size files as different
        so I can't easily certify the content.

        I don't want to spend time testing and documenting all platform
        and browser combinations known to man and computer!

3. Do we publish MD5 data for compressed and uncompressed versions?

        Neither of the above will work with Netscape 4.8 since what
        it downloads isn't correctly sized.

4. Do we tell the world we will support downloads only with tightly
specified platform / browser sets?

5. Collab Net donates hosting services and this issue represents an
additional burden.  Does the value of binary downloads to the CVS
community warrant the additional work required of Collab Net?
=====================
> Regards,

Ditto,

> Derek

Conrad

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBQfgbL7NM28ubzTo9EQKRCwCgoH2zrd4PswGukot6X5eIUMZ8VQ8AoNJg
6HnszharwpSe08reurt7othW
=nC9T
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]