Musings on Database Security

Ah, finally home after 10 days of travel. I attended the UKOUG event in Birmingham and did a database security presentation and participated in a security round table. I also attended very interesting presentations by Pete Finnigan and Paul Wright.

One noteworthy presentation was called Breaking Oracle which showed how to create scenarios where the Oracle database crashes or spins. I thought that some of the examples in the presentation were major security issues that allow users to crash or spin Oracle with very simple queries.
Please don’t try this on your database -
select 1 from dual where regexp_like(‘ ‘,’^*[ ]*a’);
Or this:
SQL> create table t2(col1 varchar2(60));
SQL> create table t1(c1 varchar2(60),
c2 varchar2(1),
c3 varchar2(60),
c4 varchar2(60));
SQL> explain plan for
select 1 from t1 a, t2 b ,t1 c
where b.col1 = ‘xxslc_department’
and a.c1 not between c.c3 and c.c4
start with a.c2=’p’
connect by prior a.c1 between a.c3 and a.c4;

I thought long and hard about what I was going to present during this conference. I did not want to do the usual stuff of unsecure/default passwords, securing the listener or applying patches. I wanted to present something that would give the attendees a real call-to-action they could take with them immediately after the conference. So, I decided to do something simple that would demonstrate SQL injection on a made-up function and show how you should protect this function. Also, I wanted to show how DBAs could find such vulnerable code in the database and fix it.

(more…)

I was invited to post a guest editorial on Ryan Naraine’s Zero Day blog over on ZDNet on the topic of database patching, which you are welcome to read.

In anticipating some responses to that post, I’d like to distill further what I intended to convey. From my exposure to database operations of enterprises large and small, the one issue that keeps haunting me is the database patching issue, about which I’ve posted in the past. Some enterprises do a good job of it, but they are the minority. In most cases, the patching issue seems so insurmountable that instead of doing at least selective patching, companies have a “deer in the headlights” reaction and choose stagnation.

This is asking for trouble. I’ve said it once and I’ll say it again – forget all the sophisticated zero-day hacks. Most database attackers will use the easy way in – a published exploit of a known vulnerability. You can’t protect yourself against everything, but you shouldn’t knowingly leave your DBMS wide open. Imagine that you read in the paper that burglars had a master key that can open all locks of a certain brand – wouldn’t you check to see if your door lock was of that make, and have it changed if it were?

So this is why patching is important, but we know it’s also difficult, which is why I proposed this pragmatic approach. It basically says – minimize what you have to patch, prioritize what’s important to patch and the trade-offs with business interruption and cost, then patch according to your priorities. Go into this with your eyes wide open rather than just gambling on not being next… Doing something is better than doing nothing.

When it’s logistically difficult to patch regularly, or to gain an extra layer of security, virtual patching for databases provides a low-cost, low-overhead solution with minimal interruption to daily operations.