Emergency Workaround For Oracle 0-Day 152
Almost Live writes "Oracle has released an out-of-cycle alert to offer mitigation for a zero-day exploit that's been posted on the Internet. The emergency workaround addresses an unpatched remote buffer overflow that's remotely exploitable without the need for a username and password, and can result in compromising the confidentiality, integrity, and availability of the targeted system." Whoever published the vulnerability and matching exploit code did not contact Oracle first.
They have backpeddled (Score:5, Interesting)
"Oracle: can't break it; can't break in"
Let me fix that for you (Score:5, Interesting)
Not that TFA says anything about whether C or C++ are actually involved, but:
The C/C++ feature that the compiler has no idea of the size of an array claims another example of misuse.
The lack of array size information is a feature of C/C++, and a well-known one at that. If you don't know how to deal with it, you shouldn't be using the language, much less talking about it.
Re:Let me fix that for you (Score:1, Interesting)
Maybe the BEA coder declared a fixed-length array of 4000 characters either on the stack or an instance variable, to hold the HTTP Post URL.
Why 4000? Well I noticed that in the exploit code. It's also mentioned here [boutell.com],
as the internal URL limit enforced by Apache.
To disclose or not... (Score:5, Interesting)
I seriously don't think that we would have seen any kind of information from Oracle about trying to mitigate a possible problem if this had simply been sent only to Oracle. As such, we are a little safer in the sense that at least we know of the issue, and as a result can apply the remedies both Oracle provided as well as any other solutions to help protect against this kind of attack.
Had this not gone public, it would almost definitely be another few months before we had a fix in place from Oracle, and in the mean time had been vulnerable to attack that someone has already found (which means it is likely that many people know of the flaw and may be looking to exploit it).
While some cases full disclosure may not be the best idea, this case (or any case for that matter where the exploit can be defeated with certain configuration options) it is better that we know of it immediately so we can put our own protections in place and use our own judgment as to what extra actions may need to take place (possibly including taking affected systems off-line or otherwise unavailable). We are all safer now because of this person releasing the exploit into the wild on the public internet, which forced a company to make a statement about that exploit and give immediate advice to protect against it, as opposed to sitting on that exploit, not telling anyone about it, and quietly have a patch released with the normal patch cycle.
Letting the vendor know first can be risky (Score:5, Interesting)
Though many experts in the area make it policy to inform the vendor, some vendors respond in wildly inappropriate ways. Some simply ignore it, others will contact law enforcement authorities believing that they are being blackmailed. And yes indeed, some security conscious people have been arrested for trying to do "the right thing."
It is rare that security flaws like these are announced in this way. I find it more likely that someone attempted to contact Oracle on the matter and the message didn't get to the right eyes or ears and was discarded. Now they are simply claiming to have no knowledge of being prior informed... or maybe just as likely, they were adequately informed and they simply did nothing about it. Microsoft is well known for doing that. There have been exploitable flaws in their OSes for years that have not been patched. Ultimately, I find it more likely that they were informed and for whatever reason did not act on it.
It's best to report it to the vendor/maintainer first and give them 30 days to fix it, but even then you're probably better off remaining as anonymous as possible or someone may be knocking on your door before you know it.
Re:Unbreakable (Score:3, Interesting)
Come on now. If a bad ass programmer wants either fun or profit he can put in an exploit which can act as a back door. If it isn't caught, he can later decide to use it one way or another.
How about some serious automated debugging routines, known error and bug checks that are documented and a mandatory human based coding review in a systematic way that tells a how well the coding is being done from the start.
Re:Another victim of C/C++ lack of array safety (Score:2, Interesting)
Not always. Suppose if I do something like this:
void *ptr = malloc(1000);
foo(ptr+4);
Now, in foo, the correct answer to the size of array being passed to it is 996. But the language does not know that.
Re:Unbreakable (Score:2, Interesting)
Re:Unbreakable (Score:3, Interesting)
Comment removed (Score:3, Interesting)
Re:fuck unbreakable. it sucks. (Score:4, Interesting)
Re:perhaps if they paid ... (Score:3, Interesting)
Wow, way to completely miss the point. So, let me explain: if I go and build an application using a "safe" language on top of a VM, I'm building on a codebase that's had millions upon millions of hours of real-world testing. Moreover, that VM, being one single piece of code, can easily be audited for security issues, buffer overflows, etc. None of this can be said of an application I build from scratch on top of an "unsafe" language.