http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5815 Very little information available at the moment.
Indeed... please keep me posted if you manage to get more information.
Gentoo person suggested, that this might be related to this. Though I didn't give it a look... But it seema unlikely to me, because this looks like related to a configuration file parsing bug. http://proftp.cvs.sourceforge.net/proftp/proftpd/src/main.c?r1=1.292&r2=1.293&sortby=date http://bugs.gentoo.org/show_bug.cgi?id=152473 I'm puzzled at all... did Evgeny report it in silence or not at all?
Aah, this is the line that is added: cmd_buf_size = 512; Buffer size limit was not set correctly in case CommandBufferSize had been specified in the config file. But it is present neither in any of sample config files from proftpd distribution nor in Fedora Core default one. Thus I assume this is not related with the issue, or is it?
Strange report... one seems to have to pay in order to get access to the code that supposedly triggers the exploit and the proftpd devs seem completely silent about the issue.
Pointer to this was Evgeny's response to my direct question towards him. Seems, like that part of code didn't change since 2004 (http://proftp.cvs.sourceforge.net/proftp/proftpd/contrib/mod_tls.c?view=annotate), so might still be exploitable. http://elegerov.blogspot.com/2006/10/do-you-remember-2-years-old-overflow.html
The FrSIRT advisory has more info: http://www.frsirt.com/english/advisories/2006/4451 "ProFTPD version 1.3.0rc5 and prior" may be incorrect though as the CVS change the advisory points to was made on Oct 31 but 1.3.0 final has been packaged for half a year already.
Oh, and the FrSIRT advisory implies that this would indeed be the same issue that Lubomir mentioned in comments 2 and 3.
Do you think, that Evgeny would sell an exploit for something, that is so unlikely (if possible at all) to exploit. I guess not. Please rethink it :)
In this case, I don't think, I report findings ;)
OK, I've queued a rebuild for devel with the patch applied. After some testing, I'll backport the patch to FC5 and FC6 branches too.
(In reply to comment #10) Excuse me, but how can you apply a patch and enqueue a build for devel, backport to FC5 and FC6, when we/you do not know what the issue is?
See the FrSIRT advisory, the section "A fix is available via CVS", which links to the change you already suggested. Since it does not say when exactly the "remote exploit" is available, it might be with non default settings, who knows (not me).
Created attachment 141353 [details] contrib/mod_tls.c buffer overflow patch Hi Matthias, I have one more patch for you :) This one is from the OpenPKG project and it fixes the mod_tls issue i mentioned in Comment #5.
Created attachment 141513 [details] Revised version of proftpd-1.3.0-cmdbufsize.patch The patch in CVS (Comment #2) appears to dereference a null pointer in the default case where the config file doesn't have a CommandBufferSize specified: > if (cmd_buf_size == -1) { > - long *buf_size = get_param_ptr(main_server->conf, > - "CommandBufferSize", FALSE); > + int *bufsz = get_param_ptr(main_server->conf, "CommandBufferSize", > + FALSE); > > - if (buf_size == NULL || *buf_size <= 0) > - cmd_buf_size = 512; > + if (bufsz == NULL || > + *bufsz <= 0) { > + pr_log_pri(PR_LOG_WARNING, "invalid CommandBufferSize size (%d) " > + "given, resetting to default buffer size (%u)", > + *bufsz, (unsigned int) PR_DEFAULT_CMD_BUFSZ); > + cmd_buf_size = PR_DEFAULT_CMD_BUFSZ; In the case where bufsz is NULL, there is a reference to *bufsz when the log message is done. I found this caused a segfault immediately on connection. Attached patch handles the cases of "buf_size == NULL" and "*buf_size <= 0" separately.
It seems the bug has already been disclosed to the public (like myself :-). Also proftpd-1.3.0a which fixes this problem is available. So far it seems that unpacking proftpd-1.3.0-6.src.rpm, and changing the Version: from 1.3.0 to 1.3.0a (and Release: to 1) is sufficient to build an updated package. Please make a new RPM as soon as possible.
Okay, just so to summarize what was discovered by Evgeny Legerov, disclosed and now fixed: There are two issues: sreplace() stack overflow, which is the vd_proftpd.pm VulnDisco metasploit exploit -- http://www.gleg.net/proftpd.txt. This is fixed in 1.3.0a mod_tls pre-auth buffer overflow. This is in VulnDisco since January 2006 and is not yet fixed in 1.3.0a. So I disagree with Jan's comment #15, updating to 1.3.0a is _not_ sufficient. It is needed to patch for also for the mod_tls issue, because mod_tls.c module is included in Fedora package by default. An attachment #141353 [details] should fix that.
That patch appears to be in the Extras package as of Nov. 16th.
Yes, and the update to 1.3.0a has been pushed to FC-5 and FC-6 as of today, so I'll be closing this bug report, unless someone has yet another patch for yet another (possible) exploit to have included in the package ;-)
> Yes, and the update to 1.3.0a has been pushed to FC-5 and FC-6 as of today, so > I'll be closing this bug report, unless someone has yet another patch for yet > another (possible) exploit to have included in the package ;-) I think anything new probably can get its *own* bug. :)
Just a note, FE-3 and 4 seem to still ship < 1.3.0a.
The mod_tls issue is now CVE-2006-6170 and cmdbufsize CVE-2006-6171
I have to admit that I've been mostly lost lost with all these reports... Is it OK with how things stand now? (1.3.0a for F5 & F6, 1.3.1rc for F7) Is it still possible to rebuild for F3 and F4 at all?
CVE-2006-5815 is the remote code execution detailed here : http://www.securityfocus.com/archive/1/archive/1/452760/100/200/threaded It was fixed in 1.3.0a, which all supported branches (FC-5, FC-6 and FC-7) have been updated too, so I'll be closing this bug. For any other vulnerabilities, please open new bug reports (the mod_ctrls buffer overflow is already bug #219938).