Full_Name: Anatoly Version: 2.4.19 OS: GNU/Linux URL: Submission from: (NULL) (89.169.85.181) I'm using openldap 2.4.19 with sql backend. I have a troubles with queries that contains single-quote ( ' ) character. For example, if I searching for (cn=Zool'man): <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') Constructed query: SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') id: '2' backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: syntax error at or near "MAN" at character 271; In this case query should be like varchar_ci(phpbb_users.username)='ZOOL\'MAN' instead of 'ZOOL'MAN' Additionally, I fear this opens a possibility of sql injection, depending on RDBMS.
changed notes
changed notes moved from Incoming to Software Enhancements
moved from Software Enhancements to Software Bugs
Can confirm this with openldap 2.4.24. Using ldap search filters like this: (cn=blabla' or '1'='1) is at least causing my postgres to eat all CPU cycles it can get (LDAP data is based on complex view). I do not have write access enabled for that particular openLDAP installation, but I also assume that SQL Injection is possible. Beside being an obviuos malfunction, this should be considered a security issue. atze
atze_80@web.de wrote: > Can confirm this with openldap 2.4.24. Thanks, the bug was already confirmed. > > Using ldap search filters like this: > > (cn=blabla' or '1'='1) > > is at least causing my postgres to eat all CPU cycles it can get (LDAP > data is based on complex view). I do not have write access enabled for > that particular openLDAP installation, but I also assume that SQL > Injection is possible. Beside being an obviuos malfunction, this should > be considered a security issue. As the bug status says, "patches welcome." back-sql is not a priority for any of the core developers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
is escaping portable? use prepare instead; patch welcome
I have made a patch for this problem. https://gist.github.com/akagisho/0d0d148c94616b84a513 2011-03-10 2:37 GMT+09:00 Howard Chu <hyc@symas.com>: > atze_80@web.de wrote: >> >> Can confirm this with openldap 2.4.24. > > > Thanks, the bug was already confirmed. >> >> >> Using ldap search filters like this: >> >> (cn=blabla' or '1'='1) >> >> is at least causing my postgres to eat all CPU cycles it can get (LDAP >> data is based on complex view). I do not have write access enabled for >> that particular openLDAP installation, but I also assume that SQL >> Injection is possible. Beside being an obviuos malfunction, this should >> be considered a security issue. > > > As the bug status says, "patches welcome." back-sql is not a priority for > any of the core developers.
Created attachment 617 [details] ITS-6461-escape-single-quotes-in-back-sql.patch
(In reply to akagisho from comment #7) > I have made a patch for this problem. > > https://gist.github.com/akagisho/0d0d148c94616b84a513 Your work is missing the required IPR information as detailed at https://www.openldap.org/devel/contributing.html#notice Please provide the appropriate IPR Regards, Quanah
Escaping with a backslash appears to be non-portable. All the major SQL implementations escape a single quote by doubling it, as done in the patch for ITS#9815.
*** This issue has been marked as a duplicate of issue 9815 ***