Slashdot Mirror
Emergency Workaround For Oracle 0-Day
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.
I sent the email to 0racle. Too much l33tness, sorry.
Anyone else remember Oracle's ad campaign claiming to be "unbreakable"?
This would seem to be a pretty decent answer to the previous thread (How do geeks get exercise).
"Oracle: can't break it; can't break in"
In post Patriot Act America, the library books scan you.
What a surprise! They were exploited by an actual hacker. Whodathunkit?
This exploit affects the Weblogic product. Oracle only acquired that a few months ago.
It's got squat to do with the DB product.
...pen and paper.
The CB App. What's your 20?
For christ's sake. At least link to the fucking Oracle page.
If I wanted to read ZDNet, I'd just go to fucking ZDNet.
Maybe not
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!)
Some Oracle That Is !!
this exploit is over 10 days old now, slashdot you are wayyy to late on reporting this.
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?
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.
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.
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 ;-)
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.
I never said I was smart, I just said I was smarter than you
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.
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 had any buffer overflows.
As for C/C++, with great power comes great responsibility, either that or for the love of Pete use an std::vector.
Equine Mammals Are Considerably Smaller
"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.
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.
Wheel in the sky keeps on turnin'.
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.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
By that standard, C does too: realloc and free need to know the size.
Do you even lift?
These aren't the 'roids you're looking for.
One man's unrefined ruffianity is another man's unconscious vernacular.
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?"
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.
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.
I hate printers.
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.
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.
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.
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 possible on the target hardware. If that benefit isn't worth the cost, get out of the way, but don't bitch that the language doesn't coddle you. It's not supposed to.
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.
It could of been a standard kdawson article were we were given a link to a blog which linked to the zdnet or more likly wired article.
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.
I know more than you drink.
(only somewhat tongue-in-cheek)
Do you have any idea what that kind of checking costs?
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++" by Dov Bulka and David Mayhew as an introduction, and "Effective STL" by Scott Meyers for more on the standard library.
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)
i find your lack of faith in science disturbing!
Great! I'm applying for a job there, since it seems management has half a clue at least!
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!
Atari rules... ermm... ruled.
"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 public at large; either way rather undesirable. )
I'm not saying that everybody would suddenly get dollarsigns in the eyes - but certainly many would be tempted.. given that this would essentially be legal extortion.
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.
Good people go to bed earlier.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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...
Why, oh why, didn't I take the Blue Pill?
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.
A Pirate and a Puritan look the same on a balance sheet.
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.
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 realizing that we were doing so.
The entire point is that you can make anything secure, yes, even MS products with the possible exception of IIS/ASP apps, with proper system architecture design coupled with software architecture and application coding. Some are more onerous (MS) to do so. Some might require validating, security, and filtering front-ends to do so, but anything can be made relatively "secure". Note that doing so may limit certain types of functionality and access, so it becomes a balancing act of functionality vs security.
The cesspool just got a check and balance.
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. The researcher gets paid, TippingPoint runs interference on any legal bullying, responsible disclosure happens, TippingPoint gets a market advantage.
The only way this isn't win-win-win is if your goal is to embarrass the vendor.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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 code reuse. With it, you build on software that has millions of hours of time in production, vast amounts of testing and QA, and a single codebase that you can vet for security issues. And anything you build on top of that is only as vulnerable as that substrate. How you can argue that isn't *clearly* a win from a security standpoint, I have no idea... well, other than blind prejudice.
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?
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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 happening. But in the end, there's always the human element.
The premise behind a 'safe' language is to completely remove certain classes of errors, because the designers understand that *no* programmer is perfect. Of course, in some cases, that can come with tradeoffs. But make no mistake, with those tradeoffs comes additional safety.
But in the end, there's always the human element.
The whole purpose of the design, testing, debugging, etc. processes is to eliminate human error. It's fair to expect a high-dollar company to produce bug-free software, and a failure in this area is particularly ironic if that's one of their key advertising points.
The premise behind a 'safe' language is to completely remove certain classes of errors, because the designers understand that *no* programmer is perfect.
That argument also could be used to argue that the "safe" language is never truly safe; it is merely more rigorously tested. Again, high-dollar software companies are expected to test their applications rigorously to avoid this sort of thing. If "safety" is some arbitrary limit that this compiler has reached, it's entirely reasonable to expect expensive commercial software packages to attain it.
But make no mistake, with those tradeoffs comes additional safety.
Don't get me wrong, I'm not trying to disagree with that. My point is simply that Oracle, because the benefits of a lower-level language are desirable for their applications, should have good enough programmers to catch this sort of thing. That's part of their job.
Realistically speaking, they might not actually be perfect, but they're expected to be. It's not fair, but that's life. The only way to deal with this situation is to be as close to perfect as possible. They'll get in trouble if they make mistakes; "we aren't perfect" isn't an excuse.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Stereotype much? Some women I know swear like sailors...
Damn it, now I have to get my irony meter recalibrated. You just pegged it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Where the code is available, it looks like those buffer overflows are in C code of the Java implementation. Glue code between Java and some C component usually seems to be the problem.
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.
Wheel in the sky keeps on turnin'.
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.
Wheel in the sky keeps on turnin'.
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.
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
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).