/ Bug 3536 – mod_sql has insufficient bounds checking in sql_prepare_where() function
Bug 3536 - mod_sql has insufficient bounds checking in sql_prepare_where() function
: mod_sql has insufficient bounds checking in sql_prepare_where() function
Status: CLOSED FIXED
Product: ProFTPD
mod_sql
: 1.3.3
: All All
: P2 major
Assigned To: TJ Saunders
:
: Backport
:
:
  Show dependency treegraph
 
Reported: 2010-11-18 17:30 UTC by mail
Modified: 2011-02-08 14:09 UTC (History)
2 users (show)

See Also:


Attachments
Adds bounds-checking to the sql_prepare_where() function, and other places in mod_sql (18.54 KB, patch)
2010-11-22 21:39 UTC, TJ Saunders
Details
Updates previous patch (20.81 KB, patch)
2010-11-22 21:45 UTC, TJ Saunders
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mail 2010-11-18 17:30:46 UTC
Today the Phrack Magazine released an article about an Remote Root Exploit for
ProFTPD with mod_sql enabled!

>> http://www.phrack.org/issues.html?issue=67&id=7&mode=txt

According to Securityfocus, the latest official Release 1.3.3c is also
affected!

>> http://www.securityfocus.com/bid/44933/info

Please have a look at, so it can be fixed as soon as poosible!

Kind Regards,
Gerrit Helm
Comment 1 TJ Saunders 2010-11-19 13:54:45 UTC
As mentioned in the Phrack article, there are several issues:

  1.  mod_sql *prior to proftpd-1.3.2rc2* had a SQL injection attack (Bug#3124,
       CVE-2009-0542)

  2.  mod_sql's sql_prepare_where() function has an unbounded copy operation

In order to exploit the second issue, the first one MUST be used.  That avenue
was fixed in 1.3.2rc3.  Thus the Phrack article is NOT about a remote root
exploit in recent versions -- it is demonstrating that the second issue still
exists.  Note that the Phrack article does NOT demonstrate an attack avenue
using a proftpd version more recent than 1.3.2rc2.

I am going to handle this bug report, then, for fixing the bounds-checking
issue in mod_sql's sql_prepare_where() function.
Comment 2 TJ Saunders 2010-11-19 13:58:49 UTC
The sql_prepare_where() function in mod_sql used to be named _sql_where().  The
ability to handle variables, and thus the bounds-checking vulnerability, first
appeared in proftpd-1.3.1rc1 (see Bug#2828).
Comment 3 TJ Saunders 2010-11-22 21:39:23 UTC
Created attachment 3465 [details]
Adds bounds-checking to the sql_prepare_where() function, and other places in
mod_sql

This patch hopefully addresses the issue in mod_sql.  In addition to the
sql_prepare_where() function, there were a few other places where a buffer
(statically allocated, rather than allocated using palloc/pcalloc) were being
written into with e.g. substituted variables/tags -- bounds-checking has been
added to the places that I found.

Having people try out this patch, make sure it doesn't break anything would be
great.
Comment 4 TJ Saunders 2010-11-22 21:45:36 UTC
Created attachment 3466 [details]
Updates previous patch

Updates previous patch to fix a minor issue with regard to the %r tag when
handling the internally-created 'getgroups' Auth API lookup.  This came up as
part of investigating this issue.
Comment 5 TJ Saunders 2010-11-23 19:51:47 UTC
To test out these bounds-checking changes, I manually changed the
SQL_MAX_STMT_LEN length in mod_sql.c to something short, something like 128 or
somesuch, and then issued long commands/names and watched the SQLLogFile.
Comment 6 TJ Saunders 2010-11-30 14:22:02 UTC
Patch committed to CVS.
Comment 7 TJ Saunders 2010-11-30 14:26:44 UTC
Backported to 1.3.3 branch.
Comment 8 TJ Saunders 2010-12-18 12:56:57 UTC
Resolved in 1.3.4rc1.
Comment 9 TJ Saunders 2011-02-08 14:09:04 UTC
Official CVE for this issue, for future reference:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4652