What's big and red and needs 270 security patches?

Oracle has revealed its quarterly Critical Patch Update Advisory for January 2017, which offers users a buffet of 270 fixes to apply. Big Red says that “due to the threat posed by a successful attack, Oracle strongly recommends that customers apply CPU fixes as soon as possible.” Where to start? Perhaps with the sole problem …

[STZ]

Open source based vulnerabilities

"Plenty of the bugs aren't Oracle's fault: like most sensible software houses Big Red uses open source code and flaws in those projects account for plenty of the 270 recommended patches."

If the above is true, one must ask whether using open source code is - or ever was - sensible ...

Once upon a time there was the widespread belief that open source code is intrinsically secure - because gazillions of highly motivated highly skilled hobby coders would surely wipe out any security flaw within microseconds ...

[Spudley]

Re: Open source based vulnerabilities

If the above is true, one must ask whether using open source code is - or ever was - sensible ...

No, that isn't the right question here.

All complex software has bugs -- security related and otherwise -- and as software gets more complex, so do those bugs. There's nothing intrinsically better about open source in that respect, but also nothing worse about it either; it's just the way things are.

The real issue here is not about whether there are bugs, but about how quickly they get patched. Oracle is dumping 270 patches onto its users at once. But we can be fairly sure that there hasn't been a sudden mass outbreak of security issues; what's happened is that they've collated all these patches over a period of time so that they could release them as a single update. The problem with doing that is that it means that some of those issues have been waiting for their patch for potentially quite a bit of time. Most major open source projects are pretty good at releasing patches promptly. It would be interesting to know how long Oracle sat on some of those patches before releasing them upstream to their users. If the delay was significant then it is a problem because the security issues would have been known about since the original downstream patch was released so a delay by Oracle in pushing it upstream has potentially left their customers exposed.

[STZ]

Re: Open source based vulnerabilities

@Spudley: You are of course right, Oracle's way of sitting on a big pile of patches for a pretty long time has disadvantages, as it leaves known holes open for exploitation longer than necessary. On the other hand this approach minimizes the operational impact of security patching, which helps the bottom line.

You are also right in that there is no software without flaws.

The big difference between proprietary software and open source is that with the latter, every hacker can look at it and craft his attacks accordingly. As you did point out, this becomes particularly dangerous when a vulnerability fix for open source code gets published, but major ISV's using that open source code are slow in adopting that fix - a clear invitation for hackers to exploit that vulnerability ...

Proprietary code may contain a comparable or even higher number of vulnerabilities, but at least those are not obvious and do not invite for exploitation. Many IT security folks will now start to scream and shout about "security by obscurity" which appears as about the worst insult one can make in this field (a term originally coined by cryptographers for helping with their job security). But in practice, that proprietary approach does work reasonably well ... (;-))

[Pascal Monett]

Re: "in practice, that proprietary approach does work reasonably well"

Spot on. Always has worked fine for Windows, hasn't it ?

Oh, wait . . .

[STZ]

Re: Windows vulnerabilities ...

@Pascal Monett: Thanks for reminding us on the obvious, Windows is of course a very scary example for poor IT security. It was originally devised for a single-seat offline computer system ,,,

Windows is heavily competing with Linux for leadership in number of registeres vulnerabilities in the NIST NVD database. As of today, Windows has now regained leadership with 5115 vulnerabilities vs. close follow-up Linux with 5051 vulnerabilities. Sorry, I'm not participating in those Windows vs. Linux wars, and when mentioning "proprietary" I was certainly not thinking Windows - which is indeed proprietary, but also more widely used and with much more Windows skills (or semi-skills) lurking around. Not the best choice for running critical systems ...

[Anonymous Coward]

Re: Open source based vulnerabilities

Quite often Oracle, like others, release individual patches to the public and if you ask Support you can even have backported and "private" patches if you're really in trouble. Several times a year the PSU bundles come out. Yes you might wait for a few months but if you're not internet facing your DBs ( which you shouldn't be doing directly anyway! ) then most companies can take the risk and wait a couple of months for the patch bundles. We wait for the quarterly Oracle bundles and patch all our systems at once. Once in a while we have to apply a single patch on a prod system if we have no choice but we like to avoid it as you often have to remove all the single patches just before applying the bundles else you can get conflicts.

[Anonymous Coward]

Re: Open source based vulnerabilities

What actually happen is that you call Oracle Support about a well-known vulnerability on a commonly used piece of FOSS, and ask then when they'll have a patch.

Then, they answer that they cannot confirm nor deny the existence of that particular vulnerability.

The quarterly update is problematic, since PCI-DSS compliance compels to fix important vulnerabilities at most one month after a fix is released by the vendor. Oracle splits hairs there, arguing that *they* are the vendor, not upstream, so basically, the clock starts ticking only after the CPU is released.

That's very good for people only interested in security theater, but in practice, it means you can have *months* of exposure to a known (and exploited!) vulnerability, during Oracle will not even acknowledge it exists, let alone help you avoid it.

In some of the worst cases, the RHEL updated RPM was available a couple of days after upstream published a fix, while Solaris got the very same weeks, or months later.

And that's only about the FOSS bits they use. For their proprietary code, they say nothing about what vulnerabilities are. So you know they exist, you know they've got high scores, but have no idea if they are exploitable/were exploited in your environment.

All that is not fun to explain to auditors, and soon it just becomes easier to dump Solaris.

[Stevie]

Re: Open source based vulnerabilities

But Spudley, in the 90s some of us had to sit through a seemingly endless stream of what were I'm sure well meant lectures about how in the New World of Computing the Young Clever Things would make bugs a thing of the past because of the essential granularity of task resolution inherent in the Object Oriented Design Paradigm.

Apparently, and I'm not sure why we old timers didn't think of this decades before, breaking down a complex task into bite-sized chunks was the way to speed up software build, enable simple and comprehensive regression testing and thereby prevent persistent bugs happening.

It's just that some of us are a bit puzzled as to why, now that these Clever Young Things have attained adulthood and a couple of decades in the biz, we are still seeing the Same Old Problems in their products, when the Song of the Nineties would surely have led to a Utopia of Software Competence ere now led by programmers software architects dressed like Raymond Massey in The Shape Of Things To Come.

I'm also puzzled that so many CYTs are reinventing the wheel class when we were also told that OOP would make that a Thing Of The Past.

Actually, I always knew that one was daft because the CLTs were so busy being CLTs they never stopped to wonder about what happens when a code component library gets so large that searching through it is slower than re-inventing the wheel and impossible to do at all without some sort of metadata library to describe it all (we used to call these "documentation" before the CLT revolution). When I saw the MFC diagram that was too big for any of our walls back in the late 90s I roared with laughter; talk about abandon hope all ye who don't have Visual Studio.

The exception was Meyer of course, who built searchable code libraries into Eiffel's design, possibly because he had done a bit of old school computer programming in the real world and "got it".

[Anonymous Coward]

So it's not about Trump?

https://www.nytimes.com/2017/01/18/us/politics/trump-team-has-barely-engaged-with-national-security-council.html