KDE Heap Overflow Vulnerability Found 233
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."
Re:This is why I use Windows (Score:1, Informative)
Ubuntu patched already (Score:5, Informative)
Rich.
About the Patch (Score:3, Informative)
Patches for both 3.2.x - 3.3.x and 3.4.x-3.5.0 are the same except for the revision number. I think Slashdot got the link switched around.
Although Apple does use some of the Konqueror's core, I believe that the bug does not affect it at all. At least there is no such vulnerable function as in KDE is in their JS core code.
Re:KJS is also used by Apple in Safari (Score:2, Informative)
JavaScriptCore
JavaScriptCore is a framework for Mac OS X that takes the cross-platform KJS library (part of the KDE project), combines it with the PCRE regular expression library, and makes it work with Mac OS X technologies.
The current version of JavaScriptCore is based on the KJS library from KDE 3.0.2. The few changes that are specific to JavaScriptCore are marked with #if APPLE_CHANGES. Other changes to improve performance and web page compatibility are intended for integration into future versions of the KJS library.
Re:This is why I use Windows (Score:4, Informative)
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.
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. A better name for Vista would be "Explorer 2006." KHTML is present only in a few select KDE apps -- and you can get away with never using those apps, and never even installing KHTML, and still use KDE.
The benefits of using explorer everywhere are...come to think of it, there are no technical benefits in doing so, but there are plenty of legal benefits (we can't remove explorer without taking out 60% of the rest of Windows!). The KDE team has no reason to do such a thing, and the open-source model essentially means that they never will -- they can focus on technical improvements, and technical advantages of different approaches.
As for running in kernel space...no, Explorer does not, it runs with the privileges of the user who uses it...but for the majority of Windows users, that is somebody with "administrative privileges." Consider that situation: a user with total control over the system, who can change or overwrite anything, is using a single component for everything they do. A single vulnerability could allow malicious code to get into the kernel. The majority of Windows users, even in some mid-size organizations I've seen, log on as superusers, and new accounts are created with superuser access by default. Worse, when there is a legitimate reasons for a superuser to log in, he is logging into an Explorer shell. This is why explorer exploits are so much worse than KHTML.
Re:This is why I use Windows (Score:3, Informative)
Oh, nonsense.
Fact is, the term "Operating System" is far older than linux, dating back to the 1950s. On almost every processor ever built, it has a precise definition. The definition is hardware based.
In the machine language, there's an opcode usually called SC (System Call). If you need to use a SC instruction to get to some subroutine, you're at the application level. If you don't need to call SC to get to that subroutine, you're in the operating system. It's as simple as that. (Well, except for a few machines with hardware support for multi-level OS security, by having multi-level SC opcodes.)
The idea that things like runtime libraries are part of the OS shows a profound lack of understanding of computer architecture.
NTTAWWT, of course. I don't expect the typical user to to understand the architecture of the machine they're using. But making claims about such architecture that are blatantly false doesn't convince anyone who knows even a little about the subject matter.
(A funny thing about the SC instruction is that in many processors, it isn't actually an implemented opcode. What happens when a program does a SC, is that an "unimplmented instruction" interrupt occurs. The interrupt routine looks at the opcode, and if it's the SC opcode, it jumps to the SC routine. Calling it "SC" is merely a promise to never implement anything for that opcode. But in some processors, it is an implemented opcode, which takes a tiny bit of real estate, but makes every SC slightly faster by eliminating that test.)
(And now I expect the assembly programmers here to fill this discussion with further detail of just how SC works on various processors present and past
Re:This is why I use Windows (Score:3, Informative)
same goes for gentoo (Score:2, Informative)
Yes people, look at this (Score:4, Informative)
And this [kde.org] 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...
Re:Rather incompetent (Score:2, Informative)
Well this is a rather common practice these days.
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.
On a desktop system this is not as important since you usually have lots of memory and even more virtual memory. The default linux behaviour of overcommiting memory and then later killing some random app if out of memory, often means the memory allocation will not fail at all.
In fact most libraries and apps on your linux installation is not out of memory safe. That includes glibc, Qt, and obviously KDE.
Re:This is why I use Windows (Score:5, Informative)
You make many many assumptions. I'm the CIO of a publishing company, I had my MCSE years ago, I am happy with Windows and Microsoft and just signed off on another 40 workstations with Windows on them. I am in no way anti-Microsoft, nor am I a teenager who think Linux is some sort of sacred ground. I use Linux personally because I've been using some variant of Unix for close to 25 years now.
That said, the question was what makes Microsoft have a bad reputation when it comes to bug fixes while Linux (meaning the distros) does not. Today systems are all online, and a critical feature of any operating system is the speed of the support to reliably fix security holes, especially those which can be remotely exploited.
We are talking about why Microsoft has a perception of being worse about bugs than Linux (or at least I was responding to that). I still maintain that, to quote myself, "Open Source authors tend to be very honest about and immediately provide fixes for security holes, while Microsoft tends to softpedal and delay". Microsoft has been addressing this aggressively recently, with various announcements that they are refocusing on bugs, and more regular updates. Still, their lackadaisical attitude toward security in the past has cast a long shadow that taints them today, both with a poor codebase and a reputation for poor support for bug fixes. Plus, as was my initial point, open source tends to provide reliable fixes quicker -- for whatever reason -- which not only garners respect for their corner, but also makes Microsoft look slow... and that affect perception.
--
Evan
Re:This is why I use Windows (Score:3, Informative)
That's exactly the point I made. You are making an academic distinction that has little to no relevance to how application programmers use the OS (or as Sun puts it "operating enviornment").
Re:Plugging the "arbitrary code" hole? (Score:3, Informative)
The reason no-execute is useful is the easiest way to get your own code to execute (rather than jumping to some existing code that does something bad) was to write the code itself to the buffer, along with the overflow that causes a pointer to be overwritten so it jumps to the buffer. This will no longer work if the buffer is no-execute.
Also (Score:5, Informative)
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.
IIS in the latest version does not (Score:4, Informative)
Did you look at the ECMA standard? (Score:5, Informative)
Sheesh, do a little homework first.
Re:I wouldn't call it clean (Score:3, Informative)
Safari *not* affected (Score:2, Informative)
Thanks to Open Source, we can check ourselves whether Safari is affected.
You can see from the patch referenced from http://www.kde.org/info/security/advisory-20060119 -1.txt [kde.org] that the vulnerable functions are: encodeURI, decodeURI.
Now you can download JavaScriptCore from http://www.opensource.apple.com/darwinsource/10.4. 4.ppc/ [apple.com]. It contains the affected source file kjs/function.cpp, but a quick look at it reveals that it doesn't have the same encodeURI, decodeURI functions nor the same flaw.
Re:This is why I use Windows (Score:3, Informative)
This is completely false. If a workstation is a member of a windows domain, a new user account has onlyvery restricted Users-group privileges by default. It has been that way since at least 1996 and NT 4.0, perhaps even with NT 3.5...
WMF exploit is NOT related to MSHTML (Score:1, Informative)