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.html I'll forward this information to upstream. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
