[NEWS] IBM Informix Web DataBlade Vulnerable to Auto-decoding of HTML Entities
From: support@securiteam.comDate: 04/14/02
- Previous message: support@securiteam.com: "[EXPL] INN Security Problems Allow Gaining of news Privileges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Sun, 14 Apr 2002 22:02:45 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
IBM Informix Web DataBlade Vulnerable to Auto-decoding of HTML Entities
------------------------------------------------------------------------
SUMMARY
The <http://www-4.ibm.com/software/data/informix/blades/web/> Informix
Web DataBlade module is a collection of tools, functions, and examples
that ease development of "intelligent", interactive, Web-enabled database
applications. The Web DataBlade module supports most Web Server
Application Programming Interfaces (APIs), and enables a truly interactive
Web site. A security vulnerability in the product allows attackers to
insert into existing SQL queries their own arbitrary content, thus
compromising the integrity of the database.
DETAILS
Vulnerable systems:
Web DataBlade 4.12, IDS 9.20/9.21 running under Linux 2.2/2.4 or SunOS 5.7
(NOTE that the OS, IDS and WDB versions seem to be irrelevant)
Details:
HTML encoded strings are automatically being decoded when used in SQL
statements. It causes developers to create code that looks fine but
actually contains holes, since the logic is circumvented by WDB.
Any worthy web/database programmer checks all user input before using it
in an SQL query. WDB has a function $(WEBUNHTML) which converts the
characters <>"& to their HTML entities. When a string has been
$(WEBUNHTML)'ed it should thus be safe to use it in an SQL query, provided
that you enclose the string in double quotes (there can not be any double
quotes inside the string).
However, somewhere on the path before the SQL query is being executed the
HTML entities are actually decoded into their original character
representations. We have not found this documented anywhere, and even if
it were documented, we would consider it a bug.
Example:
<!-- Make inputstr harmless -->
<?MIVAR NAME=inputstr>$(WEBUNHTML,$inputstr)<?/MIVAR>
<!-- Build query to insert the checked string -->
<?MIVAR NAME=qstr>INSERT into mytable VALUES ("$inputstr")<?/MIVAR>
<!-- Execute query -->
<?MISQL SQL="$qstr"><?/MISQL>
Besides of being an example of just how ugly WDB code is, this code looks
correct; it runs $inputstr though the $(WEBUNHTML) function before
inserting. However, the query will actually fail if the original $inputstr
contained a double quote, and it can therefore be exploited to execute
other SQL code. The string is HTML decoded again somewhere, that is, the "
is converted back to a real double quote.
At first one may think that all the user can do is to make a query fail,
by inserting just one quote somewhere, and that the attacker would have to
know the exact query in order to actually make it succeed while being
circumvented. However, it is much simpler than that. The webexplode()
function will always be available, and it can be used to execute SQL of
choice. Since it returns string data, it can simply be concatenated to
other string data, thus executing any SQL, even without interrupting the
original query.
Proof of concept:
Given the code above, the malicious user would have to put something like
the following into an "inputstr" field in an HTML form and submit it:
" || webexplode("<?MISQL SQL='INSERT INTO sysusers
VALUES(...)'><?/MISQL>", NULL) || "
This INSERT query writes to a sensitive part of the database, and returns
nothing at all. The query on the HTML page would therefore succeed;
nothing is actually changed in the input that it sees. Moreover, the
attacker does not even have to know the query that is circumvented.
Impact:
Malicious user may insert SQL code in form input and have it executed,
even if the developer has escaped the input properly; Web DataBlade
actively un-escapes the input afterwards. This is serious since your code
*looks* like it escapes the input, so an auditor will not catch the error
unless he actually looks at the data at the point of execution in the
database engine. It is much harder to spot than to just find input that is
not escaped at all and therefore likely to exist in great amounts of WDB
code. While this may not strictly be a security bug in itself, it
certainly fools the developer and leads to holes.
Workaround:
Run input data through $(WEBUNHTML) twice. The SQL interpreter will HTML
decode that string, but then the first level of HTML encoding will be
preserved, i.e. there can be no <>"& characters in it.
ADDITIONAL INFORMATION
The information has been provided by <mailto:simonl@mirrormind.com> Simon
Lodal.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[EXPL] INN Security Problems Allow Gaining of news Privileges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
