Secure testing team - Feb 2009 - 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

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

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