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."
Who has variables named "vvvv" and "uuuuu"? At least make them somewhat useful, even if they are temporary variables.
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.
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
Probably, but expect silence until Tuesday, when a patch will suddenly appear to bump Safari to 2.0.4.
Does this affect Safari?
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
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.
Is it? It also means just one place to fix the bug, because there are less people reimplementing functionality. The real problem with Microsoft is their sloppy bug fixing.
that even with a relatively clean codebase, bugs happen. Konqueror is good code compared to a lot of things, but I guess complexity is unavoidable, and that leads to things like this.
I am trolling
"With this, the patch was available almost immediately, and within hours"
If its avilable within hours someone have failed to test it properly, there is thousands of combinations of hardware and software and god knows what a quick and dirty patch can break.
http://www.intellipool.se/ - Intellipool Network Monitor
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.)
Also means if you fix the problem in one component, others are fixed automatically
They called me mad, and I called them mad, and damn them, they outvoted me. -Nathaniel Lee
By the time you and I heard about it, there was already a fix. On the other hand, if it's existed since 3.2 onward, that means this flaw has been in place since at least February, 2004. The fact that it's public now and there's a patch now doesn't mean that there wasn't some sharp-eyed and black-hearted soul who spotted this hole years ago, and has been quietly taking advantage of it ever since.
ABSURDITY, n.: A statement or belief manifestly inconsistent with one's own opinion.
Yes, Explorer.exe will normally load mshtml.dll to render the info pane for folder contents. Yes, you can still turn off that and use classic folder view. In that case, Explorer.exe doesn't use the rendering engine of IE (unless you use HTML-based Active Desktop, but NOT web folders, a somewhat surprising combination). It's as simple as that. As another comment noted, the common controls were updated with IE and with IE as a recommended way to redistribute the new DLL.
Also, if an administrative user logs in, it will be with the admin profile. There is no immediate reason that someone only using Explorer.exe to browse the HD, even with web folders active, will somehow pick up a known exploit for Trident/MSHTML.
Autorendering of HTML mail has historically been a much worse decision than the use of HTML in the user interface of some local apps. Still, that is a decision that makes some sense, at least if one accepts the idea of people wanting formatted mail at all.
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
a) Because if you run out of memory in a JS interpereter in a graphical app, what are you going to do? You can't display anything, all you can do is exit. In which case an OOM segfault would have been more informative anyway. Sounds like this was posted by someone without much practical experience in GUI apps.
b) For one, KDE never uses STL, because for one when it was wirtten it was not available on all the platforms it needed, and for two Qt's containers are just better and more efficient than STL contains in general anyway.
Except that Microsoft takes the strategy much, much further than KDE does -- not only is explorer the component for rendering HTML, but it also renders the desktop, taskbar, start menu, etc.
Please for the love of God tell me you were kidding?
The HTML rendering Engine is NOT Explorer, nor is it even Internet Explorer. And Explorer is NOT Internet Explorer. Understand?
Sure Explorer can call features from the HTML rendering engine, just like it can call feautres from the BMP and Font rendering engines. But this does NOT mean Explorer itself is a PART of the HTML rendering engine.
Addtionally, The Taskbar, Start Menu, etc are not rendered using the HTML engine, and the only time the desktop is rendered along side the HTML rendering engine is when Active Desktop or HTML apps or Pages are placed running on the desktop. Just because Explorer can use the HTML engine does not make it the HTML engine. You could set the system that Explorer NEVER calls any functions out of the HTML engine if you really wanted...
Just remember this, the HTML rendering engine in Windows is what everyone hates. It is not Explorer nor even Internet Explorer. Internet Explorer is a fairly small application that wraps around the HTML engine technologies to give the engine an application interface.
As for the whole HTML rendering being allowed in the OS and other applications, I think the whole argument is a place were people are mislead or try to be misleading.
Almost ALL modern OSes do this or use this to one extent or another. Additionally, even if the OS interface doesn't provide a 'common' HTML rendering technology for third party applications, many third party applications either tap into or strap on HTML engines for everything from part of their UI to their help systems.
So remember before people get on their anti-MS soap boxes, remember - ALL OSes do this, or allow this in one way or another. From OSX to Solaris. PERIOD.