Program: glftpd Homepage: http://www.glftpd.com/ Vulnerable Versions: current stable (1.32-r1) Risk: Low / Medium Impact: multiple Local Stack Buffer Overflow Vulnerabilities, remote vulnerability suspected -- description (Homepage) glFTPd is a free FTP server for UNIX based systems. It is highly configureable and its possibilities are endless. One of the main differences between many other ftp servers and glFTPd is that it has its own user database which can be completely maintained online using ftp site commands. glFTPd runs within a chroot environment which makes it relatively safe. i have found several local buffer overflows in various utilities included in the glftpd ftp server software. affected utilities include: dirlogclean: $ ./dirlogclean -r `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ $ ./dirlogclean `perl -e 'print "A"x2280'`/tmp/testing [AAAAA] Segmentation fault (core dumped) $ dupescan: $ ./dupescan `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ formateduser: $ ./formateduser `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ $ ./formateduser -r `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ ...lots more... the daemon itself is closed source. given the code quality of the commandline utilities, i assume the server itself is also vulnerable and ( remote!!! ) exploitable in various ways. i also assume, that the daemon binary calls some of the affected support binaries while running. this automatically leads to a remote exploitable vulnerability. the author states in his FAQ: ---
Program: glftpd Homepage: http://www.glftpd.com/ Vulnerable Versions: current stable (1.32-r1) Risk: Low / Medium Impact: multiple Local Stack Buffer Overflow Vulnerabilities, remote vulnerability suspected -- description (Homepage) glFTPd is a free FTP server for UNIX based systems. It is highly configureable and its possibilities are endless. One of the main differences between many other ftp servers and glFTPd is that it has its own user database which can be completely maintained online using ftp site commands. glFTPd runs within a chroot environment which makes it relatively safe. i have found several local buffer overflows in various utilities included in the glftpd ftp server software. affected utilities include: dirlogclean: $ ./dirlogclean -r `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ $ ./dirlogclean `perl -e 'print "A"x2280'`/tmp/testing [AAAAA] Segmentation fault (core dumped) $ dupescan: $ ./dupescan `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ formateduser: $ ./formateduser `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ $ ./formateduser -r `perl -e 'print "A"x880'`/tmp/testing Segmentation fault (core dumped) $ ...lots more... the daemon itself is closed source. given the code quality of the commandline utilities, i assume the server itself is also vulnerable and ( remote!!! ) exploitable in various ways. i also assume, that the daemon binary calls some of the affected support binaries while running. this automatically leads to a remote exploitable vulnerability. the author states in his FAQ: --- · Where can i get the source-code? Nowhere, it is not released for several reasons. 1. Evil hackers could find exploits easier and not report them. 2. Wanna-be 'coders' would start many variants of glftpd that they would claim are their own and they probably wouldn't share any work they do. There are several people with access to the source code; when we are confident that #1 is not a big issue and when we no longer care about #2, we will release the source code. --- so my recommendation is to security-hardmask this package until the author releases a new, possibly open source version. best regards florian [rootshell]
Reading their site, they seem to have good confidence that their code is secure. They say the other utilities (like dupescan) are not called by the main program, so overflows in them aren't a real problem. We just can't mask this package because we suppose their remote-accessible code is bad... I suppose they put a lot more care in FTP commands processing than in external support programs. If we have something meaty, I think we should contact them to be sure. Which is the support program that might be called by the closed-source one ?
when we had the dupescan bug before and i e-mailed the devs, that was pretty much their position ... the extra utils are fluff (and full of bugs), but arent called by the processes that handle remote connections might want to review the 2.0_rc candidates and see if these problems still exist; they've fixed a bunch there
Created attachment 41248 [details, diff] 1.32-stack-overflow.patch An updated patch to fix mentioned overflows. dupescan.c was already patched.
The previous dupescan vulnerability was GLSA 200409-27. vapier, could you verify and replace the stack overflow patch? thanks!
1.32-r2 is in portage
security, please vote on GLSA. (note: we released GLSA 200409-27 for the dupescan issue also mentioned in this bug)
I've mixed feelings on this. I think we shouldn't have released an advisory in the first place. Buffer overflows in client utilities that have no obvious reasons of being SUID or being called by an external application shouldn't generate GLSAs. But since we have released 200409-27, there are two solutions. - Do nothing - Update the existing GLSA (adding new version, updating description, downgrading to Low severity) We should wait for the boss opinion on this.
Given that this has no apparent exploit vector, I don't see what makes it a security vulnerability, myself, which means I don't see why we should do anything about it at all. We cannot audit programs that are in portage, and we certainly cannot audit closed-source programs. If we wish to restrict this, I think we'd have to start a policy of restricting all closed-source applications on the suspicion of bad coding practices. Which would suck.
there's a lot of assumptions made in the original bug report which make me leery of issuing a GLSA. If we can demonstrate a remote attack, then I think we should issue a GLSA. Otherwise, I vote for no GLSA.
Closing without GLSA.
