David,
It seems you missed it. To be honest I don't understand your email.
The problem exists and I have 36+ Oracle vulnerabilities (="dozens" in
10.2.0.1) where I can bypass dbms_assert. Oracle is aware of this problem
and has already assigned bug numbers for my findings (e.g. "7569081 - SQL
INJECTION IN PARAMETER 1 of ***").
I never claimed that dbms_assert is insecure nor do I recommend using
dbms_assert in this (insecure) way with three consecutive quotes. My PL/SQL
samples show only the generic concept of bypassing dbms_assert. Oracle is
using this construct 30+ time in 10.2.0.1.
If you are interested I can show you next week some working examples/
exploits at the Black Hat in Las Vegas...
Regards
Alexander
P.S.: The search strings are "dbms_assert.simple_sql_name" and
"dbms_assert.qualified_sql_name".
--
Red-Database-Security GmbH
www.red-database-security.com
-----Original Message-----
From: David Litchfield [mailto:davidl@ngssoftware.com]
Sent: Friday, July 28, 2006 6:42 AM
To: ak@red-database-security.com; bugtraq@securityfocus.com
Subject: Re: Bypassing Oracle dbms_assert
Today I released a new whitepaper "Bypassing Oracle dbms_assert".
<SNIP>
Oracle has no problem with the release of this information
("Oracle sees no problem with your publication of the
white paper.")
The reason Oracle sees no problem with the release of the paper is that
for
your technique to work the DBMS_ASSERT.QUALIFIED_SQL_NAME has to be used
in
the wrong context; you simply wouldn't use QUALIFIED_SQL_NAME in this
manner - i.e. within quotes. I've just had a quick look through the SYS
packages and find no instance of DBMS_ASSERT.QUALIFIED_SQL_NAME being used
this way. If there is such a case, in other words I've missed it, then it
would be a flaw in the package/procedure/function itslef and not a problem
with DBMS_ASSERT - with the fix being to use the correct DBMS_ASSERT
function instead of QUALIFIED_SQL_NAME or alternatively use a bind
variable.
Cheers,
David
