Entries tagged with “cpus”.


Ah, time flies when you’re having fun. It seams that only yesterday we worked on the October CPU and now Oracle released the January CPU.

This time, Oracle acknowledged 24 security fixes, 9 of them in the database layer. This number is a bit lower than the average but as in the previous CPU, you have a vulnerability that can be exploited remotely without authentication to take control of the machine (on Windows) or the Oracle account (on *nix).

Analyzing the CPU provides an interesting story. As always, Oracle talks about x vulnerabilities but actually patches y (which is much bigger than x). In this CPU, we’ve already analyzed more than 15 different vulnerabilities and we’re still counting!

Based on the severity of some of the vulnerabilities, if you have one of the supported versions you know you need to patch!
It’s also important to understand that if you have any 9i, 10gR1, 10gR2 or 11gR1 you’re vulnerable. Oracle just provides CPUs to the latest patch-sets.

I’m happy to see three Sentrigo researchers were credited in this CPU (including myself!). Go Red Team!

Of course, Sentrigo customers are already protected against many of the vulnerabilities using our own vPatches and we will release updated vPatches to cover the others.

In this case, my advice to wait a week to make sure that there are no issues with the patch and then patch as soon as possible since the vulnerabilities are so severe. Patch as soon as possible – but only after ensuring that your applications are not breaking.

If you can’t patch quickly or unable to patch at all due to valid reasons , try virtual patching as a stop-gap solution.

Oracle has released the October CPU with 38 announced security fixes (and more under the covers). 16 database vulnerabilities out of which a mind blowing 6 may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password. Also, 3 of those will allow you to completely compromise the machine!
If you have one of the mentioned versions (9.2.0.8, 10.1.0.5, 10.2.0.4) you know you need to patch!
It’s also important to understand that if you have any 9i, 10gR1 or 10gR2, you’re vulnerable. Oracle just provides CPUs to the latest patch-sets.

The usual suspects are present in the credits – Alex, David, Joxean, Dennis, Cesar, Alexandr, Laszlo – good stuff.

Sentrigo was given credit for both discovering vulnerabilities and for security in depth. Way to go, Red Team!
Of course, Sentrigo customers are already protected against many of the vulnerabilities using our own vPatches and we will release updated vPatches to cover the others.

In this case, my advice is not even to wait a week to make sure that there are no issues with the patch since the vulnerabilities are so severe. Patch as soon as possible – but only after ensuring that your applications are not breaking.

If you can’t patch quickly or unable to patch at all due to valid reasons , try virtual patching as a stop-gap solution.

Wow, that’s a big one! Not so much as in the number of security bugs fixed but from the severity point of view.

Oracle fixed 30 vulnerabilities which is a bit less than the previous CPUs. Most of the problems are in the core database product and centered around the network components. The advanced queueing usual suspect also makes an appearance.

The interesting part is the 3 remotely exploitable vulnerabilities without authentication in the Network Authentication, Listener and Secure Enterprise Search (note the irony) components.

As in prevous CPUs, but even more so due to the severity of some of the issues, my advice is to wait for a few days to see if there are problems in the patch itself, test your application and patch as soon as possible.

I’d love to hear from DBAs out there, how soon are you deploying this CPU?

It’s that time of the quarter again. Oracle just released another CPU, this time with 15 DB vulnerabilities compared with the 11 in the July CPU and 15 in April. There are also some interesting vulnerabilities for Oracle EBS and application server. Sentrigo is represented by Guy Pilosof and myself in the credits section.

The vulnerabilities contain the usual mix of SQL injections, buffer overflows and network attacks but I’m missing some of the usual suspects (vulnerable components) like AQ (advanced queuing) while seeing some old friends like CDC and LT. It’s interesting to note that again, one of the DB vulnerabilties is remotely exploitable without authentication. Of course, you should patch as soon as possible, but as we all know there are many factors that prevent you from doing so as frequently as you’d like.

I can bet on a good Sushi dinner that right now, security researchers and hackers around the world are busy reversing the CPU and understanding exactly what the vulnerabilities are. Expect POC scripts to pop up on various websites in the next few days. We at Sentrigo are already familiar with some of the vulnerabilities and have protections for them, while additional ones will be added over the next few days.

The usual advice applies:

  • Patch as soon as possible
  • Install only what you use, don’t install features you are not going to use and remove them if installed by default – many vulnerabilities are in rarely used components like Oracle Spatial, etc.
  • Use the least privilege principle – give the minimum permissions required for the task – every permission can be used to attack the database (create view, create procedure, etc.). Many packages can be used for an attack. Lock them down.
  • Check for default and weak passwords – there are many tools out there. Check after every patch as there were cases it restored default accounts.
  • Secure the network – use firewalls, valid node checking, etc.
  • Use secure coding – bind variables, bind variables, bind variables.
  • If you can’t patch quickly and your databases remain vulnerable, try virtual patching as a stop-gap solution.

So, when are you going to patch?

In a recent survey we conducted, it turned out the DBAs are mostly ignoring security patches. Two thirds of the DBAs have never applied a CPU and only about 10% of them are applying CPUs in a timely fashion. After releasing the survey, we had some interesting responses in online publications and blogs which I would like to address in this post.

Response number 1 – Lies, damned lies, and statistics
The survey is made up, we asked the wrong questions, we did not understand the answers and my favorite – the survey contacted only lazy DBAs between at home between 1PM and 3PM.
Well, let me set the record straight here – the rolling survey was conducted in face to face OUG meetings – 14 different ones across the US, anywhere from 10 people in a room to 45 people. We did not select who was invited or who attended. These were OUG members who chose to attend our sessions. If anything, I would say these were people rather more interested in database security than the average.
We asked two questions –
1) Have you installed the latest Oracle CPU? (actually, since some meetings where right after the CPU we’ve asked about the latest 2 CPUs).
2) Have you ever installed an Oracle CPU?
You can find the actual answers in the survey itself. I should add that the results were quite similar across the different OUG meetings.
I can relate to this disbelief in the results. It sounds amazing that the most important assets of the organization are left un-patched especially after so many publicized incidents. But those in the know already knew this.

Response number 2 – DBAs are just lazy
Well, as a former DBA for many years I definitely do not insinuate that DBAs are lazy. The simple fact is that they just have too much working against them when trying to apply the CPUs:
1. The need to test all applications using the database is a heavy burden
2. Oracle supports only the latest patchsets
3. The lack of application vendor certification of the CPUs
4. The simple fact that it takes a huge amount of work to manually shutdown the database and apply the patch in an organization running hundreds if not thousands of instances
5. For production critical databases you have to consider maintenance windows which might come once a year
6. The lack of understanding by some IT security personnel of the severity of the problem simply does not generate enough pressure in the organization – please see Rich Mogull’s excellent post on this topic.
All in all, I know of companies that analyze and deploy CPUs as soon as three months after release but those companies are very few and usually have budgets in the millions for such things…

Response number 3 – Yeah, we all knew that is the case
I know, I knew it as well being a DBA and all. But I always thought that DBAs at least deploy the patches after testing them. We are talking about severe vulnerabilities. Some of them are remotely exploitable without credentials.

A final remark – as always in security – use common sense:
1) Install only what you use, don’t install features you are not going to use and remove them if installed by default – many vulnerabilities are in rarely used components like Oracle Spatial, etc.
2) Use the least privilege principle – give the minimum permissions required for the task – every permission can be used to attack the database (create view, create procedure, etc.). Many packages can be used for an attack. Lock them down.
3) Check for default and weak passwords – there are many tools out there. Check after every patch as there were cases it restored default accounts.
4) Secure the network – use firewalls, valid node checking, etc.
5) Use secure coding – bind variables, bind variables, bind variables.

There are many white papers out there talking about Oracle security…