[Secure-testing-team] Security update: proftpd-dfsg 1.3.1-17
Steffen Joeris
steffen.joeris at skolelinux.de
Fri Feb 6 13:14:47 UTC 2009
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
More information about the Secure-testing-team
mailing list