Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Remote exploitation of a buffer overflow vulnerability in multiple vendor's implementations of curl and wget allows attackers to execute arbitrary code. The vulnerability specifically exists due to insufficent bounds checking on user-supplied data supplied to a memory copy operation. The memcpy() of the supplied ntlm username to ntlmbuf shown below results in a stack overflow.
seemant, liquidx: this is theorically confidential but has been leaked, so we should open this bug soon. Feel free to commit fixes to Portage directly, referencing this bug.
Created an attachment (id=70533) [edit] libcurl-ntlmbuf.patch Patch from Daniel Stenberg (curl team)
*** Bug 109123 has been marked as a duplicate of this bug. ***
I guess this is completely public now :)
Ouch, didn't see this bug... The stable wget version doesn't support ntlm auth, is therefore not affected.
This is CAN-2005-3185
wget is done. curl still needs some lovin' vapier, solar, dragonheart: got time for some security patching ?
k- I'm working on it. Seems to have some pecular backards compatibility cruft that needs cleaning. When I commit it I wouldn't mind someone having a review.
Commited curl-7.15.0 currently masked I had some gcc-3.4.4 (hardened x86 and ppc) troubles - self tests 253 and 255 failed with smashing stack attack. emerge Portage 2.0.53_rc3 (hardened/x86/2.6, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 AMD Athlon(tm) XP 1900+ Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" dan@frog /var/tmp/portage/curl-7.15.0/work/curl-7.15.0/tests $ ./runtests.pl 253 ********* System characteristics ******** * curl 7.15.0 (i686-pc-linux-gnu) * libcurl/7.15.0 GnuTLS/1.2.4 zlib/1.1.4 libidn/0.5.15 * Features: IDN IPv6 Largefile SSL libz * Host: frog * System: Linux frog 2.6.12-gentoo-r6 #1 Wed Jul 27 18:38:45 EST 2005 i686 AMD Athlon(tm) XP 1900+ AuthenticAMD GNU/Linux * Server SSL: ON * libcurl SSL: ON * libcurl debug: OFF * valgrind: OFF * HTTP IPv6 ON * FTP IPv6 ON * HTTP port: 8990 * FTP port: 8992 * FTP port 2: 8995 * HTTPS port: 8991 * HTTP IPv6 port: 8994 * FTP IPv6 port: 8996 * TFTP port: 8997 * SSL library: GnuTLS ***************************************** test 253...[FTP IPv6 dir list with EPRT] sh: line 1: 31666 Aborted ../src/curl --output log/curl253.out --include -v --trace-time -g "ftp://[::1]:8996/" -P - >>log/stdout253 2>>log/stderr253 data FAILED: --- log/check-expected 2005-10-16 01:03:54.000000000 +1000 +++ log/check-generated 2005-10-16 01:03:54.000000000 +1000 @@ -1,11 +0,0 @@ -total 20 -drwxr-xr-x 8 98 98 512 Oct 22 13:06 . -drwxr-xr-x 8 98 98 512 Oct 22 13:06 .. -drwxr-xr-x 2 98 98 512 May 2 1996 .NeXT --r--r--r-- 1 0 1 35 Jul 16 1996 README -lrwxrwxrwx 1 0 1 7 Dec 9 1999 bin -> usr/bin -dr-xr-xr-x 2 0 1 512 Oct 1 1997 dev -drwxrwxrwx 2 98 98 512 May 29 16:04 download.html -dr-xr-xr-x 2 0 1 512 Nov 30 1995 etc -drwxrwxrwx 2 98 1 512 Oct 30 14:33 pub -dr-xr-xr-x 5 0 1 512 Oct 1 1997 usr - abort tests TESTDONE: 0 tests out of 1 reported OK: 0% TESTFAIL: These test cases failed: 253 TESTDONE: 1 tests were considered during 3 seconds. dan@frog /var/tmp/portage/curl-7.15.0/work/curl-7.15.0/tests $ more log/ check-expected curl.log server.input sockdataipv6.log stdout253 check-generated ftpd.log sockctrlipv6.log stderr253 verifyftp dan@frog /var/tmp/portage/curl-7.15.0/work/curl-7.15.0/tests $ more log/stderr253 01:03:54.593324 * About to connect() to ::1 port 8996 01:03:54.593530 * Trying ::1... connected 01:03:54.595141 * Connected to ::1 (::1) port 8996 01:03:54.595210 < 220- _ _ ____ _ 01:03:54.595253 < 220- ___| | | | _ \| | 01:03:54.595294 < 220- / __| | | | |_) | | 01:03:54.595335 < 220- | (__| |_| | _ <| |___ 01:03:54.595377 < 220 \___|\___/|_| \_\_____| 01:03:54.596147 > USER anonymous 01:03:54.596231 < 331 We are happy you popped in! 01:03:54.596935 > PASS curl_by_daniel@haxx.se 01:03:54.597016 < 230 Welcome you silly person 01:03:54.597681 > PWD 01:03:54.597761 < 257 "/nowhere/anywhere" is current directory 01:03:54.597810 * Entry path is '/nowhere/anywhere' 01:03:54.603018 > EPRT |2|::1|33924| 01:03:54.603111 < 200 Thanks for dropping by. We contact you later 01:03:54.603162 * Connect data stream actively 01:03:54.603887 > TYPE A 01:03:54.603969 < 200 I modify TYPE as you wanted 01:03:54.607410 > LIST 01:03:54.607500 < 150 here comes a directory 01:03:54.607607 * Connection accepted from server lt-curl: stack smashing attack in function AllowServerConnect() Needs to be fixed before AT as some 3.4.4 gccs are stable. AT - as you see from the below you have the option of: add net-dns/c-ares with your keyword or use.masking ares net-misc/stunnel is used in 7 self tests that are fairly good. It isn't required though. DEPEND.bad 8 net-misc/curl/curl-7.15.0.ebuild: ~alpha(default-linux/alpha/2005.0) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~arm(default-linux/arm/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~hppa(default-linux/hppa/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~ia64(default-linux/ia64/2005.0) [ 'net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~mips(default-linux/mips/2004.2) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~ppc64(default-linux/ppc64/2005.0) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~s390(default-linux/s390/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~sparc(default-linux/sparc/sparc64/2005.1) ['net-dns/c-ares'] RDEPEND.bad 8 net-misc/curl/curl-7.15.0.ebuild: ~alpha(default-linux/alpha/2005.0) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~arm(default-linux/arm/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~hppa(default-linux/hppa/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~ia64(default-linux/ia64/2005.0) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~mips(default-linux/mips/2004.2) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~ppc64(default-linux/ppc64/2005.0) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~s390(default-linux/s390/2004.3) ['net-dns/c-ares'] net-misc/curl/curl-7.15.0.ebuild: ~sparc(default-linux/sparc/sparc64/2005.1) ['net-dns/c-ares'] note for glsa: put revdep-rebuild fix instructions to be sure
if no proper solution can be found: append-flags -fno-stack-protector works.
Hardened peoples - any chance of a proper fix? Fails with: gcc (GCC) 3.4.4 (Gentoo Hardened 3.4.4-r1, HTB-3.4.4-1.00, ssp-3.4.4-1.0, pie-8.7.8) Works with: gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) curl-7.15.0/lib/ftp.c -> stack smashing attack in function AllowServerConnect()
The guts of testcase 253 start dummy server /var/tmp/portage/curl-7.15.0/work/curl-7.15.0/tests $ make test chmod ugo+x ftpserver.pl ./ftpserver.pl --pidfile .ftp6.pid -s . --ipv6 --port 8996 start curl test: /var/tmp/portage/curl-7.15.0/work/curl-7.15.0/tests $ env LD_LIBRARY_PATH=../lib/.libs/ gdb --args ../src/.libs/curl --output log/curl253.out --include -v --trace-time -g "ftp://[::1]:8996/" -P - For details of another failed test 1. Get the server command and client command strace -fe trace=process ./runtests.pl 2. Run server 3. run client in gdb 4. look in log directory: contains outputs.
dragonheart: since it's not a regression (it was already failing in past versions) please unmask it so that we call for arch testing...
unmasked and ready for keywording. Most self tests work except detailed above (these failed in previous versions).
note: net-dns/c-ares will probably require keywording too.
Currently the curl ebuild seems to only supports c-ares on x86 for some reason (not sure the decision behind this). Also are us arch monkeys just keywording some version of curl now or also some version of wget as well?
yes if someone can cite specific versions I'd be happy to keyword for ppc64
both wget and curl done on x86
Ok, let me see... There is no "need" to mark any wget stable, since only the ~ version (1.10.*) was vulnerable to this. But of course you can mark 1.10.2 stable if you want to. For curl, you need to mark stable the following : - net-misc/curl-7.15.0 - some net-dns/c-ares version in order to solve the c-ares dep.
Stable on hppa (thanks to hansmi for fixing curl) and ppc (tested by hansmi).
Marked net-misc/curl-7.15.0 ppc64 stable and marked c-ares-1.2.1-r1 ~ppc64
sparc stable.
net-misc/curl-7.15.0 and c-ares-1.2.0 (as dep) are now marked "stable" on alpha. Alpha Done.
amd64 done curl-7.15.0 and c-ares-1.2.1-r1
curl-7.15.0 stable on mips. I've masked the ares USE flag on mips for the time being as I don't really feel comfortable marking it stable for mips when there were previously no mips keywords.
GLSA 200510-19 arm, ia64 and s390 should mark stable to benefit from GLSA ppc-macos should mark ~
marked curl-7.15.0 and c-ares-1.3.0 ~ppc-macos
