[Secure-testing-team] Security update: proftpd-dfsg 1.3.1-17

[Francesco P. Lovergine]

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