Oracle from unbreakable to unpatchable

Oracle from unbreakable to unpatchable

Summary: In a twist of irony, the proof-of-concept shellcode produces a sample text file on the server called "unbreakable.txt" with the string "ARE YOU SURE?" inside. When Larry Ellison boldly proclaimed Oracle was "unbreakable" to the world, the crackers of the world boldly responded with "root".

TOPICS: Oracle

When people complain about patching two or three vulnerabilities every month on their Windows machine, I can't help but chuckle when I think about the dire situation Oracle users are in.  Oracle, which has always bragged about being "unbreakable" and "never breaks" just released its quarterly critical patch update composed of fixes for 82 critical vulnerabilities in nearly every Oracle product.  Many organizations using Oracle leave themselves exposed to these fresh exploits for months. Unfortunately, the most critical vulnerability for the Oracle PL/SQL Gateway, which allows a hacker to gain full administrative control of a back-end database from anywhere on the Internet, was left unpatched -- even though it was disclosed to Oracle in October of 2005.

David Litchfield, who discovered the bug and reported it to Oracle, demonstrated the vulnerability at the Black Hat 2006 Federal Briefing in Washington DC.  Litchfield then posted this workaround so that organizations can mitigate the vulnerability, but blasted Oracle for not making a patch available for this quarter's patch cycle which means Oracle users will be exposed for another 90 days.  Although the proof-of-concept exploit code wasn't released by Litchfield, it's only a matter of time before some smart hacker reverse engineers the workaround if they haven't done so already.  Any organization using Oracle PL/SQL Gateway should apply Litchfield's workaround as soon as possible and also apply any of the other 82 critical patches that pertain to them.

To make matters worse, another critical flaw called DB18 affecting Oracle database 8i/9i/10g discovered by Imperva was fixed in this quarter's mega-patch two months after the flaw was reported.  This particular bug is so nasty because it affects every Oracle database in the past five years and allows a hacker to escalate their privileges from guest to database administrator.  Since Oracle deployments are complex with many critical dependencies from application servers that might break during an update, it often takes weeks or more to plan and test an Oracle patch of this scope.  As a result, many organizations using Oracle leave themselves exposed to these fresh exploits for months.

If you thought this was the end of it, an XML database component buffer overflow proof-of-concept exploit in Oracle Database Server 9i/10g was released to the Internet yesterday.  This particular flaw allows a hacker to launch shellcode on an Oracle database server to obtain complete control.  In a twist of irony, the proof-of-concept shellcode produces a sample text file on the server called "unbreakable.txt" with the string "ARE YOU SURE?" inside.  When Larry Ellison boldly proclaimed Oracle was "unbreakable" to the world, the crackers of the world boldly responded with "root".

This would almost be funny if this wasn't for the fact that a significant chunk of the world's most sensitive data resides on Oracle databases.  The reason this isn't more commonly known is because it's difficult for ordinary computer users to relate since Oracle is something that's usually tucked away in a server room somewhere.  Hackers who do hack into Oracle usually never do it for bragging rights by defacing a website but do it for serious financial gain by stealing critical information.  The last thing these hackers want is notoriety because it makes it harder to do business.  Unfortunately, this lack of outcry has allowed Oracle to continue on with these quarterly mega-patches while spouting their "never breaks" slogan.  Every CIO or IT manager who pays hundreds of thousands of dollars a year in Oracle licensing fees should be ringing Oracle's phone off the hook because they're certainly not getting their money's worth.

Topic: Oracle

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Firewall/VLAN

    In larger organizations, where Oracle is typically running on 'big iron', e.g., SUN/Solaris, there is this 'anal rentitive nature' especially with HIPAA, regarding security, and, as I am sure you know, with layers of Cisco physical/VLAN architectures and LDAP/ActiveDirectory, it's pretty difficult to get 'near' a database, unless you were authorized to be there in the first place, starting with having to be on the 'inside' of a Firewall and in a specific VLAN or, if 'outside', via VPN, combined with Intrusion Detection methods.

    Perhaps this will help to move Oracle to address the security issues you raise.

    Thanks George for an excellent article.
    D T Schmitz
    • SOX compliance similiar

      we have a similiar setup, all our critical oracle databases and systems are in a complete lockdown (from an intranet perspective), so any risk assesment shows we are only vunerable from our intranet, and only from servers where applications are allowed to connect to the oracle database.

      So a disgruntled employee may be able to actually see the exploit, if they hack into one of the applicaiton servers. Maybe someone will try, it has been really quiet lately and would be exciting to see someone forcefully removed from the building...
      • This is NOT an intranet issue

        The gateway vulnerability allows full admin access to the backend from anywhere on the Internet. It's an application gateway in the DMZ that's wide open here.
        • Oracle PL/SQL Gateway would not be allowed for us

          ...since it provides an access point from the external network to the internal, a definite no-no since we have financial transaction data that is used on one of our oracle databases.

          We do have a home-grown external web server that is used for customer reports, but our fw is configured to allow internal-->external only and is used to push reporting data in excel spreadsheets via ssh...
          • Like I said, you figure out if it pertains to you

            Still, you have your work cut out for you to install all the other patches.
          • Me2

            With HIPAA, I would be put up against the nearest wall and shot if found passing data with ftp.

            ssh is a must! :)

            Thanks Doolittle.
            D T Schmitz
    • No, you don't get it

      That unpatched gateway vulnerability bypasses all those layers of VLAN/Firewall protection you speak of. I know Gartner put their foot in thier mouth a couple of months ago when they made the argument for Oracle over MS SQL by saying that "Oracle tends to be behind firewalls".

      Firewalls do nothing to block an applicatation vulnerability when the Oracle ports have to be open. IDS might have a chance at detecting this but these types of things are easy to confuse with legitimate application requests.
      • Assumptions

        Now you assume that they're exposing their database to the world by putting the gateway in the DMZ. There are numerous thinkable setups where it's not necessary to do so and still have webaccess to your database.

        Yes, if somebody put the gateway in the DMZ, they're vulnerable. If they've devised another way via additional security measures they're save. That's the problem with all vulnerabilities regardless of OS or vendor. It all depends on your setup!!!!
        • When did I make an assumption? This is a warning

          I never made any assumptions. I listed the vulnerability and it's up to the admin to interpret the information.

          However, the fact that an Oracle server is not in the DMZ exposed to the Internet doesn't make me feel a whole lot better. No one should ever depend on the hard on the outside soft on the inside security model. The point is that the vulnerability is still serious even if it's only accessible via Intranet. It only takes on computer to get rooted on the inside to bypass the firewall. You should stop making excuses for Oracle.
          • Did I make an excuse for Oracle??

            You're Dead funny George
          • Alright, no assumptions here, no excuses there

            It just sounded like an excuse. Oracle DBAs and Gartner are famous for making the old "Oracle is usually behind a firewall" excuse.

            But to be fair, I didn't make any assumptions, you didn't make any excuses.

            Like I said, it doesn't matter if it is behind a firewall or not. Oracle has some serious quality issues to work out.
    • didn't I read somewhere...

      that many of the attacks on servers originate from the inside of a corporate firewall? I don't know that a firewall offers as much security against attacks is it appears to offer.
      • Firewalls don't do much for open services

        Firewalls are wide open as far as the HTTP protocol is concerned. All the firewall does is mask the services you don't use.

        And yes you're right, plenty of attacks occur behind the firewall in the soft underbelly of the network.
  • Bizarre conjecture ...

    How can you say that SQL Server is the only competitor to Oracle? Oracle lost its #1 position in the market to DB2 last year. As I understand the market shares, it's DB2 at number 1, with Oracle a close second and SQL Server off in the distance. As you point out, not many people are willing to allow a platform with such a dreadful security history as Windows to manage their critical enterprise data, although this article seems to indicate that Oracle isn't much better. I don't know if DB2 is any better, but I haven't heard anything to indicate that there are problems there.

    Interestingly, the freebie MySQL is making enormous inroads into the corporate space too. Maybe this year we'll see MS pushed back to 4th place.
    • DB2 - It's got other issues

      We're prepping to move from DB2 to Oracle. While DB2 has been ok from a security standpoint, it has been a bear to work with in other regards. Our z/OS DB2 is very unwieldy from a system maintenance standpoint. Where Oracle can do reorgs in hours, DB2 has taken DAYS to reorg. That's a HUGE disadvantage for any organization that is intent on keeping on schedule.

      The other real weakness is the immaturity of IBM's Windows-based offerings. We use DB2 Connect to hook up Windows app servers with the z/0S-based DB2 database. Windows versions of IBM software are bug riddled. It's obvious they've been ported from another platform and minimally tested, if at all. For example, attempting to change the default install location, or other default settings during the installation, can cause the software to fail upon initial execution. It ends up being apparent that the default choices are the only true choices in some instances. Too bad someone at IBM didn't take the time to test more thoroughly. Oh, and in some circumstances they'll make you assign full admin rights to service accounts running the software in Windows. So IBM makes some terrible security decisions when running on the Windows platform. Yeah, Microsoft has its issues, but "respected" vendors will fall into sloppy security practices when on Windows, by no fault of Microsoft.
  • MS NEVER this bad

    In Microsoft's worst years, they were never this bad. They never had a hundred critical patches a quarter.
    • Hence 'Service Packs'

      That's why they have 'Service Packs'. Many flaws will be fixed in those packs. I'm sure you remember the 20.000+ bugs which were fixed for Windows2000 at the time.
      • 20,000 is some number tossed out their for beta version

        When was the last time you remembered 82 or 100+ patches in a 3 months period. Oracle has averaged about 100 fatal flaws since they started their quarterly update program.
    • Misleading...'re misleading people:
      1) In general, MS tends to underrate the severity of their defects.
      2) Of the 103 defects in the "risk grid" (yes, I followed the link and looked at the list), only 29 of them are specific to the Oracle database...the rest are for Oracle applications/suites.
      3) The risk factors of each vulnerability resulting in violations of confidentiality and integrity of the database are "Difficult" for 18 of 29. Those 18 can affect availability.
      4) Many of the other 11 require some specific permissions, as do some of the 18.

      To summarize, most of the flaws can at worst affect availability, with many of the remaining being not necessarily wide open, if the db is configured with appropriate permission restrictions. Certainly, some of these flaws should not exist - there are a few that clearly indicate a lack of thought. But this is by no means a worse situation than Microsoft is often in.
      • Nice spin

        If you combine all the IIS bugs and all the MS SQL bugs in the last few years, it wouldn't add up to one of these quarterly mega patches. There's no way around it, Oracle has some serious quality control issues which is surprising given the amount of money they charge. These quarterly mega-patches are an embarrassment anyway you spin it.