Slashdot Mirror


Oracle's Chief Security Officer Speaks Out

s0u1d13r writes "ZDNet Australia posted a special article from Oracle's CSO regarding the treatment and publishing of exploits and vulnerabilities by security researchers. From the article: 'There's a myth about security researchers that goes like this: Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all -- if it weren't for noble security researchers using the threat of public disclosure to force them to act.' An interesting read from the perspective of one of the largest software vendors accused of ignoring vulnerabilities by software researchers."

9 of 112 comments (clear)

  1. Rubbish as usual by tyroneking · · Score: 4, Interesting

    Nothing but a very short, low-on-detail slagging off of independent secuiryt researchers with totally nothing about how she does her job and what her department does. She does touch on some good points, such as clients not wanting to implement fixes during critical reporting periods, but fails to mention that systems that are used for such reporting are usually never exposed to the evil internet.
    Don't read the 'article' - don't post stories like this onb /. again please.

    1. Re:Rubbish as usual by Donny+Smith · · Score: 4, Insightful

      The article criticizes security researchers, which is aparently easier than spending energy on introspect.

      And all that from a company that marketed its product as "Unbreakable" despite dozens of security problems every year.

      Scum.

  2. But that's true, at least for extensive vulns by melted · · Score: 5, Interesting

    But that's true, at least for extensive vulnerabilities that can require a lot of effort to fix and/or test!

    Let's see, you're a development manager and you have a crazy schedule forced on you from above by some idiotic VP. Now this guy from product support comes along and tells you about this horrible flaw that will require you to shut down all development for two weeks, slip the schedule and have your best people fix it. Then you shut down testing for a month and have your best testers test it. Then there's a pain of pushing out a patch and notifying the customers and bad PR associated with that.

    I can easily see how some of the less obvious vulnerabilities would be simply brushed off using "no one is ever going to find out" line of reasoning. Now if you know that someone has already found out and he will make it public in about a month, sure as heck you're going to issue a patch, even if this means slipping the schedule by a month (or in case of Windows by two years). Because if you don't, script kiddies will rape your customer and he will never give you another dollar.

    1. Re:But that's true, at least for extensive vulns by gclef · · Score: 5, Informative

      The problem is, a few of the recently-released ones had lag times measured in *years*. Oracle can whine all they like about unrealistic deadlines from researchers, but a few years is far too long to sit on something.

      My reference for the years comment:
      http://www.red-database-security.com/advisory/publ ished_alerts.html

      They waited over 600 days for Oracle to patch some vulns. There's no excuse for that.

  3. Deparment of Homepage Security by Doc+Ruby · · Score: 4, Insightful

    Sure, why waste time fixing bugs, when you can attack the researchers whose bug reports make you look bad? People are going to buy Oracle no matter what, so these bugs matter only by requiring the Marketing Department to talk tech, rather than spin the wonders of Oracle that make the Web a safe, peaceful utopia. If Oracle is going to deliver every American our government serial number, its Security chief has to play from the same denial playbook as the Department of Homeland Security to which they'll be charging those fat support contracts.

    --

    --
    make install -not war

    1. Re:Deparment of Homepage Security by fimbulvetr · · Score: 5, Interesting

      This is bullshit.

      Oracle does _not_ take vulnerabilites seriously. I agree that the oracle database is extremely complex, and the implications of bugs is enormous, but it's not inherently complex. Because of this, claiming that they don't release patches because it's complex is bullshit. Oracle does not need to be as complex as it is.

      First, the complexity:
      I've been running Oracle just as long as I've been running both Mysql and Postgres (I know what you're saying - oh, he's one of those guys:)), and I know that the features oracle offers can exist without all of the useless bloat oracle tacks on. Mysql can replicate, instantly, to who knows how many databases. Oracle Dataguard is limited to 9. I can restore databases in seconds using postgres, oracle takes all damn day. Mainly because you have to have your ducks in a row with: Arch files, redo files, tnsnames, listener files, spfiles, pfiles, oratab, oracle home, etc. Oracle databases are extemely difficult to get running on a different system. Even exports (exp/imp - what _should be similiar to an sql dump) don't work across OSs. Oracle offers no native sql dump command, instead you have to figure out how to get TORA working. Oracle offers sqlplus, an old, broken command line client that requires unsightly scripting to even start the database.
      Oracles documentation is very similiar to their product: Disconnected. Nothing fits. Everything (kind of) works, but noone knows how to put it together, save the people who killed what must be hundreds of thousands of brain cells by doing it by trial and error. Oracle requires java, and lots of it. Oracle requires an oracle database to monitor other oracle databases. It's wise to put this on a seperate installation/box. Doesn't seem to make a lot of sense. Now I have twice as many exploitable boxes, not to mention more to backup, administer, etc. Oracle requires an insane amount of diskspace compared to other databases.
      I'm not arguing for mysql/postgres vs. oracle - I'm just trying to say that Oracle does NOT need all of the bloat it currently has. The company could stand to do a complete rewrite of it.

      Now, the security:
      Here's a perfect example of what I mean:
      http://www.red-database-security.com/advisory/publ ished_alerts.html

      The first 6 vulnerabilites are 600(!!!) days old!
      Here's a perfect example of their lack of motivation.

      http://packetstormsecurity.nl/0507-advisories/Orac le9R2-unpatched.txt

      Basically, a vulnerability was disclosed months ago, and oracle fixed 10.x in July's update, but completed ignored 9.x. To quote TFA:

      'We contacted Oracle about this issue and Oracle
      confirmed it, when we asked why there is no fix
      for 9iR2, Oracle said:

      "Our development teams neglected to do the backports.
      We are working on creating those backports now."'

      Leaving production systems unpatched until October! (Assuming oracle doesn't 'neglect' to do it again.

      In short, quit reading the marketing bullshit and wake up.

    2. Re:Deparment of Homepage Security by IdleTime · · Score: 4, Informative

      I'm sorry but you are way off the mark here. I'm sorry that you don't know your job, but don't blame Oracle for your own incompetency.

      Using streams replication there is not limit (practically) on the number of servers to replicate to.

      Restore and recover takes a long time? Use archivelog mode, unless you have physical corruption that spans multiple disks, there is no need to restore the whole database. restore the corrupt file and roll forward. Unless your last backup of the file was months ago, the operation is done in minutes. Please don't spread stupid remarks that have no foothold in reality. L:earn to use the product rather than display your own ignorance.

      Oracle Dataguard has nothing to do with replication. Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.

      Starting a database is simple: sqlplus "/ as sysdba"; startup... How difficult is that?

      I don't mind critique of Oracle, but at least get your facts straight!

      --
      If you mod me down, I *will* introduce you to my sister!
  4. "security researchers" is a broad rubric by DingerX · · Score: 4, Insightful

    In TFA she discusses two sorts: those who play ball, and those who don't. One of the continuing problems with IT security is the fact that the bright folks who can find or fix problems aren't always the ones who understand how really big, clunky corporations work.

    The only goal in the article there is to do discourage people from doing the whole "I found a vulnerability, you have 5 days to comply" nonsense. Yeah, sure, it works great if you've got a 1-person operation with no legal team, and no multitiered support system in place to filter out the garbage.

    1. Re:"security researchers" is a broad rubric by dbarclay10 · · Score: 4, Insightful
      In TFA she discusses two sorts: those who play ball, and those who don't. One of the continuing problems with IT security is the fact that the bright folks who can find or fix problems aren't always the ones who understand how really big, clunky corporations work.
      The only goal in the article there is to do discourage people from doing the whole "I found a vulnerability, you have 5 days to comply" nonsense. Yeah, sure, it works great if you've got a 1-person operation with no legal team, and no multitiered support system in place to filter out the garbage.

      You miss the entire point. You could be referring to one of two "really big, clunky corporations." Either the "really big, clunky corporation" that needs to upgrade all their vulnerable equipment, or the "reall big, clunky corporation" which actually has to provide the fix. Let's do the last one first:

      • My job is to provide services in a secure, cost-effective, and effecient manner
      • It's my responsibility to choose the components I will use to do my job
      • That means that (unlike the recent Oracle vulnerabilities), I require that fixes for reported vulnerabilities be provided in a reasonable time-frame, fully-tested and audited
      • A "reasonable timeframe" is measured in hours, days, or - very occasionally - weeks. Not months or years (such as the recent Oracle fixes)
      • You may say "that will increase the cost of the products" - no it won't. The relatively minor increase in ticket and support contract price is dwarfed by the price of a security breach
      • Whether the vendor is a "big, clunky corporation" or not is irrelevant - all that matters is if they can meet the requirements set out by their customers (of which I am but one, and trust me, more and more customers are demanding reasonable security-fix practices - of which "sit on it for a year or more" isn't one)
      Or, if you're talking about the "really big, clunky corporation" which can't manage to perform critical upgrades at a time appropriate for the business:
      • That's their choice and their problem. That some yahoo idiot corporation can't expend the resources to secure their infrastructure isn't my responsibility.
      • Note that near reporting periods, I don't touch critical infrastructure either. My choice. I implement what workarounds are safe to put in place, and I make a calculated risk. By refusing to act on security-related reports in a timely manner, Oracle took that choice away from me.

      To sum up: Oracle waited YEARS to fix some of these bugs. I don't care why they were unable to fix them. They got caught with their pants down, after the people who reported them decided that "okay, by now, somebody who'll use these vulnerabilities to actually attack people has probably found them" and subsequently released (limited) details required to inform Oracle's customers of the possibility of vulnerabilities.

      Now they're trying to blame those people, who actually gave me the ability to make reasoned decisions? The gall. A year ago I wasn't in a position to choose which software we used in our infrastructure, and now I am. Oracle's failure to act upon vulnerability reports, and their subsequent attempt to disparage those who allowed me to do my job, has lost them any possibility of future sales while I'm in charge (until, of course, they actually change - and confirming that change will require me to actually audit their own practices, which I doubt they'll ever let me do).

      The saddest part? We're a software development firm which gets to dictate to some really big customers what database engine they use. We're talking about tens of thousands of licenses, easy. Whereas we were previously looking at MySQL, Postgres, and Oracle. Now Oracle is just totally ruled out.

      --

      Barclay family motto:
      Aut agere aut mori.
      (Either action or death.)