Francesco P. Lovergine
2009-Feb-06 12:46 UTC
[Secure-testing-team] Security update: proftpd-dfsg 1.3.1-17
Hi RMs and security teams I just uploaded a new version of proftpd-dfsg on sid fixing a recently discovered security issue. After some discussion with TJ (proftpd PM) The problem is not of interest for 1.3.0 (etch version) because it lacks relevant code present in successive versions. At the same time, I found a libtool-related problem due to an uncomplete cleaning of working files, which causes a FTBS in 1.3.1-16 with current libtool. Relevant changelog: proftpd-dfsg (1.3.1-17) unstable; urgency=high . * Security: added 3173.dpatch patch to manage a critical encoding-dependent SQL injection with SQL-based authentication. See http://bugs.proftpd.org/show_bug.cgi?id=3173. This is fixed in 1.3.2. Thanks TJ for backported patch. * Now debian/rules removes at cleaning time a couple of .la files under contrib/ still around after building. This fixes a recently discovered FTBS error due to those files. Cheers. PS: No CVE code is assigned at my knowledge at this time. -- Francesco P. Lovergine -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090206/9bb8fb96/attachment.pgp
Steffen Joeris
2009-Feb-06 13:14 UTC
[Secure-testing-team] Security update: proftpd-dfsg 1.3.1-17
Hi Francesco Thanks for informing us.> I just uploaded a new version of proftpd-dfsg on sid fixing a recently > discovered security issue. After some discussion with TJ (proftpd PM) > The problem is not of interest for 1.3.0 (etch version) because it lacks > relevant code present in successive versions. At the same time, I found > a libtool-related problem due to an uncomplete cleaning of working > files, which causes a FTBS in 1.3.1-16 with current libtool. > > Relevant changelog: > > proftpd-dfsg (1.3.1-17) unstable; urgency=high > . > * Security: added 3173.dpatch patch to manage a critical > encoding-dependent SQL injection with SQL-based authentication. > See http://bugs.proftpd.org/show_bug.cgi?id=3173. This is fixed in > 1.3.2. Thanks TJ for backported patch. > * Now debian/rules removes at cleaning time a couple of .la files > under contrib/ still around after building. This fixes a recently > discovered FTBS error due to those files. > > Cheers. > > PS: No CVE code is assigned at my knowledge at this time.I am not sure that the issue really exists. Since upstream quotes similar CVE ids, I know that for mod-auth-mysql to be exploitable, it had to be possible to specify the client encoding. Same goes for courier-authlib, which had a similar issue. So there was some code present already, which could be used to set the client encoding to some multibyte encoding, like GBK. After a quick glance, I don''t see this code in current proftpd-dfsg. However, I only checked the two sql mod files. Could you check as well and point me to the code that makes it possible to set the client encoding? Also, do you have a possible exploit, which you could email us in a private mail? If this issue is really present, then note that upstream uses PQescapeString() instead of PQescapeStringConn(). The former being deprecated[0], because afaik it does not honour the encoding of the connection. This would most likely make the fix for postgresql incomplete. Cheers Steffen [0]: http://www.postgresql.org/docs/7.4/static/libpq-exec.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090206/6878079b/attachment.pgp
Francesco P. Lovergine
2009-Feb-06 13:57 UTC
[Secure-testing-team] Security update: proftpd-dfsg 1.3.1-17
On Fri, Feb 06, 2009 at 08:14:47AM -0500, Steffen Joeris wrote:> Hi Francesco > > Thanks for informing us. > > I just uploaded a new version of proftpd-dfsg on sid fixing a recently > > discovered security issue. After some discussion with TJ (proftpd PM) > > The problem is not of interest for 1.3.0 (etch version) because it lacks > > relevant code present in successive versions. At the same time, I found > > a libtool-related problem due to an uncomplete cleaning of working > > files, which causes a FTBS in 1.3.1-16 with current libtool. > > > > Relevant changelog: > > > > proftpd-dfsg (1.3.1-17) unstable; urgency=high > > . > > * Security: added 3173.dpatch patch to manage a critical > > encoding-dependent SQL injection with SQL-based authentication. > > See http://bugs.proftpd.org/show_bug.cgi?id=3173. This is fixed in > > 1.3.2. Thanks TJ for backported patch. > > * Now debian/rules removes at cleaning time a couple of .la files > > under contrib/ still around after building. This fixes a recently > > discovered FTBS error due to those files. > > > > Cheers. > > > > PS: No CVE code is assigned at my knowledge at this time. > I am not sure that the issue really exists. Since upstream quotes similar CVE > ids, I know that for mod-auth-mysql to be exploitable, it had to be possible > to specify the client encoding. Same goes for courier-authlib, which had a > similar issue. So there was some code present already, which could be used to > set the client encoding to some multibyte encoding, like GBK.Do you mean the *sql client, I think. Proftpd server has the mod_lang.c modules and the UseEncoding directive starting from 1.3.2, which could be used to inject multi-byte chars into sql instructions used by a sql auth modules. The 1.3.1 version has not the Encoding API but since 1.3.1-16 the --enable-nls does allow the admin to specify UseUTF8 with similar effects AFAIK. On the ftp client side OPTS UTF8 can be used to try an alternative encoding.> After a quick glance, I don''t see this code in current proftpd-dfsg. However, > I only checked the two sql mod files. Could you check as well and point me to > the code that makes it possible to set the client encoding? > Also, do you have a possible exploit, which you could email us in a private > mail? > If this issue is really present, then note that upstream uses PQescapeString() > instead of PQescapeStringConn(). The former being deprecated[0], because > afaik it does not honour the encoding of the connection. This would most > likely make the fix for postgresql incomplete. > > Cheers > Steffen > > [0]: http://www.postgresql.org/docs/7.4/static/libpq-exec.htmlI''ll forward this information to upstream. -- Francesco P. Lovergine