Oracle SHELLSHOCKER - data titan lists unpatchables Oracle has confirmed that at least 32 of its products are affected by the vulnerability recently discovered in the Bash command-line interpreter – aka the "Shellshock" bug – including some of the company's pricey integrated hardware systems. The database giant issued a security alert regarding the issue on Friday, warning that …
"Free Software Foundation executive director John Sullivan attributed the speedy resolution of the Shellshock issue to the fact that Bash is free software, adding that proprietary software often ships with hidden bugs that customers cannot fix by themselves."
Why yes, indeed! Because Bash is free software, I was able to immediately fix all the embedded devices I have that incorporate it.
Firstly - do you actually have an embedded device with bash installed? Bash is big, and if embedded devices have a shell at all it is usually one of the mini ones like lash which is not vulnerable to this flaw.
Secondly, pretend a flaw is found in lash tomorrow, and you have a device for which you cannot download the source code, apply a patch, cross compile and install new firmware. <shouting>Why did you buy it?</shouting>. There are plenty of hackable devices out there. If you want a router, pick one that is easy to install openwrt on. The reason locked down devices exist at all is because people buy them. Stop it at once, or you have to pay whatever the vendor demands for updates.
No vote up or down, but a general observation on the El Reg scene. Sarcasm and irony don't appear to translate well. (I'm making an assumption, here, which as we all know . . . )
Assuming AC was being sarcastic, I suspect that the response is associated with whatever gene predisposes IT specialists, when confronted by some monumental SNAFU in a program's operation, to respond, "Yes, it does that."
You were right to latch onto Mr. Sullivan's quote, but I think you missed the real issues. This problem wasn't quick to fix because bash is free, it was quick to fix because once shown the issue the bash maintainers could address it rapidly. That any one may contribute compounds the issue of quality control. Fortunately, as a practical matter, it's generally project code base experts who would bother.
However, that only fixes the source code. Because the software is free and as is, the users are on their own as to whether a fix of one things breaks another in their confederation of packages.
Proprietary code vendors do not do the work of angels, but the biggest ones such as Apple, Oracle, Microsoft, etc., generally think about the effects of the fix on the paying customer, and if there's a show-stopper problem, holds off until the patch does no harm to the software they sell. This takes time, both in the testing and the revising. Apple and Microsoft recently put out patches that had to be withdrawn. Incompetence? Maybe. Shipping more quickly than they should? Definitely.
Quick is not the virtue, correct is. Mr. Sullivan should also remember that we users aren't grading on a curve. Many will be scrambling or vulnerable until the bash patches are installed and regressions addressed and to them it doesn't matter that Microsoft will release patches in 10 days that it could have released last week, as bash is the thing that disrupted the schedule this week and possibly month. That the problem could have been fixed quickly raises the question why was it not fixed years sooner. And if the response is that the bash reliant aren't giving money to the project, would that be an eye-roller? I ask because right and maintained are why people give money to proprietary code vendors. To Mr. Sullivan I'd recommend coming down from the high horse because everyone has the same problems. Code is buggy and frequently one person's fix is another person's break. It takes time and money to reduce get things right. A code license is not a silver bullet.
"Quick is not the virtue, correct is."
But in a world where everyone wants everything yesterday, where by the time you find out about the bug, it's too late and you've already been pwned, you can't just do it fast, and you can't just do it right. You must be able to do it rightfast or you're toast.
"attributed the speedy resolution of the Shellshock issue to the fact that Bash is free software"
But it isn't fully fixed yet. And the partial patches that we have have been rushed out of the door without proper regression and integration testing.
"the fact that Bash is free software, adding that proprietary software often ships with hidden bugs that customers cannot fix by themselves."
So how come Microsoft - for instance - consistently have a faster average fix time / fewer days at risk that all of the major enterprise Linux distributions?
But where on earth would Oracle get such a complex program, this "data-base" of which you speak, from?
And surely it would require an unprecedented level of foresight to allow a company to contact its paying customers over such a newly discovered class of issue (I mean, bugs only gained their name in t the forties).
No, Mr (or Ms) Coward, I feel you are holding this poor, blameless company to altogether a too high standard.
Ridiculous kneejerk response. Like Microsoft, Apple IBM and any other huge software vendor, they have millions of customers, its wholly impractical at that scale to contact each and every customer, the back end support systems will anyway have details of for example, the person in procurement who made the order years back, rather than an actual person responsible for bug fixes.
They also all have have systems that you can connect to which will tell you what needs an update for the actual software you have installed rather than what you bought (not the same thing at all) which any responsible IT organisation will be using and monitoring, rather than waiting passively for Oracle / IBM / SAP etc etc to send an email to "fred@procurement dot com" who probably also buys software for every other vendor as well.
Are you kidding? Anyone that's an Oracle customer has paid hefty coin for the priveledge. That means that Oracle will certainly be able to contact all of them. If this were an issue of sending some sales centric spam, the question of "technologically feasible" would never even come up.
For Oracle in particular, everyone in the trenches that can open a support ticket will have their own registered account with Oracle tied to their corporate email account.
Are these 32 products with bash installed, or 32 products that I can remotely convince to run bash with my choice of data in an environment variable?
At a brief glance, at least some of these products allow a competent sysadmin to download the source code for bash, apply a patch, compile and install a fixed version - all without any help from Oracle. Is this true of all 32?
Even if they can, my guess is they won't. Given what enterprises pay for Oracle and the likelihood that manually fixing a small part of something yourself will invalidate the support agreement I suspect competent sysadmins leave these things alone and let whoever bought Oracle take the flak if problems come up.
Well, the flak won't ever come to the persons who bought Oracle - they're much too high up in the chain for that. The competent sysadmins meanwhile will mitigate the issue via other means and wait for the vendor supplied fixes to arrive..
Yes to the majority of the affected products, and some of the exploits make it nearly impossible to know if the systems have been 'root kitted' without a full binary audit from a trusted source, or leaked information somewhere.
And whats worse, is the outages that will be impacted to business, services over the next few weeks / months / years to remediate the affected products with a new version of BASH.
Just to note the impact of ShellShock, From the Oracle security bulletin :
Solaris 8,9,10; BASH is not the root shell but is available to users,applications, etc for use. Any service running under BASH or cgi script may be exploitable. As a minimum, a service / application, etc restart would be required after the patches are applied / tested.
Solaris 11; BASH is the root shell and is also available to users, applications, etc for use. Any service running under BASH or cgi script may be exploitable. As a minimum, a system reboot would be required after the patches are applied / tested.
Oracle LINUX; same restrictions as RedHat, reboot, etc.
ILOMS & XSCF; Firmware upgrade, and hope not to loose the configs. Both have web interfaces.
Oracle VM 2.2, 3.2, 3.3; reboot of all your LDOMS after patches are applied / tested.
The CISCO rebadged fibre channel switches may need a reboot, outage affecting all connected fibre's / systems / etc.
Im surprised that they havn't listed Oracle Enterprise Manager as yet considering its 'heavy' web interface along with it's use of shell / java scripts.
"I can see that after openssl and now bash, lots of open source tools whose code has not been looked at for decades because they have, up to now, just worked, will come under intense scrutiny."
That's no bad thing IMO, but this process isn't a new event in the Open Source world either.
It took three days for a definitive - we hope.- patch, since the disclosure. While the vulnerable code has been there for a very long time, and nobody ever spotted it, despite source code availability.
And unlike in 1970, most user can't fix bugs themselves for the simple reason they are not programmers, and they do expect the supplier fix them, open source or not.
But we see the FSF is asking money for support... not more 'community' source code reviews...
- Build a system using other people's work or more likely outdated versions of other people's work
- Take customers' money
- Take an inordinate amount of time to push out security updates but only to customers who've paid more for support
That's adding value right there.
Non free *nix ditros - what do they do?
- Build a system using other people's work or more likely outdated versions of other people's work. Or sometimes cutting edge that don't really work all that well or have been extensively tested.
- Take customers' money
- Take whatever time it takes and push updates as you feel like. Answer phone if the sucker, i mean customer, actually has a support contract.
That's adding value right there too.
That said, Slack fan and will die one, but i see no difference between Proprietary and Enterprise *nix. Same poopoo different smell. And source availability is only meaningful if you have the in house expertise to fix/apply it yourself, whether the FOSS people like to admit it or not.
In a large corporation, the likelihood of that is going to be very high actually.
I worked in one Fortune 500 company where they plain had the source for their key enterprise application. They had been maintaining it themselves because it was impossible to replace and would have been desupported by the vendor decades ago.
A megacorp being able to handle the source to bash is not such a strange idea.
I looked this morning, there is another patch out in the bash directory released late last night (for GMT users) - e.g. for 4.3 patch 027 is out:
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
