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.
Whoops, that was my fault (Score:4, Funny)
I sent the email to 0racle. Too much l33tness, sorry.
Haha! (Score:5, Informative)
Anyone else remember Oracle's ad campaign claiming to be "unbreakable"?
Re: (Score:3, Interesting)
Re:fuck unbreakable. it sucks. (Score:4, Interesting)
Re:fuck unbreakable. it sucks. (Score:5, Informative)
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.
Re: (Score:2)
Wow - run from that job. Seriously, it sounds like no one there had a clue.
Oracle may suck, but it does run relatively securely (as does any other DB) if you follow proper procedures.
We had hot-failover oracle DB servers running in a 5 9s configuration for 3 years without any unscheduled downtime. There was no need to patch the DB because it was fully firewalled from everything except the application servers, and we could patch those in sequence without bringing down the entire system, or customers even rea
Re: (Score:2)
Anyone else remember Oracle's ad campaign claiming to be "unbreakable"?
I'm constantly amazed that companies (and fan boyz) still have the stones to make that claim about anything. Same with Mac..."It Just Works"...
Re: (Score:2)
People who write 60K per CPU software probably think that people will treat it
in a manner comparable with a 60K doo-dad. IOW,they won't leave it lying around
on the front porch in a shoddy nieghborhood.
Most people don't. They don't actively encourage that.
So they're not expecting it (like Microsoft).
BTW, Oracle takes great pains to avoid root. So being "owned" should mean at
most that the Oracle account was owned (typically a universe unto itself).
If the rest of the box got owned then you've got other (non-or
Re: (Score:1, Funny)
nice timing (Score:5, Funny)
This would seem to be a pretty decent answer to the previous thread (How do geeks get exercise).
Re:nice timing (Score:5, Funny)
Re: (Score:1)
They have backpeddled (Score:5, Interesting)
"Oracle: can't break it; can't break in"
That's why I use... (Score:2, Funny)
Re:That's why I use... (Score:5, Funny)
Re:That's why I use... (Score:5, Funny)
[command executing...]
[timeout ID-10-T - CPU has entered sleep mode]
Re: (Score:2)
Worthless (Score:5, Funny)
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.
Re: (Score:1, Funny)
Lose the language, you unrefined ruffian. Do you talk to your mother with that mouth? Do you think it makes your point (or lack thereof) stronger? Got masculinity issues?
One man's ruffianity... (Score:5, Insightful)
Moving to a university research lab after five years in IT at a paper mill in East Bumville, I really had to make a conscious effort to unlearn the conversational vernacular that I had picked up over the last few years.
Oh, and I believe the correct expression is "Do you kiss your mother with that mouth?"
Re:One man's ruffianity... (Score:5, Funny)
And the correct answer is "No, but I kiss yours."
Re: (Score:2)
Profanity is the literary crutch for the inarticulate motherfucker.
Re: (Score:2)
It was a joke. I was being ironical.*
* the word 'ironical' is also a joke++
++ no it wasn't(1)
(1) actually, yes, it was. But I was being ironical again.
Re: (Score:1)
Re: (Score:2)
Pull your skirt up. You're mumbling.
You can see the lips moving, but you can't hear what they're saying?
I thought that was more of a problem with tights than with skirts...
Re: (Score:1)
Re: (Score:2)
Do you talk to your mother with that mouth?
Sure do!
Do you think it makes your point (or lack thereof) stronger?
It can. In fact, that's the whole point of profanity: to create a strong emotional impact, in order to better convey the feelings of the speaker. Of course, one must be sensitive to context, but it's certainly not out of place on Slashdot.
Got masculinity issues?
Stereotype much? Some women I know swear like sailors... are you saying they, too, long to be more masculine?
Speaking of stereotyping (Score:2)
Stereotype much? Some women I know swear like sailors...
Damn it, now I have to get my irony meter recalibrated. You just pegged it.
Re: (Score:2)
Ha ha, touche. Though, in my defense, that's a cliche base on a stereotype, used to convey an idea, and not meant to be a stereotype in and of itself.
It could of been worse. (Score:2)
Re: (Score:2)
"For christ's sake. At least link to the fucking Oracle page. "
In Soviet America, Oracle fucks you.
Re: (Score:2)
No, but it IS starting to become trendy to clench your cheeks while they're fucking YOU, so there you go....
perhaps if they paid ... (Score:5, Insightful)
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!)
Re: (Score:2)
Re:perhaps if they paid ... (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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)
if I go and build an application using overhead on top of more overhead, I'm building on a codebase that's had millions upon millions of hours of real-world testing. Moreover, that overhead, 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.
No, but it'll have less overhead. I wonder if they were concerned about performance when they designed this?
Seriously, though: I'm not saying the application design you described doesn't have its place. In fact it's an excellent way to avoid these sort of problems if you're willing to sacrifice some flexibility and speed. In a high-performance database, though, every little bit is critical. Yes, they must hire top-notch programmers to avoid mistakes like this, but isn't that why the software package costs s
Re: (Score:2)
No, but it'll have less overhead. I wonder if they were concerned about performance when they designed this?
Congratulations, you're arguing against a point I never made. I never once claimed that switching to a safer language didn't have it's tradeoffs (all such choices do). But that choice *does* bring additional safety, contrary to what the GP would have you believe.
Re: (Score:1)
what the GP would have you believe
...was that someone, somewhere, has to use so-called "unsafe native code garbage", if only to write the interpreter (compiler, more accurately) that allows you the additional level of safety given by the safer language. Thus, you can't simply make a blanket statement of "nobody should use it" (because some situations require having the extra edge it gives: which was precisely my point, and his too). Maybe you just misunderstood his point.
Re: (Score:2)
Is it fair to say we agree that morons shouldn't be producing software?
I think you're right, actually. :)
It's still Oracle Inc's problem (Score:2)
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)
If the software sucks so much, maybe they shouldn't have bought it.
(Note to those with a high input impedance, the above is called hyperbole. I don't know a thing about BEA WebLogic J2EE server, other than that I'm sure it's expensive. The point is that when a company purchases another company, they're taking on obligations with it. This is Oracle Inc's problem.)
(I agree that clarifying that this isn't Oracle-the-product in The Summary would have been a good thing.)
Re: (Score:2)
no, as of right now the product is still called the BEA Weblogic Server
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.
Slippery backfiring slope... (Score:2)
"True, but if people got paid for reporting vulnerabilities they would be more inclined to report them to Oracle."
Actually, I think it would make security researchers (white hat) and 'security researchers' (black hat) far more likely to not contact Oracle with full details as they may have in the past, and instead tell Oracle "we've found a vulnerability. For $100,000 we will tell you what it is. For $0 we will tell... other ...interested parties." ( where other interested parties may be baddies or the pu
Re: (Score:1)
C and other low-level, unsafe languages
Unsafe? That's like saying I-beams and granite are unsafe building materials because it's possible to build a structure that collapses... if that concept was applied to construction, architects would be using pre-fabbed rectangular rooms marked "This side up" and "Do not stack over 3 high".
It's a fucking Oracle !! Should it have known ?? (Score:2, Funny)
Some Oracle That Is !!
"0 day?" (Score:1, Funny)
this exploit is over 10 days old now, slashdot you are wayyy to late on reporting this.
what in the world is mod_wl do? (Score:4, Insightful)
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?
Re: (Score:1)
on squeezing their posts
like this?
There is an art to formatting
one's post for effect,
but this is a web forum,
not some scrunched-up
afterthought of a
newspaper column!
Oh, wait...
Re:what in the world is mod_wl do? (Score:5, Informative)
It's a module that implements a communication protocol, this protocol enables features that are useful when dealing with clusters, such as load balancing, server affinity (user with an active session always hits the same server), better integration with caches and reverse-proxies, etc...
Re: (Score:2)
After taking a look at the exploit code, a few perl lines, it seems that it targets the apache module itself. It's a buffer overflow exploit, the AppServer wouldn't be affected because it's Java.
So, if you're using Apache2 it will cause your server to segfault and die. And, as Apache is usually the only way to get to the AppServer, it will become unreacheble.
Re: (Score:2)
And yes, this is really a BEA issue, which is of no surprise. Frankly, issues like this have existed for years in the world of Microsoft IIS. Why BEA would allow something as trivial as this sounds is what
hack my trouble ticket system (Score:2, Funny)
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!!!!
A misnomer (Score:2, Funny)
It's for Weblogic, not Oracle Database (Score:4, Informative)
Re:It's for Weblogic, PANIC!!!! (Score:2, Informative)
you should panic if it's for weblogic. Your oracle databases are not open to the Internet. But weblogic, or especially this buggy plugin in your apache, is!
That means: potentially free access to your webserver!
"Did not contact Oracle first." (Score:4, Insightful)
"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
Re: (Score:2)
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).
Re: (Score:2)
Re: (Score:2)
In this case what it did was cause the system to fall over once a day and need rebooting; fortunately all that meant was they couldn't change the lane assignments on a conveyor belt system until it came back up again.
I come from the old school of thought that says that a SCADA system should be able to fail without adversely affecting the safety of the overall system. You lose your overview and control, but the automatic controls and safeties should continue to operate and make sure nothing really bad happe
Re: (Score:2)
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
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.
Re: (Score:2)
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.
Outsource the Risk (Score:2)
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."
I'm surprised this bug wasn't handled through the Zero Day Initiative [zerodayinitiative.com]. The researcher gets paid, TippingPoint runs interference on any legal bullying, responsible disclosure ha
Re: (Score:2, Insightful)
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
Do you have any idea what that kind of checking costs?
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
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: (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.
Re:Another victim of C/C++ lack of array safety (Score:5, Informative)
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.
Re: (Score:1)
Re: (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: (Score:2)
C++ does know the size of arrays.
Not quite, C and C++ know the size of memory blocks allocated with malloc or new and can retrive that information given a pointer to the start of the block.
What they don't know is given a pointer to an array whether that pointer points to the start of a memory block on the heap or to an array on the stack or to part of a larger array on the heap.
This makes it rather difficult to add strong bounds checking in a way that doesn't break existing correct code.
Re: (Score:3, Funny)
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.
Re:Another victim of C/C++ lack of array safety (Score:4, Funny)
And Princess Diana is a victim of cars lack of a 30 MPH speed cap.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Another victim of C/C++ lack of array safety (Score:5, Informative)
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.
Re: (Score:2)
Thanks for the book recommendations.
As I said in my other reply, I was storing pointers, not class instances. That's not a good golden rule. I was using a list because I needed fast random insertion/removal, since it was for game entities which could be created/destroyed at any time. An array would have been crazy slow without doing some sort of funky hashing. Also, as it was for game entities, I didn't need random access. I'd be iterating over the list once per frame and adding/removing.
Tried an unordered set? (Score:2)
I was using a list because I needed fast random insertion/removal, since it was for game entities which could be created/destroyed at any time. An array would have been crazy slow without doing some sort of funky hashing. Also, as it was for game entities, I didn't need random access. I'd be iterating over the list once per frame and adding/removing.
Then you don't need a list as much as an unordered set (C++ std::hash_set, Python set, Java HashSet).
Re: (Score:2)
IOW, you need to be aware of how the component does things internally.
Of course this negates much of the CIS justification for using that component.
Re: (Score:2)
No, I didn't. I know how to code. I never bothered to look into it, and it may very well just be how I was using it (I doubt it), but since that experience, I haven't even bothered profiling STL vs. slimmer code.
Re:Another victim of C/C++ lack of array safety (Score:5, Funny)
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.
Re: (Score:2)
It's not as if Java never [securityfocus.com] had [sun.com] any [securitytracker.com] buffer [uni-stuttgart.de] overflows [gnu.org].
The difference is, once they're fixed in Java, they're fixed for everyone. Meanwhile, any moron with a C++ compiler can create an app with a buffer overflow.
That's not to say safe languages are an all-purpose panacea (obviously there are tradeoffs to any language choice), but I think even you must realize that your argument is a weak one. The Java VM is a classic example of c
Re: (Score:1)
The difference is, once they're fixed in Java, they're fixed for everyone. Meanwhile, any moron with a C++ compiler can create an app with a buffer overflow.
Is it fair to say we agree that morons shouldn't be producing software? Particularly expensive, supposedly-secure software that may be critical to operation?
Re: (Score:2)
Is it fair to say we agree that morons shouldn't be producing software?
Since when were buffer overflows limited to stupid programmers? Last I checked, every programmer was human, and thus every programmer makes mistakes (my glorious, unbelievably awesome self included). And in the world of unsafe languages, just one absent-minded error can translate into a severe security issue. Yes, you can institute conventions and procedures, and make design decisions which minimize the chances of such things happeni
Java buffer overflows are in C code (Score:2)
Where the code is available, it looks like those buffer overflows are in C code of the Java implementation. [gnu.org] Glue code between Java and some C component usually seems to be the problem.
Re: (Score:2)
Gah, I know it's flaimbait but I can't resist. As has already been pointed out, C and C++ both do know the size of arrays. However, unlike Java, the C and C++ idiom of decaying arrays to pointers causes that information to be lost in the callee. It is intentional behavior, because it is expected that the user (programmer) manages array sizes correctly.
The cost is that programmers who don't know exactly what they're doing run into these problems. The benefit is that the program runs as fast as possibl
Fix your grammar (Score:3, Insightful)
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.