In the 2.3 timeframe, a serious security bug was fixed. Hibernate treats 
backslashes differently from some
database management systems and as a result native SQL can be injected through 
the searchDocuments function.
This means members of a wiki can finish an SQL query, also this means that 
badly written searchDocuments or
search queries go from small security issues to larger ones.

NOTE: Passwords are hashed (encrypted) so they cannot easily be read from the 

Who's at risk?

Database systems which treat backslash as an escape character and allow stacked 
queries are susceptible to
arbitrary SELECT, INSERT, UPDATE, DELETE, and DROP statements.
These include:

Database systems which treat backslash as an escape character but disallow 
stacked queries are susceptible
only to arbitrary SELECT statements.
These include:

Database systems which do not treat backslash as an escape character are not 
vulnerable these include:
HSQLDB (default XWiki zip/exe installation)

You can get a small groovy snippet to test your database and see if it supports 
stacked queries here:

What can be done:

#1: XWiki-2.3 and XWiki-2.2.6 Are patched to convert \ to \\ in search queries 
so upgrading to them will
negate the threat. You can download them here:

#2: If you compile your own branch of XWiki and are unable to upgrade, you can 
integrate the patch which
was used to fix the problem The patch is here:
Since the database controller has changed, you will likely have to port this 
patch to your version, what's
important is that api.XWiki.searchDocuments and have their 
input filtered.

#3: You can and should make sure to log unexpected SQL at the database level. 
XWiki doesn't usually use
the backslash character and queries containing backslashes should be logged 
specially. Also it is a good
idea to log (or block if possible) any SQL comment syntax. Hibernate does not 
support comments and comment
syntax is central to almost all SQL injection.


users mailing list

Reply via email to