/
Bugzilla – Bug 3536
mod_sql has insufficient bounds checking in sql_prepare_where() function
Last modified: 2011-02-08 14:09:04 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
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.
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).
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.
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.
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.
Patch committed to CVS.
Backported to 1.3.3 branch.
Resolved in 1.3.4rc1.
Official CVE for this issue, for future reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4652