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@xxxxxxxxxxxxxxx] > Sent: Friday, July 28, 2006 6:42 AM > To: ak@xxxxxxxxxxxxxxxxxxxxxxxxx; bugtraq@xxxxxxxxxxxxxxxxx > 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 > >
