netkit-ftpd/ftp uninitialized vulnerability [Security Advisory] Advisory: [AD_LAB-07009] netkit-ftpd/ftp uninitialized vulnerability Class: Design Error DATE:11/1/2007 CVEID:CVE-2007-5769 Vulnerable: netkit-ftpd-0.17/netkit-ftp-0.17 Vendor: I.Synopsis A vulnerability has been discovered in netkit-ftpd/ftp. II.DETAILS: ---------- Background netkit-ftpd is the Linux Netkit FTP server with optional SSL support. netkit-ftp is the client for the ftp protocol. Description There is a uninitialized vulnerability in function dataconn() in ftpd.c. static FILE * dataconn(const char *name, off_t size, const char *mode) { char sizebuf[32]; FILE *file; <-uninit variable. ... if (SSL_accept(ssl_data_con)<=0) { 1459 static char errbuf[1024]; 1460 1461 snprintf(errbuf, sizeof(errbuf), "ftpd: SSL_accept DATA error %s\n", 1462 ERR_error_string(ERR_get_error(),NULL)); 1463 perror_reply(425, errbuf); 1464 /* abort time methinks ... */ 1465 fclose(file); <-- close an uninit value. 1466 return NULL; Program received signal SIGSEGV, Segmentation fault. 0x6fca33fd in fclose () from /lib/libc.so.6 (gdb) bt #0 0x6fca33fd in fclose () from /lib/libc.so.6 #1 0x0804c601 in dataconn (name=0x77add110 "/bin/ls", size=<value optimized out>, mode=0x8053f4f "w") at ftpd.c:1465 #2 0x0804d3f8 in retrieve (cmd=0x80550c7 "/bin/ls -lgA", name=0x77add110 "/bin/ls") at ftpd.c:1197 #3 0x0805193a in yyparse () at ftpcmd.y:378 ) at ftpd.c:685 in order to trigger this bug, the client should use the passive mode to transfer data. and the SSL_accept should failed at line ftpd.c:1458. the client broke the connection will cause the SSL_accept failed. same problem occur in netkit-ftp's getreply() too. 467 int 468 getreply(int expecteof) 469 { ........ 520 (void) signal(SIGINT,oldintr); 521 code = 221; 522 return (0); 523 } 524 lostpeer(0); 525 fclose(cout); Program received signal SIGSEGV, Segmentation fault. 0x6fcb73fd in fclose () from /lib/libc.so.6 (gdb) bt #0 0x6fcb73fd in fclose () from /lib/libc.so.6 #1 0x0804fb9c in getreply (expecteof=0) at ftp.c:525 #2 0x0804fe49 in abort_remote (din=0x8099a20) at ftp.c:2117 #3 0x08052400 in recvrequest (cmd=0x80567f1 "LIST", local=0x8059400 "-", remote=0x0, lmode=0x8056b44 "w", printnames=0) at ftp.c:1288 #4 0x0804bcb5 in ls (argc=1, argv=0x80650e0) at cmds.c:1429 #5 0x08055382 in main (argc=-817625725, argv=0xc3010805) at main.c:484 Impact Reading uninitialized variables can result in unpredictable behavior, crashes, or security holes. III.CREDIT: ---------- Venustech AD-LAB discovery this vuln. Thank to all Venustech AD-Lab guys. V.DISCLAIMS: ----------- The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages. Copyright 1996-2007 VENUSTECH. All Rights Reserved. Terms of use. VENUSTECH Security Lab VENUSTECH INFORMATION TECHNOLOGY CO.,LTD(http://www.venustech.com.cn) Security Trusted {Solution} Provider Service Reproducible: Always
Is there a fix available somewhere?
As for ftp (client): Fedora / RHEL packages include one patch (netkit-ftp-0.17-segv.patch) which seems to address this issue. Patch was written by Alan Cox and is included in our ftp packages as of June 2004. Patch: http://cvs.fedora.redhat.com/viewcvs/rpms/ftp/F-8/netkit-ftp-0.17-segv.patch?view=auto VenusTech, can you please provide more information of how to reproduce ftp client crash so we can verify whether this problem is properly addressed by this patch? Thanks!
(In reply to comment #2) > Fedora / RHEL packages include one patch (netkit-ftp-0.17-segv.patch) which > seems to address this issue. Patch was written by Alan Cox and is included in > our ftp packages as of June 2004. Oh well, that patch is included in ftp ebuilds and it actually seems to introduce the problem. Following patch was added few months ago: http://cvs.fedora.redhat.com/viewcvs/rpms/ftp/F-8/netkit-ftp-0.17-sigseg.patch?view=auto
yep,this ftp client crash addressed by this patch.
we public the adv in fd. http://seclists.org/fulldisclosure/2007/Dec/0174.html.
The ftpd issue was assigned CVE-2007-6263 and it is still unfixed. The ftp issue is CVE-2007-5769 and a patch can be found in comment 3. Rerating B3 as this is only confirmed as DoS. base-system, can you apply the one patch and prepare a similar one for ftpd? Initializing and checking for NULL should do the trick. Thanks.
(In reply to comment #6) > The ftpd issue was assigned CVE-2007-6263 and it is still unfixed. Patch is here: http://people.debian.org/~nion/nmu-diff/linux-ftpd-ssl-0.17.18+0.3-9_0.17.18+0.3-9.1.patch Base-system, please bump.
base-system, are there plans on fixing these two issues? If not, we'll have a look.
*netkit-ftpd-0.17-r7 (10 Jan 2008) 10 Jan 2008; Robert Buchholz <rbu@gentoo.org> +files/netkit-ftpd-0.17-fclose-CVE-2007-6263.patch, -netkit-ftpd-0.17-r6.ebuild, +netkit-ftpd-0.17-r7.ebuild: Security: Fix a double-fclose vulnerability in the dataconn function (CVE-2007-6263, #199206) *ftp-0.17-r7 (10 Jan 2008) 10 Jan 2008; Robert Buchholz <rbu@gentoo.org> +files/netkit-ftp-0.17-sigseg.patch, +ftp-0.17-r7.ebuild: Security: Fix a double-fclose() vulnerability in the getreply function (CVE-2007-5769, #199206)
Arches, please test and mark stable net-ftp/netkit-ftpd-0.17-r7. Target keywords : "alpha amd64 arm ia64 ppc s390 sh sparc x86" The issue in ftp (not ftpd) is not considered to be a security vulnerability, as it only allows to crash a client program. It is fixed in net-ftp/ftp-0.17-r7, arches are free to stable that version as they prefer.
ppc and ~ppc64
* Applying netkit-ftpd-0.17-fclose-CVE-2007-6263.patch ... * Failed Patch: netkit-ftpd-0.17-fclose-CVE-2007-6263.patch ! * ( /usr/portage/net-ftp/netkit-ftpd/files/netkit-ftpd-0.17-fclose-CVE-2007-6263.patch ) If USE=ssl is NOT set.
Sorry, my fault. I fixed that in-place and dropped ppc. Brent, please keyword again.
x86 stable
Nothing to do here!?
re-ppc'd
amd64 done.
arm/s390/sh done... http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-ftp/netkit-ftpd/netkit-ftpd-0.17-r7.ebuild?r1=1.7&r2=1.8
alpha/ia64/sparc stable mips doesn't have it keyworded
GLSA vote. I'm in for a YES.
I tend to vote YES.
Since no one voted NO, this is a yes then :-)
GLSA 200801-17