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
Attachment:
signature.asc
Description: Digital signature