|Summary:||<net-ftp/proftpd-1.3.3d: SQL Injection Vulnerability when used with mod_sql (CVE-2010-4652)|
|Product:||Gentoo Security||Reporter:||Bernd Lommerzheim <bernd>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||enhancement||CC:||hanno, net-ftp, proxy-maint|
|Package list:||Runtime testing required:||---|
Description Bernd Lommerzheim 2010-12-18 09:33:29 UTC
Hello, on 17/Dec/2010 ProFTPD 1.3.3d [1,2] with a some bugfixes and ProFTPD 1.3.4rc1 [3,4] with new features have been released. For ProFTPD 1.3.3d a simple version bump of the ProFTPD 1.3.3c ebuild should work without problems. And for ProFTPD 1.3.4rc1 I will attach a patch against proftpd-1.3.3c with the following improvements: * Bump mod_vroot to 0.9. * Move mod_deflate from an external module to a contrib module. * Add support for the new modules mod_copy, mod_ifversion and mod_qos. * Remove blocking check for a running ProFTPD pre 1.3.3. When ProFTPD 1.3.4 will get stable ProFTPD 1.3.3d will be stable for over a half year and then everybody should migrated the pid file to it's new location. * Add support for finding the MySQL and PostgreSQL headers and libraries automatically. Works fine for me. Although upstream did not mark the ProFTPD 1.3.3d release to fix important security bugs I think it does: ProFTPD 1.3.3d and 1.3.4rc1 are fixing ProFTPD Bug #3536  and as far as I remember this bug might be the problem that was used to break into ftp.proftpd.org a few weeks ago. Nevertheless I think we should quickly add ProFTPD 1.3.3d to the portage tree and start a stabilization request for it. Best regards. Bernd Lommerzheim  http://www.proftpd.org/docs/RELEASE_NOTES-1.3.3d  http://www.proftpd.org/docs/NEWS-1.3.3d  http://www.proftpd.org/docs/RELEASE_NOTES-1.3.4rc1  http://www.proftpd.org/docs/NEWS-1.3.4rc1  http://bugs.proftpd.org/show_bug.cgi?id=3536
Comment 1 Bernd Lommerzheim 2010-12-18 09:34:10 UTC
Created attachment 257480 [details, diff] proftpd-1.3.4_rc1.ebuild patch (against proftpd-1.3.3d.ebuild)
Comment 2 Hanno Böck 2010-12-22 23:32:27 UTC
I'm pretty sure this is security relevant, from release-notes: + Fixed sql_prepare_where() buffer overflow (Bug#3536)
Comment 3 Tim Sammut (RETIRED) 2010-12-22 23:48:09 UTC
@net-ftp, is mod_sql enabled by default (or only with USE='mysql')?
Comment 4 Bernd Lommerzheim 2010-12-23 00:46:44 UTC
(In reply to comment #3) > @net-ftp, is mod_sql enabled by default (or only with USE='mysql')? No, the module "mod_sql" gets only built into ProFTPD when using USE="mysql" or USE="postgres".
Comment 5 Bernard Cafarelli 2011-01-13 15:20:15 UTC
Sorry for the delay here. No CVE on this but reading the bugreport and: http://www.securityfocus.com/bid/44933 http://phrack.org/issues.html?issue=67&id=7#article it's indeed better to stable 1.3.3d, I have added it to the tree, stable target keywords are: alpha amd64 hppa ppc ppc64 sparc x86
Comment 6 Tim Sammut (RETIRED) 2011-01-14 07:44:31 UTC
(In reply to comment #5) > Sorry for the delay here. > No problem; thank you for the new ebuild. Arches, please test and mark stable: =net-ftp/proftpd-1.3.3d Target keywords : "alpha amd64 hppa ppc ppc64 sparc x86"
Comment 7 Kacper Kowalik (Xarthisius) (RETIRED) 2011-01-14 09:02:10 UTC
Comment 8 Agostino Sarubbo 2011-01-14 09:48:02 UTC
Comment 9 Markos Chandras (RETIRED) 2011-01-14 22:22:11 UTC
amd64 done. Thanks Agostino
Comment 10 Paweł Hajdan, Jr. (RETIRED) 2011-01-15 10:48:24 UTC
Comment 11 Jeroen Roovers (RETIRED) 2011-01-18 18:00:46 UTC
Stable for HPPA.
Comment 12 Tobias Klausmann 2011-02-05 20:10:38 UTC
Stable on alpha.
Comment 13 Raúl Porcel (RETIRED) 2011-02-12 17:52:22 UTC
Comment 14 Tim Sammut (RETIRED) 2011-02-12 18:19:03 UTC
xiexie folks. Added to existing GLSA request.
Comment 15 GLSAMaker/CVETool Bot 2011-06-24 00:36:29 UTC
CVE-2010-4652 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4652): Heap-based buffer overflow in the sql_prepare_where function (contrib/mod_sql.c) in ProFTPD before 1.3.3d, when mod_sql is enabled, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted username containing substitution tags, which are not properly handled during construction of an SQL query.
Comment 16 GLSAMaker/CVETool Bot 2013-09-24 23:39:23 UTC
This issue was resolved and addressed in GLSA 201309-15 at http://security.gentoo.org/glsa/glsa-201309-15.xml by GLSA coordinator Sean Amoss (ackle).