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."
Microsoft would never tie a web browser into the operating system... err, wait.
Who has variables named "vvvv" and "uuuuu"? At least make them somewhat useful, even if they are temporary variables.
I'm going back to Windows!!!
The obvious question is - does the same bug exists in the KJS-derived Safari Javascript?
...yawn and pay no heed. Have any vulnerabilities for Konqueror ever actually resulted in exploits in the wild?
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
There are patches already available. Fix it. Move on. Mind you, this is not like what happens with "some other operating systems," where they have to be berated by users into issuing patches...
GetOuttaMySpace - The Anti-Social Network
And the proposed patch leaks if realloc fails and does not check the return value of realloc. *sigh*
...
Also, one may only wonder why didn't they use std::vector
~velco
Not directly, unless you run as root. On the other hand, local root kernel vulnerabilities may be exploited, and the Linux kernel has new ones discovered frequently.
Alright, here come the slashdot standard defense responses the moment anything is found bad about something related to Linux:
:)
1. Oh, but microsoft takes longer to patch
2. But it is still more secure than windows!
3. Ya, old news, it's already patched!
4. And, this isn't an OS problem it's the shell, windowing, daemon, whatever etc!
And hell yes, I will post this Anonymously as I expect this to be moded as Troll within 5 minutes and I got no karma to burn!
This is the text of the patch. Look at the nice variable names :P
And this is the contents of the guilty source code file. It's filled with such variable names and obfuscated code! Some variable names -> zzzzzzz, yyyyy, xx, uuuuu.
I really never thought that this kind of code was in a project such as KDE. I assume that it's a fairly unique file, but even then it's just really stupid...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
If you study the code a little, you'll see there is some logic to those names: The length of the variable name also reveals the number of bits stored by that variable. "xx" stores a 2 bit value, "zzzzzz" stores a six-bit value.
That's not obfuscated, since if you know the scheme, it improves readability.
(The code doesn't really look obfuscated to me, but OTOH I have been programming C++ for over 10 years.)
The letter in the variable name indicates the order. So if you put together the parts where the sub-bit sections come from, it looks like this:
yyyyzzzzzz
E.g. that stores the lower 10 bits of a value, where zzzzzz hold the lowest six bits and yyyy holds the next 4 bits. That seems like a pretty neat idea to improve the readability of what would otherwise inherently be fairly tricky to read code.
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.
If you look up SQL server documentation and best practices they tell you to switch the user it runas as. IIS and most other services run as network service, which has greatly reduced priviledges.
Check section 15.1.3 of the ECMA standard, which the source refers to. The algorithm is explained there, and the variable names are taken from the standard for readability.
Sheesh, do a little homework first.
Laws do not persuade just because they threaten. --Seneca
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