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?