Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Emergency Workaround For Oracle 0-Day

Posted by kdawson on Tue Jul 29, 2008 10:04 PM
from the maybe-somebody-shorted-the-stock dept.
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.
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward on Tuesday July 29 2008, @10:06PM (#24396159)

    I sent the email to 0racle. Too much l33tness, sorry.

  • Haha! (Score:5, Informative)

    by Anonymous Coward on Tuesday July 29 2008, @10:07PM (#24396177)

    Anyone else remember Oracle's ad campaign claiming to be "unbreakable"?

    • 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 "le
      • by hanshotfirst (851936) on Wednesday July 30 2008, @07: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 technomom (444378) on Wednesday July 30 2008, @08:20AM (#24400363)

        Did anyone actually drill through the article to the fix?

        The exploit is in BEA WebLogic server, not in the Oracle database. BEA is a web application server company that Oracle acquired about 2 months ago.

  • nice timing (Score:5, Funny)

    by Anonymous Coward on Tuesday July 29 2008, @10:11PM (#24396227)

    This would seem to be a pretty decent answer to the previous thread (How do geeks get exercise).

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

    "Oracle: can't break it; can't break in"
  • ...pen and paper.
  • Worthless (Score:5, Funny)

    by jlarocco (851450) on Tuesday July 29 2008, @10:21PM (#24396335) Homepage

    For christ's sake. At least link to the fucking Oracle page [oracle.com].

    If I wanted to read ZDNet, I'd just go to fucking ZDNet.

  • by SlashWombat (1227578) on Tuesday July 29 2008, @10:38PM (#24396475)
    I would have thought that an exploit like this would be worth a huge amount of money ... For Oracle, but now for the great pool of unwashed out there.

    It strikes me that if Oracle (and other HUGE software vendors) were to offer substantial cash incentives to find holes as gaping as this one obviously is, that the exploit would have been reported directly to Oracle. By substantial i mean in excess of 100,000 euros. (I would have said US dollars, but that currency isn't worth much any more!)
    • The fact that Oracle has tens of thousands of employees points to the fact that Oracle does, in fact, offer a substantial cash incentive for finding bugs like these. The problem is not the money, the problem is the architecture. As long as things like Oracle are written in a massive jumble of C and other low-level, unsafe languages, they will be crawling with bugs. All the money in the world isn't going to get you to a state of zero remotely exploitable flaws.
      • by rubycodez (864176) on Wednesday July 30 2008, @12:16AM (#24397223) Homepage

        this is an article about an exploit in the BEA Weblogic J2EE Server, which until very recently had nothing to do with Oracle (the company) at all nor Oracle (the DBMS)

        I can't believe all the tards here going off about Oracle's DBMS code base.

        • I don't care what label they put on it: it's still unsafe native code garbage. You will note from the exploit and discussion that the problem lies in mod_wl.
          • Re: (Score:3, Insightful)

            So what do you think your interpreter is made of? Somewhere, "unsafe" native code has to run.

            • Re: (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.

      • Re: (Score:2, Insightful)

        The fact that Oracle has tens of thousands of employees points to the fact that Oracle does, in fact, offer a substantial cash incentive for finding bugs like these.

        Do you mean how they pay employees and some of those employees are involved in testing and debugging? That's not the same as paying for vulnerabilities. Do those employees get a bonus for finding vulnerabilities? What about if someone who is not an employee finds a vulnerability?

        The problem is not the money, the problem is the architecture. As long as things like Oracle are written in a massive jumble of C and other low-level, unsafe languages, they will be crawling with bugs. All the money in the world isn't going to get you to a state of zero remotely exploitable flaws.

        True, but if people got paid for reporting vulnerabilities they would be more inclined to report them to Oracle.

  • Some Oracle That Is !!

  • by Anonymous Coward on Tuesday July 29 2008, @10:44PM (#24396531)

    i just tried to google mod_wl and the first page
    of the results do not clearly tell me what mod_wl
    even does. i do not know a single person who uses
    it and i work a large ISP.

    this has nothing to do with oracle's database and
    i think slashdot editors really need to stop with
    these silly headlines designed to get me to click
    on stories. grow up! make a profit without deceit!

    frankly, this post about this overflow is such
    a non issue for me it is funny.

    can anyone explain what in the heck mod_wl even does?

  • Sweet, I've been wondering how to hack the trouble ticket system's Oracle back end at work. Now when a deploy has issues in production that weren't seen in development, I can retroactively fix my ticket attachments so it looks like the system engineers screwed up the deploy. Muahahahahaha!!!!

  • The hacker thought "Oracle" already knew ;-)
  • by Samari711 (521187) on Tuesday July 29 2008, @10:58PM (#24396629)
    not nearly as panic inducing as I first thought, although I'm sure my program management is going to get all bent out of shape about it anyway. Bad news if you Apache with WL though.
  • by InlawBiker (1124825) on Tuesday July 29 2008, @11:25PM (#24396863)

    "Whoever published the vulnerability and matching exploit code did not contact Oracle first."

    It's interesting to me that this is a tag in the OP. I realize it's part of the Hacker's Code of Ethics to report exploits to vendors and I fully agree with it. For the most part it's people pushing software to its limits that find the bugs. BUT - the more business is done on the Internet the more valuable exploits become.

    I am under the belief that somewhere out there, black-hat organizations have some really scary databases of exploits that have never been reported to vendors.

    Reporting to vendors is the right thing to do, but if there's one thing I've learned in my life it's that when money and ethics collide money almost always wins.

    • Re: (Score:3, Insightful)

      I am under the belief that somewhere out there, black-hat organizations have some really scary databases of exploits that have never been reported to vendors.

      No need for abstract belief; this is near certainty. Even "better", I've seen stuff that would curl your teeth that the vendor apparently knew about but remained quietly unpatched. That was in the toolset of a professional IT security testing company. Their stuff made Metasploit look like a Lego model of a battleship vs. the real thing. It's sobering knowing that tools exist that are the direct realization of the weakest link principle. With really well-thought out and easy to use UI, and backend code

      • I once found a bug in a major SCADA platform that, from talking to someone who worked for the company that developed it, they knew about and had a fix for; their support people had instructions to only tell you about it and send it to you if you'd actually found the bug. As in found it and knew what it was (namely a memleak).

        • That should be criminal (not proactively providing the patch to customers). Stuff connected to SCADA equipment can kill you (in lots of cases, like electrical substations and gas pipelines).
    • Reporting to the vendor is pretty much useless. They will stonewall you and then, for something as big and inertial as Oracle, the patch will come out five years later. It's much more important, and, to me, much more aligned with sound ethical principles to report the problem immediately and directly to the public. By doing so you give the users and administrators a fair chance to quantify the risks of using the product, and to try to offset those risks with countermeasures.

      If you just report it to Oracl

  • by Fallen Kell (165468) on Tuesday July 29 2008, @11:33PM (#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, @12: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: (Score:2, Insightful)

      What a surprise! They were exploited by an actual hacker. Whodathunkit?
    • I forgot to let Oracle know first. Forgive me.

      Sureee...let me guess, you would have contacted Oracle, but you were too much of a coward and figured they might find out who you were.

    • Re:Unbreakable (Score:5, Informative)

      by dannycarroll (180967) <dan@[ ]tnik.net.au ['spu' in gap]> on Tuesday July 29 2008, @10:19PM (#24396313)

      This exploit affects the Weblogic product. Oracle only acquired that a few months ago.

      It's got squat to do with the DB product.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        very true, it is only the patch from 2 weeks ago for the other 45 vulnerabilities we have to worry about :(. God I hate there quarterly patch cycle, too many important security patches mixed up with other stuff that needs extensive testing before deployment.

      • Re: (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.

    • by achurch (201270) on Tuesday July 29 2008, @10: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 SpazmodeusG (1334705) on Tuesday July 29 2008, @10:59PM (#24396643)
      C++ does know the size of arrays. That's why you call call delete [] myArray; without specifying the size of the array.
      What C++ doesn't do is test if the index is out of bounds every time you access the array. It makes it faster but you should remember to put the test in if the index isn't guaranteed to be correct.
        • Actually a better example of C/C++ knowing the size of the arrays would of been the sizeof() operator.

          You're thinking of the infamous `size've` operator.

    • by Anonymous Coward on Tuesday July 29 2008, @11:00PM (#24396661)

      And Princess Diana is a victim of cars lack of a 30 MPH speed cap.

    • That's flamebait but nonetheless...

      It's not as if Java never [securityfocus.com] had [sun.com] any [securitytracker.com] buffer [uni-stuttgart.de] overflows [gnu.org].

      As for C/C++, with great power comes great responsibility, either that or for the love of Pete use an std::vector.
      • When I was developing a game for class, I initially began using std::list to store my entities. With more than a trivial amount, it was extremely bogged down. When I swapped that over to an inline linked list built into the class, I gained about 4x performance.

        The STL is *not* useful for time-sensitive applications.

        • Not sure if this is relevant to your situation, but I've found that GNU std::list sucks compared to almost any other data structure. Never bothered to check why, I now just try to avoid it. Sorry, but you happened to stumble upon the worst of the lot.

          If you think you can beat std::vector... good luck. You won't, for any non-POD type.

        • by MadKeithV (102058) on Wednesday July 30 2008, @02:57AM (#24398173)
          The thread is talking about arrays, and you mention std::list. Right, C++ standard library golden rule #1: always use std::vector, unless you have a really, REALLY, REALLY good reason to use something else. See also one of the other child posts.
          std::vector is the array replacement. It has good random access speed. It is guaranteed to use contiguous memory. If it's not fast enough that's probably because you are allocating memory because you are storing by value and the STL makes a lot of copies of stored values internally in many operations(see other child post) - and that can be solved without defaulting to pointers by using a custom allocator.
          If any of this seems too complex to you, you shouldn't have been bothering with performance-critical C++ yet, and learning more about the language and libraries first. I recommend the book "Efficient C++" [google.be] by Dov Bulka and David Mayhew as an introduction, and "Effective STL" [amazon.com] by Scott Meyers for more on the standard library.
      • or for the love of Pete use an std::vector.

        What's love got to do with it? In fact, if you go for money, you are probably more likely to find a good std::vector. Sorry, old joke. Couldn't resist.

    • I'd comment on the absurdity of your comment, but it's much more fun to point out to trolls that their grammar stinks.

      It's "might not have caught it", although, we all expect trolls to have the linguistic skills of neanderthals.