Bugtraq mailing list archives
ftpd: the advisory version
From: lamagra () HACKERMAIL NET (Lamagra Argamal)
Date: Fri, 23 Jun 2000 09:18:22 -0000
You might have seen the wuftpd exploit by tf8, he released it in his own lame way. But now I bring you the story behind it. The story begins inside the ftpcmd.y file. Which has the ftp commands in it. The bug is in the site_exec(char *cmd) function. There is calls lreply(200,cmd); In ftpd.c we find void lreply(int n, char *fmt,...) .... vreply(USE_REPLY_LONG, n, fmt, ap) ... and void vreply(long flags, int n, char *fmt, va_list ap) ... vsnprintf(buf + (n ? 4 : 0), n ? sizeof(buf) - 4 : sizeof(buf), fmt, ap) .... cmd becomes fmt with vsnprintf that's bad. The idea is to put in formatstrings to get some extra priviledges. We can use %n to overwrite some stuff. eg. overwrite a ret-address or a null at the end of a buffer (cause an overflow) or change the configuration or uid like I did in my proftp exploit (check proftp_pcc.c on Packetstorm). There are some other bugs in site_exec like for (t = cmd; *t && !isspace(*t); t++) { if (isupper(*t)) { *t = tolower(*t); } } Sanitizing stops at a space?? (good thing I didn't tell you this, eh tf8) Wuftpd is all really buggy code. I prefer proftpd, it has clean, readable code and it's quite secure. I did some checking and found some minor bugs there too First in modules/mod_pam.c /* Allocate our entries...we don't free this because PAM does this for us. */ pam_user = malloc(strlen(cmd->argv[0]) + 1); if(pam_user == (char *)0) return pam_return_type ? ERROR(cmd) : DECLINED(cmd); sstrncpy(pam_user, cmd->argv[0], strlen(cmd->argv[0]) + 1); pam_pass = malloc(strlen(cmd->argv[1]) + 1); Pam doesn't free these according to me. So this could lead to a pottential system DoS if abused. Fortunatly proftpd has a limit of 3 on USER/PASS. Second: In the set_proc_title(char *fmt,...) function in main.c It constructs a buffer with hostname + user + cmd to replace argv[0]. If setproctitle(char *fmt,...) is available (only on debian and bsd). It calls setproctitle(statsbuf); what re-opens the old bug Not a big thing since almost nobody has it. -lamagra http://lamagra.seKure.de http://roothat.labs.pulltheplug.com Send someone a cool Dynamitemail flashcard greeting!! And get rewarded. GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41
Current thread:
- Re: WuFTPD: Providing *remote* root since at least1994 Bernhard Rosenkraenzer (Jun 22)
- Re: WuFTPD: Providing *remote* root since at least1994 Daniel Jacobowitz (Jun 22)
- Re: WuFTPD: Providing *remote* root since at least1994 Marcus Meissner (Jun 23)
- Why pine must never be sgid Stan Bubrouski (Jun 23)
- sawmill5.0.21 old path bug & weak hash algorithm Cashdollar, Larry (Jun 26)
- Re: WuFTPD: Providing *remote* root since at least1994 Tomasz Grabowski (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Bernhard Rosenkraenzer (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Gregory A Lundberg (Jun 27)
- ftpd: the advisory version Lamagra Argamal (Jun 23)
- Re: ftpd: the advisory version Bernd Luevelsmeyer (Jun 25)
- Re: ftpd: the advisory version Sebastian (Jun 26)
- [RHSA-2000:037-05] New Linux kernel fixes security bug bugzilla () REDHAT COM (Jun 26)
- LeafChat Denial of Service Andrew Lewis (Jun 25)
- Netscape Enterprise Server for NetWare Virtual Directory Vulnerab ility Peter Grundl (Jun 26)
- Re: ftpd: the advisory version Bernd Luevelsmeyer (Jun 25)
- <Possible follow-ups>
- Re: WuFTPD: Providing *remote* root since at least1994 Peter Pentchev (Jun 23)
- Re: WuFTPD: Providing *remote* root since at least1994 der Mouse (Jun 25)
- Re: WuFTPD: Providing *remote* root since at least1994 Mikael Olsson (Jun 26)
- Re: WuFTPD: Providing *remote* root since at least1994 Theo de Raadt (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Carson Gaspar (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Mikael Olsson (Jun 26)
(Thread continues...)
- Re: WuFTPD: Providing *remote* root since at least1994 Daniel Jacobowitz (Jun 22)