Slashdot Mirror
KDE Heap Overflow Vulnerability Found
sayanchak writes "An incorrect bounds check has been discovered in kjs, the JavaScript interpreter engine used by Konqueror and other parts of KDE, that allows a heap based buffer overflow when decoding specially crafted UTF-8 encoded URI sequences. It might allow malicious Javascript code to perform a heap overflow and crash Konqueror or even execute arbitrary code. Source diff patches for KDE 3.2.0 - 3.3.2 and KDE 3.4.0 - 3.5.0 are available."
The obvious question is - does the same bug exists in the KJS-derived Safari Javascript?
The complaint about MS is the running of said things in or at the kernel.
The only people who make that complaint are people who don't have a clue what they are talking about. Internet Explorer doesn't run "in or at" the kernel. It runs with the user's privileges, just like any other application.
The problem with "Internet Explorer" is that its rendering engine, Trident, is embedded by a great many applications, so any vulnerability in Trident is also a vulnerability in those applications. The same is true of KDE/KHTML/KJS. If a vulnerability is found in, say, KHTML, it also means KMail and Amarok are vulnerable.
Unfortunately, this is the downside to modern component-based strategies - it's not a Microsoft-specific problem. However the beneefits of these strategies vastly outweigh the downsides.
Of course software has bugs. Given that, the key thing is how the software authors treat such bugs. Open Source authors tend to be very honest about and immediately provide fixes for security holes, while Microsoft tends to softpedal and delay.
The problem is not the bugs, it is how they are handled.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
There are patches already available. Fix it. Move on.
There are source patches available. That's fine for you and me, but it's no good for the increasing number of "normal" users who are moving to Linux, who wouldn't be able to apply them if you showed them how. They still have to wait on binary patches from their vendors.
Mind you, this is not like what happens with "some other operating systems," where they have to be berated by users into issuing patches...
That's mostly because the self-same users berated them into only releasing patches once a month at most; they can't have it both ways. I'd also be willing to bet that patches from commercial OS vendors go through rather more rigorous QA processes than this; support contracts and such like make that essential.
It's official. Most of you are morons.
Working on embedded systems I'm used to checking every malloc(). It is fairly easy to do, but you need to design your application to handle out of memory situations gracefully. That is not as easy depending on what you are trying to do.
Yes, but on an embedded system, you almost always have an init phase where you allocate all the memory that you need at startup, and so you have an init() function or similar that either fails or succeeds at startup containing checked mallocs. Then you have *one* cleanup path. You only guarantee that your application handles up to N resources used of each type at runtime (100 connections, 30 open files, whatever).
Checking malloc in the middle of your code is essentially an obsolete practice for real-world systems -- it's essentially impossible to cleanly back out of all failures, and nobody is going to test all possible failure conditions. The fact that Linux uses an OOM killer and overcommits by default is just a recognition of this fact.
I know this goes against what some people learn, but let me ask those people who carefully check every failure:
* Do you actually test each bit of cleanup and error-recovery code? I mean, are you using a malloc()/free() wrapper that causes *every* path to be invoked? Otherwise, you're just bloating your application with masses of untested code.
* Are you certain that you can't run out of stack space, not just heap space? Particularly if you're using C++ and local objects, I'm pretty dubious that you're so sure. Do you really know, for certain, how much space a random STL object uses?
Systems these days have so much memory and virtual memory that running out of memory is almost *always* a bug. It's a pretty safe bet that the allocation that causes your app to run out of memory is the culprit. Even if Linux didn't have an OOM killer, I'd feel safe in almost all circumstances just wrapping malloc() with an abort() on failure.
Some applications might be fed huge workloads inadvertently. Those are better off adding checks specifically for those workloads. For example, if you load a huge image in the GIMP, you'll get a warning based on the size before the GIMP attempts to do memory allocation, not after the failure happens.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Wikipedia has a few articles that might interest you. Please look at Stack Smashing Protection to learn about canaries and tools such as ProPolice. ProPolice is part of gcc, so you can build practially any open source OS with this protection today. (This makes buffer overflows much more difficult, if not impossible.) It should not surprise any Slashdot reader to learn that OpenBSD uses this by default. OpenBSD also adds W^X protection to each page. It is ironic that you reference Intel on a no execution bit. If you read some of the developer comments from the OpenBSD team, it is pretty clear that AMD 's 64-bit processors and all RISC processors have better implementations of the no-execute bit than does Intel. It is doubly ironic that you mention Microsoft for Data Execution Prevention, since this sure seems like they are trying to appear to be the inovator of this technique. This is pretty typical for MS, and it explains why many people seem to believe that MS inovates and free software copies. The reality, in this case and many others, is often the opposite.
Think global, act loco