On Mon, Dec 11, 2006 at 10:11:34PM +0100, Christian Boltz wrote: > > Not that I wouldn't want to see this fixed but, really, this is as > > low risk as it can get. Through XSS no one could retrieve user > > credentials and no one should be trusting (in this day an age) the > > information from a website that is not signed (through an SSL > > server-side certificatE). > > *LoL* > > The people download packages from there which are installed as root > (pre-/postinstall scripts) and might contain harmful binaries. > Therefore a wrong md5sum is not "low risk"!
Pray tell, how can we trust a user that blindly follows a link from somebody (not from a Debian advisory, which is GPG/PGP signed) will take any kind of precautions from downloading software? You're really saying that somebody that follows that link and doesn't take the average precautions (trusting who sent it) would verify the package's md5sum? C'mon. Not mentioning the fact that *even* with md5sum pollution that someone would still get to download a file from the Debian servers (with the current fix, previously you could manage, through an XSS to make an HTML page that pointed to an alternate location). Not that many people use packages.debian.org to download and install packages to their system. Debian users will (almost) always use apt (with per-archive signatures). > Oh, and SSL would not change anything here. One can still create a link > with a wrong md5sum to https://packages.debian.org, this time fully > trusted ;-) Wrong, https://packages.debian.org does not exist. What I'm saying is that if you read a content from a web page and that content is not signed (by the webserver) you can trust it as much as doing a google search and picking up whatever you get there. Haven't you heard about DNS spoofing or MITM attacks? XSS attacks against HTTPs sites are risky since the web site is telling you "trust me" and signing the content, something that does not happen in packages.debian.org. That's what would have bumped the severity up in this bug because that would mean that "the server" was signing fake content from a third party. Right now, you have not any way, any, to tell packages.debian.org appart from a fake site that is supplanting it. > $file = $input->param('file'); > param_error( "file" ) unless defined $file; > +# Make file fit in a regexp > +param_invalid ("file") if $file !~ /^[\w\%\.\_\-]+$/; > > BTW: Inside [...], you do _not_ need to escape special chars. Your > regex will allow backslashes in the filename - not necessarily what > you want. Says who? You *do* need to escape chars. I would suggest you try this: echo "\\" | perl -ne 'print if $_ =~ /^[\w\%\.\_\-]+$/'; Tell me what it prints in your system. Now test with other chars and you'll see the regexp is correct. > > And it allows other funny things like > http://packages.debian.org/cgi-bin/download.pl?arch=all&file=..%2F..%2F..%2Finsecure%2Fscript%2Fhacked.deb&md5sum=totally_broken_by__security_team&arch=esel&type=main > or > http://packages.debian.org/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fi%2Fie%2Fmicrosoft_internet_explorer_7.0-3_i386.deb&md5sum=totally_broken_by__security_team&arch=i386&type=main > (hmm, does this package's license meet your strict requirements? ;-) ? That would generate HTML files that point to content that do no exist in the any of the mirrors. The only way you can make those file valids if you break into one of the mirrors, and if a mirror is broken and you do not do per-release GPG checks of the archive your injection method is really pointless. Might be OK for a prankster joke, completely useless for an attack. > > $md5sum = $input->param('md5sum'); > param_error( "md5sum" ) unless defined $md5sum; > +# Make md5sum fit in a regexp > +param_invalid ("md5sum") if $md5sum !~ /^\w{32}$/; > > Oh yes, very funny ;-) > http://packages.debian.org/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fd%2Fdietlibc%2Fdietlibc_0.28-3_i386.deb&md5sum=debian_security_team_in_da_house&arch=i386&type=main > (thanks to fefe again) So? what's the issue there? You get a link to a file whose md5sum will not verify whatever you provide in the webpage. Is that an issue? Will the user install that package? How do you get a user to install something there that will compromise the system? Please read before me: content manipulation (of the md5sum) does not equate to code injection or even to remote compromise of a system because of a wrong download. > Again: It is not an option to check the md5sum with a regex, you have > to display the _correct_ md5sum. This means you should not pass it as > URL parameter, but read it from a file or database. But why on earth would you need to do that? Could you please tell what your attack would be and how somebody could fall into installating something in their system because of this? The only thing somebody could do (with the current fix) is to play prankster jokes with embedded (or e-mailed) fake URLs. I don't see where the deal is, really. > $arch = $input->param('arch'); > param_error( "arch" ) unless defined $arch; > +# Make arch fit in a regexp > +param_invalid ("arch") if $arch !~ /^[\w\-]{1,10}$/; > +# And also check that it is in the list of supported archs > +param_invalid ("arch") if ! defined ($arches{$arch}); > > arch is also something that should be checked against a fixed array. It already is, what do you thing '$arches{$arch}' is? Regards Javier
signature.asc
Description: Digital signature
