Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Security Businesses Databases Oracle Programming Software IT

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.
This discussion has been archived. No new comments can be posted.

Emergency Workaround For Oracle 0-Day

Comments Filter:
  • by stimpleton ( 732392 ) on Tuesday July 29, 2008 @11:11PM (#24396239)

    "Oracle: can't break it; can't break in"
  • by achurch ( 201270 ) on Tuesday July 29, 2008 @11:51PM (#24396575) Homepage

    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.

  • by Anonymous Coward on Wednesday July 30, 2008 @12:24AM (#24396859)

    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 [],
    as the internal URL limit enforced by Apache.

  • by Fallen Kell ( 165468 ) on Wednesday July 30, 2008 @12:33AM (#24396925)
    Again, this brings up the whole debate on to disclose or not to disclose.

    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.

  • by erroneus ( 253617 ) on Wednesday July 30, 2008 @01:03AM (#24397129) Homepage

    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)

    by BoRegardless ( 721219 ) on Wednesday July 30, 2008 @01:28AM (#24397285)

    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.

  • by lee1026 ( 876806 ) on Wednesday July 30, 2008 @01:55AM (#24397503)

    Not always. Suppose if I do something like this:
    void *ptr = malloc(1000);

    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)

    by Markspark ( 969445 ) on Wednesday July 30, 2008 @04:10AM (#24398231)
    Apparently not TOO much, since Ericsson and Sony Ericsson both do code audits, with senior programmers questioning every single line of code. (Yes, i have friends who work there)
  • Re:Unbreakable (Score:3, Interesting)

    by MadKeithV ( 102058 ) on Wednesday July 30, 2008 @04:25AM (#24398319)
    Great! I'm applying for a job there, since it seems management has half a clue at least!
  • by nimbius ( 983462 ) on Wednesday July 30, 2008 @07:46AM (#24399387) Homepage
    I remember coming in every other morning in the office to restart our oracle concurrent manager servers because they had mysteriously gone haywire somewhere between their backend and apache interface.

    I remember teams of expensive consultants, weeks without sleep and 24/hr oncall in order to restart crashed IStore servers

    this was when i worked for a certain popular bed company. i also remember our oracle DBA's primary solution being to "reboot all the oracle servers" when something was wrong. his "learn oracle from oracle" book clenched firmly in hand. I remember the database running as a privileged user with full passwordless sudo, as per our oracle reps insistence. i remember files stored at access 777 and no one caring. more power to the 0-day exploits. people need to know this software isnt indestructible just because marketing says it is.
  • by hanshotfirst ( 851936 ) on Wednesday July 30, 2008 @08:39AM (#24399811)
    Your DBA's didn't know what they were doing. Was this an Oracle sales rep or a technical consultant? They were clueless too - there is NO reason to run the Oracle database in that way. I can't speak to the Istore or concurrent manager stuff, but if their lack of knowledge on the core database product was this bad, I can only imagine...
  • by Abcd1234 ( 188840 ) on Wednesday July 30, 2008 @10:03AM (#24401003) Homepage

    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.

"What the scientists have in their briefcases is terrifying." -- Nikita Khrushchev