Safe Databases Are Key to Security

Oracle rates the severity of many of these vulnerabilities as Level 1, its highest level. There are no work-arounds; Oracle recommends applying available patches immediately. (Please test your patches before sending them to production servers!) Go to www.oracle.com/ for details.

Oracle reportedly sat on both the vulnerabilities and patches before releasing them. In an interview after the Black Hat Briefings convention in July, David Litchfield, managing director of U.K. vendor Next-Generation Security Software, said he had notified Oracle of 34 vulnerabilities early in the year. Oracle fixed those holes a couple of months ago, he said, but then waited to release the fixes as it was transitioning to a monthly patch update cycle. Incidentally, this release cycle is now the same as Microsoft's.

What's at Stake

As Richard Hoffman notes in our Buzzcut, there's no such thing as unbreakable software, no matter what Oracle or any other vendor says. Any application attached to a network has vulnerabilities--most just haven't been found yet. At the same time, your database administrator better have limited database access to only those people and applications in need of it.

Fact is, our most important information is stored in databases. Customer information. Financial data. Research results. We build complex applications that access this information, often through app servers that sit on the Web. Who cares about getting the keys to the kingdom via OS access when intruders can just as easily go directly for the database gold?Depending on the way your application is designed, you could provide different levels of access for intruders. If your database is back-ending a Web application, intruders coming in through a Web front end can use SQL injection attacks or buffer overflows on the application server. If they have direct access to the database, they have more protocols to leverage, and they can throw arbitrary, nonscrubbed commands to the database itself.

Validating input for type and length information is critical. If your Web developers are scrubbing the data correctly before any of it gets sent back to the database server, they're limiting your vulnerability. For example, your developers can prevent SQL injection attacks with proper coding techniques that validate all input. Database-oriented buffer overflows can be caught by the application before they're passed to the database server--the application itself should be sending only "clean" data to the server.

Application server vulnerabilities are a little scarier, because the app server itself is more often outward-facing. If your developers rely on the app server to make database calls, they have to trust the server vendor to prevent those same SQL injection attacks through the same clean coding practices your developers use.

In the end, your database and network design may help prevent some critical database vulnerabilities from becoming exploitable. If you build a three-tier network, you won't have end-user applications that directly send SQL to the DBMS, and you'll have a buffer (the application server) between the DB server and the data. However, vulnerabilities in the application server itself can provide the holes.

Mike Lee is Network Computing's editor. Write to him at [email protected].0