Security Researcher Says Oracle Slow to Fix Flaw
Billosaur writes "A report by Robert Lemos of SecurityFocus in The Register states that Oracle is being criticized by David Litchfield of Next-Generation Security Software for failing to rapidly patch a known flaw in its database software. Litchfield had made Oracle aware of the flaw last October and is now taking them to task for their slow response to the exploit. Oracle, in turn, has attacked Litchfield: 'We are always disappointed when researchers feel the need to publish details of vulnerabilities before a fix is available... What David Litchfield has done is put our customers at risk.'"
What if they CANT fix the problem immediately.
I am a programmer and when I find bugs in my code "pre-release" I find it benefitial. However, some of the bugs I have to spend a substantial amount of time debugging to finally find a fix.
With the code as large as Oracle's code is.. it could take an extremely long time.
This is unfortunate.
Windows? I haven't used that since 1999. Fix the Slashdot Problems
Oracle sold crap software, did not fix it when told about a problem.
So tell me again, Oracle, WHO put their customers at risk?
Acts of massive stupidity are almost never covered by warranty. --me.
What David Litchfield has done is put our customers at risk
Isn't Oracle the one who has put their customers at risk?
Litchfield is putting Oracle's customers at risk? I don't think so. Oracle put their customers at risk, Litchfield merely told those customers they were at risk and in what way. He gave Oracle 3 months to either fix the problem or inform their customers, Oracle did neither, I'd say the problem's all of Oracle's making. If they'd placed their customer's security over their own PR in a reasonable timeframe, Litchfield wouldn't have had to embarrass them this way.
Another example of why "reasonable disclosure" doesn't work well.
He gave them more than 3 months to fix it. They didnt. He releases the information so that admins can take steps to protect themselves... ...and they call HIM the dick? Right...
Beep beep.
If a vulnerable product cannot be patched in a reasonable timeframe ..
RECALL THE PRODUCT!
That's what car makers do.
And yes, software is critical.
While the posing doesn't explain the vulnerability in detail, you can see from the fix that it's inadequate input validation, which is easy to add. There's an access control mechanism that's supposed to prevent access to certain features from the web interface, and it's not doing its job.
While sometimes there are fundamental design problems, this doesn't look like such a case.
(And in such a case, you should explain to the problem reporter why this is an exceptionally difficult bug and ask for an exceptionally long time before disclosure.)
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
What a lame analogy. Trying to compare those two is practially meaningless, unless of course you have a particular extremist political agenda and are looking for any reason at all to try to convince yourself that you must be right.
/. thread is all about.
Since you brought it up though, lets analyze the analogy. And only in terms of "security", which is what this
Intercepting communications from foreign people believed to be terrorists or connected to them:
* This activity's purpose is to prevent future "security breaches" (e.g., learning of a terrorist plot).
* Without this activity, citizens are certainly less safe (meaning this activity has a positive security benifit)
* The activity itself is not unsafe nor pose a "security hole" (regardless of your opinions on other non-security effects like liberty)
* It's effectiveness is in large part subject to it remaining covert
* Publically reveiling the activity makes it non-covert, and therefore reduces its effectiveness.
* Result: the "risk" to our safety was increased (again ignoring any other effects for this analogy). There is no obvious way to "undo" this increase in risk (e.g., no forthcoming "patch" which will make it covert once again)
* If the public exposure had not happened: risk would have remained unchanged (which already was lower than if this activity was not even occuring)
Exposing Oracle bug publically:
* The "activity" in this case was a security flaw in deployed software.
* Thus the "activity" was unsafe.
* The risk it poses is was dependent upon it remaining undiscovered and without an implemented exploit, or until fixed.
* Publically reveiling it makes it undiscovered.
* Result: the risk is temporarily increased--its a race to whether an exploit or a patch is developed first. The risk will actually be decreased when a patch is available and installed.
* If bug was not publically reveiled: flaw remains in software (proven for at least 3 months); probability of being discovered by "black hats" increases with time, thereby gradually increasing risk.
Oh, and one other big difference: in the former there were other ways to attempt change without full public disclosure (congressional oversight, etc.) that were not used. In the later other non-public methods of affecting change were attempted first.
So yes, both acts of publicity result in at least temporary increased risk. But the analogy is otherwise completely broken.
Sorry, but please save your political arguments to a political topic.