Slashdot Mirror
Oracle Exec Strikes Out At 'Patch' Mentality
An anonymous reader writes "C|Net has an article up discussing comments by Oracle's Chief Security Officer railing against the culture of patching that exists in the software industry." From the article: "Things are so bad in the software business that it has become 'a national security issue,' with regulation of the industry currently on the agenda, she said. 'I did an informal poll recently of chief security officers on the CSO Council, and a lot of them said they really thought the industry should be regulated,' she said, referring to the security think tank."
this explains all....bunch of slackasses!
We played dungeons and dragons for 3 hours.....then i was slain by an elf
No.
Not at all in fact.
Open Source has nothing to do with this and I would suggest that you actually do some research instead of parroting the usual "Open Source will fix all problems" mantra.
Oracle has recently been shown to have up to 5 years turnaround to patch glaring security holes. This has reached the point where security researchers like Litchfield who have had an ongoing relationshop with Oracle for 10+ years do not want to work with any longer. Note, we are not talking sc1pt k1dd10tz sitting in their dad's basement here. The people in question consult banks, governments, large corps and cannot actually recommend them a working security policy because Oracle cannot get its head out of its arse and patch a security problem for multiple years after it has been reported to them.
As a result people who used to work on Oracle problems and reported them in private to Oracle have started posting them openly "0 day" style or giving Oracle a 1 month fixed notice of an impending posting regardless of does it have a patch or not.
Obviously Oracle is pissed.
First of all it breaks all of their marketing bollocks about unbreakability and security to bits.
Second it is threatening their sales to customers in regulated markets where security issues must be addresses within a fixed term after being known.
This is the reason for them to rattle the "regulation" sabers and moan about a "patch culture". Open Source has nothing to do about it.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
and get modded insightful for it.
Really, your whole post is so silly, it defies believe.
First off, she did not in any way shape or form suggest that her poll, as she perhaps wrongly liked to call it, does in any way meet the requirements for a statistically correct poll.
Further, her argument does not rely in any way on this "poll", no matter how hard you try to spin it.
So what did she do?
She simply presents an argument about the terrible state of security in software engineering and mentions that many in the field agree with her.
To claim that this is lying with statistics is simply absurd and simply shows that it's not enough to merely read books, one should also understand them.
Yes, OpenBSD still has a few security patches each version, but thier methodology is far better than many other software developers.
I write the OWASP Guide, which is used by basically everybody as the standard for web application security, and is the official standard of Visa, many governments, and so on.
She talks to CSO's who mostly are bean counters. They see money down the drain from patching. I agree with them - patching is inefficient and wasteful. But it's necessary as Oracle builds crap, buggy and insecure software. They are easily five+ years behind Microsoft in churning out safer software. Buffer overflows, high privilege accounts, public access to highly privileged library functions - all this stuff is easily 10-15 years old and should not be in Oracle 10g, but it is.
Oracle has time and time again outright refused to get on board with a secure coding program, often fixing just the little bug which gained root privileges, exposed all your data, or destroyed the database outright. Instead, they should be searching for all those types of bugs and fixing them in one hit. Davidson has more than enough time to address the root cause
She is holding software up to the standards of bridges. Bridges have tolerances and over-design built into them. Most software does not. Often to make artificial deadlines made by beancounters, software is shipped with bugs. Often the bugs are not found for some time and requires researchers to go find them. If it's not researchers, its the commercial 0day crowd. This is where Davidson shows she is an amateur and must be replaced. It's best for HER customers to be secure, and that means shipping secure software. Shipping insecure software does not prevent the 0day houses from creating exploits. Oracle's reputation as a solid data partner is worthless if we lose all our data to an attacker because Oracle suppressed the news from us, rather than fixes the problem.
It is simply unachievable to build bug free software for a reasonable cost. What is required is care, developer training in secure software techniques, and defense in depth. That is our tolerance and over-design. Oracle is sadly lacking. She has had five years to get their developers onto a program of building this into their platforms, and she's failed miserably. I will be interested to hear what standards they use, and if it's mine (OWASP Guide), or if they do their own based upon ours, or use Microsoft's.
I've called for her to step down more than once. When she attacked the good name of David Litchfield and NGS Software, I was outraged - this was like shooting the messenger that their "unbreakable" software was pure crap, which we already knew - but now know through his unstinting efforts that it is truly appalling and not fit for purpose.
If this latest "push" for too little too late does not work out, she should be sacked by the Oracle board for the good of all Oracle shareholders and customers. She's had more than enough time to make a positive change, and should make way for someone who really understands security.
Andrew van der Stock
Take the phone switches for example. These things don't crash, ever. They just work.
Sorry, that's just not true. Phone switches _do_ crash - it's just that the telcos have learnt to build networks with a hell of a lot of redundency. If a phone switch goes down then the worst that'll happen is you'll lose the calls that are in-progress on that switch (actually, the switch may be able to recover the calls if it resets quickly enough - just because the signalling goes down for a few seconds doesn't necessarilly mean the voice circuits have also failed). New calls will be routed via a redundent switch.
Of course, building any kind of highly redundent network is very costly so people avoid doing it if they can help it.
Also, phone systems are only designed to deal with a fairly specific set of events, they don't need to worry about security holes, etc, because everyone on the network is fairly trusted. I'm sure this will change very quickly in the near future with the convergence of the internet and the PSTN.
Probably the closest you'll get to completely reliable are the fly-by-wire systems used in planes, but even then they still put a lot of effort into redundency, with multiple computers arranged in voting systems so faults can be spotted and corrected or completely taken out of service as early as possible. This is probably also the most similar scenario to the bridge analogy - if it goes badly wrong, people die.
http://blog.nexusuk.org
- Do a proper high-level design.
- Review your design with all stakeholders, including QA/testing and marketing.
- Plan time to fix issues in all steps of the project.
- Prototypes are to throw away, don't build your product on top of them.
- Require specifications for all parts of the application.
- Peer review all specifications.
- Peer review all code.
- Perform unit and module tests on all parts of the code.
- Fix bugs as early as possible.
Development will cost more and take longerIt will take more time till a programmer starts coding, you will need less time to find and fix bugs. A clean design leads to cleaner module interfaces, which makes tracing the bug easier. Doing module testing means that a lot of bugs are found early and are automaticly traced to an offending module, which means quick fixing.
Restrictions on hardware and software
For high-reliability, yes. It's hard to write software that can replace blown out fuses. I think it is rediculous that an Internet connected Windows system is "automagicly" degrading to a near useless condition, so Windows should be thrown out.
It should be possible to run a decent selection of software on a server, where the user selects his mixture, taking into account his desired level of reliability. An Operating System should sufficiently isolate processes so that a single bug doesn't crash the machine.
Slower performance.
Needless consistency checks slow things down (and improper checks may even cause instability). With a proper design you know what to check where, so you only check once. In my experience good quality software performs better than bad software.
Take the phone switches for example. These things don't crash, ever. They just work. [...] they've had like one major upgrade (5ESS to 7R/E) in the last couple decades
Sorry, I had to pick myself up from the floor, fell of my chair laughing. I did work for a telco and crashed a few switches myself, the Lucent stuff you mention. Ericson makes more reliable systems (but they have a different design philosophy). And software updates for phone switches appear regularly.
extern warranty;
main()
{
(void)warranty;
}
"Second, there are numerous examples of bridges that have had structural flaws."
And the very concept of road construction is very much a trial and error with thousands of people actually getting _killed_ every year, often because of known problems that should have been fixed to provide a safer infrastructure.
known to break stuff, released in 6 month batches
Oracle's patching regime is an obsolete, adhoc pile of steaming crap. I was employed to maintain and develop software on Oracle databases from version 6 (Novell) through 9i (Solaris, HP/UX, Win32 and Linux.) I have applied many Oracle patches during my time. Things may have changed with Oracle 10+ as I haven't seen much of it, but I doubt it.
First, there is no simple, auditable means of determining which patches have been applied to an installation. Recently OUI has been good about revealing the installed versions of components, but that's not enough. Not by a long shot.
Second, there is no dependency checking. A DBA is pretty much free to annihilate an Oracle system by selectively cherry picking whatever patches are needed to solve a specific problem, damn the dependencies. His fault if he exercises some bug as a result. His fault if he overlooks one.
Third, there is no automated means of querying Oracle to discover missing patches. You're expected to rummage around their support site reading multiple contradictory patch lists and discover patches yourself. This, naturally, is further complicated when multiple platforms are involved.
Forth, patches often don't apply cleanly. I don't know how many times I've had to debug Oracle's patch process, but it happened frequently. Crummy log files and guesswork is what you are expected to use for this.
Fifth, anyone remotely involved with the OUI machinations Oracle has inflicted on its customers must be shot. These people cannot be allowed to persist on my planet. It's just wrong. I've had patches that could not be installed with the OUI used to install the base. You have to upgrade the OUI to patch!
Sixth, JVM hell; 1.1x, 1.2x, 1.3x and 1.4x all in the same HOME to run various scraps. F**cking joke.
Seventh, Metalink is a brilliant example of how NOT to implement a web based support system. Slow, overly elaborate, filled with redundant, often obsolete records, etc. Half the URLs to specific patches are 404. Search is circa 1998 like. Their redesign efforts amount to an annual re-shuffling of the same collection of documentation.
Eight, the patches are often regressions. Apply, find breakage, remove, complain, wait 3 weeks for attempt number n, rinse and repeat. There is no level of testing sufficient to assure an Oracle patch won't crush a production system.
Nine, forget about patching clients. Oracle did. They just obviated with whole client problem with a zero-installer mini-client thing. Hope you don't need the full featured client on a lot of clients...
etc., etc.
As an aside; the only commercial DB vendor with whom I've had experience that does a good job of patch management is IBM. DB/2 patches are at least not regressions (usually). They tend to apply cleanly and fix what they claim to fix.
Take the phone switches for example. These things don't crash, ever. They just work. Great, but they only do one thing, yoy use only certified hardware, they've had like one major upgrade (5ESS to 7R/E) in the last couple decades, and they cost millions.
As other posters have already noted, telephone switches do crash, or much more frequently, have impairments short of a complete outage. Lucent's markteting boasts of five 9s availability, but thats based on aggregate FCC reporting data, not for any one switch.
And the claim that there has been only one major upgrade makes me laugh. Right now there have been about twenty generic releases (major software releases), although some of the recent ones (since about 5E16 or so) are supposed to be split between wireless & wireline. In between generics, there are numerous patch releases. That's just the software. On the hardware side, there have been many hardware changes since the No. 5 ESS came out in the 80's. Some of the changes have been optional, but many have required grafting new hardware onto an existing switch (like CM & AM retrofits.
7/RE was more of a collection of upgrades and marketing, than anything unique in it's own right. Lucent has since gone back to calling it 5ESS, just like they have with 5ESS-2000, and every other marketing name change they've tried. I can't wait to see what Alcatel tries.
There's redundancy and reliability built into most vendor's equipment, but it's far from perfect, especially when you start adding humans in to the mix.
Its a big planet, but a small world.
Any regulation Oracle could come up with would apply *only* in those countries it could get to accept it - so if it were based in the US, it would be binding on Oracle (as a US company) and other US companies, plus any OSS projects based in the states - but Full-Disclosure mailing lists based in Norway or India would still be free to post 0-Day or fixed-delay postings, and those would be readable anywhere in the world.
Insisting on (American Sited) regulation can only shoot Oracle in the foot.
-=DaveHowe=-