The History of the Oracle PLSQL Gateway Flaw
In the past few days Oracle has criticized me for publishing a workaround
for a critical flaw in their PLSQL Gateway. This email will show that after
4 years of waiting for Oracle to try to get it right, I eventually decided
to take matters into my own hands and provide Oracle customers with more
help than Oracle is currently doing. Oracle - shame on you:
The Oracle PLSQL Gateway sits on a web server and allows web users to
execute PLSQL applications in an Oracle database server. When first
introduced, as long as a web user had the permission to execute the PLSQL
procedure and knew its name then they could execute it through the PLSQL
gateway. This clearly opens up a massive security risk and Oracle introduced
what is known as the PLSQLExclusionList to help limit exposure. Essentially,
if a web user attempts to access any plsql package listed in the exclusion
list then the Gateway rejects the user's request with a "forbidden" message.
So access to anything that started with "SYS.", for example, would be
blocked.
Or that's what's supposed to happen, anyway. There are two distinct problems
with this solution. Firstly, it's never worked and the exclusion list can be
totally bypassed and secondly, it's a half baked idea to begin with. Let's
delve deeper and examine both of these
When Oracle first introduced the exclusion list in 2001 it could be
trivially bypassed by preceding the plsql package name with a newline
character
http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROCEDURE
I advised Oracle about this bypass problem in 2001 and, once Oracle
"patched" this, I published details in "Hackproofing Oracle Application
Server" (http://www.ngssoftware.com/papers/hpoas.pdf)
It didn't take long to discover that this patch could be bypassed using the
following techinque: due to internationalization, an Oracle database server
will convert the ÿ character (value 0xFF) to a capital Y. The PLSQL Gateway
will not. Thus, if we request
http://www.example.com/pls/dad/S%FFS.PACKAGE.PROCEDURE
the gateway will happily pass it over to the database server where the ÿ is
conveted to a Y and we can gain access again.
Oracle issued a patch for this but this patch was broken, too. What's
interesting is the story behind how I found the next bypass technique. I had
just reported some flaws in a few PLSQL applications in the database server
but there was only a risk if an attacker could bypass the exclusion list. As
Oracle had just released a "fix" for the bypass problem they stated they
were not going to fix the backend flaws. This is from the email they sent me
informing me that they weren't going to fix these issues
"We feel that our latest fix to security alert #68 will now correctly block
any request that matches the patterns defined in the exclusion list. The
OWA_OPT_LOCK package falls under the OWA_* pattern. Therefore, this request
will be blocked by the exclusion list feature. Since the exclusion list
cannot be bypassed anymore, we are not allowing anyone to call this package
from the browser, and thereby, blocking this PL/SQL injection from
happening."
This angered me as it was clear laziness on Oracle's part and they were
deliberately leaving their customers at risk. I then set out to find a new
bypass technique and eleven minutes after reading this mail I found what I
was looking for. This new bypass technique simplly involved enquoting -
putting SYS in double quotes:
http://www.example.com/pls/dad/"SYS".PACKAGE.PROCEDURE
Whilst this bypass worked on Oracle Application Server 9 - it didn't on 10g.
The technical reason for this is as follows. 10g App Server converts the
upper case SYS to the lower case sys - and if something is enquoted - it
needs to match the right case. However, a bypass trick that did work with
10g was to use angle brackets - these form a label in PLSQL.
http://www.example.com/pls/dad/<<LABEL>>SYS.PACKAGE.PROCEDURE
So come July 2005 Oracle had really made a mess of all this and introduced
their next patch. This can be bypassed too - this is the one I posted a
workaround for and we're all currently waiting on Oracle fixing.
Going back to the second problem - that is - the PLSQL Exclusion List is a
half baked idea to begin with. The exclusion list, by default, attempts to
block access to the following
SYS.*
DBMS_*
UTL_*
OWA_*
OWA.*
HTP.*
HTF.*
Thus, by default, access to packages owned by accounts such as CTXSYS or
MDSYS is not blocked. These two accounts are both DBAs and, what's more,
many of the PLSQL applications owned by these accounts have suffered from
security flaws. As the exclusion list doesn't block access to these
accounts, these flaws can be exploited via the web server to gain complete
control of the database server. The point is the exlusion list is a "black
list" solution and the problem with black lists is that you need to know in
advance everything that is bad and should be black listed. It's a much
easier proposition to know what is not bad though and only allow access to
this. This is a "white list" solution and I've been asking Oracle to give us
a white list solution to this problem for four years now - but they still
haven't done it. Explaining this further - let's say my web plsql
application consists of one package called "banking" and this package has a
number of procedures that implement typical banking tasks such as
"transfer", "pay", "show_balance", etc, etc. If I had a white list solution
then I could say allow access if and only if the web users request starts
with "banking" and reject everything else. This is an entirely much more
secure and robust solution than the "black list" approach.
Will we ever be given this as a solution? Who knows. As it seems providing a
decent security solution is beyond Oracle at the moment - I'm not holding my
breath.
Come on Oracle - get your stuff together!
Cheers,
David Litchfield