Databases Reference
In-Depth Information
overflow vulnerability (see Chapter 1), and the arguments passed to the
procedure can come from a user of the application. This technique is gen-
eral and can be used in any database environment, but in order to make the
discussion more concrete, I will use a specific Oracle example as published
in a security advisory from February 2004 by Integrigy. By the way, Oracle
has already released security patches solving these problems (and the infor-
mation on the vulnerability is available in the public domain), so I feel at
liberty to discuss how this works.
At the time, Oracle 8i and 9i included six standard Oracle database
functions with buffer overflow vulnerabilities. These functions are part of
the core database and cannot be restricted:
BFILENAME—Oracle 8i, 9i
FROM_TZ—Oracle 9i
NUMTODSINTERVAL—Oracle 8i, 9i
NUMTOYMINTERVAL—Oracle 8i, 9i
TO_TIMESTAMP_TZ—Oracle 9i
TZ_OFFSET—Oracle 9i
Let's look at FROM_TZ as an example. FROM_TZ converts a times-
tamp value and a time zone to a timestamp with time zone value. The time
zone value is passed in as a character string in the format tz_hour:tx_minute.
For example, if I want to get the time right now adjusted for Eastern time
zone, I can perform the following select statement:
SELECT FROM_TZ(TIMESTAMP '2004-09-07 18:00:00', '5:00') FROM
DUAL;
Unfortunately, FROM_TZ is vulnerable to long strings used in the time
zone parameter. If I were to issue a select of the form:
SELECT FROM_TZ(TIMESTAMP '2004-09-07 18:00:00',
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa') FROM DUAL;
I would overflow the stack, and if I were to craft the long string in a wise
way, I could plant an appropriate return address on the stack, as described in
Chapter 1. Because Oracle runs under an administrator account in Windows,
this attack allows for a complete compromise of the host. In UNIX (because
 
Search WWH ::




Custom Search