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."
This is why I use Windows (Score:3, Funny)
OS? No. (Score:2)
Re:OS? No. (Score:2)
IE (Score:2)
At least with KDE, you can drop it totally, and your system is still there and functioning.. Try that with windows somtime.
Not saying either way is right or wrong, just different paths to get to the same place.
Re:This is why I use Windows (Score:5, Insightful)
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.
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:4, Insightful)
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.
Re:This is why I use Windows (Score:2)
The recent WMF exploit that attacked the thumbnailing process however...
Do you have any proof (Score:2)
And if it does render in html, why is that a big deal, if anything it simplifies code, and removes one other area of coding to replicate existing functionality somewhere else.
If in a corporate network people are logging in as admin, you have a network/sys admin problem. NOT a windows issues, fire your
Alternative shells = better security? (Score:2)
By the way, what about alternative shells like the Aston Shell? Do they completely replace explorer.exe or is the Explorer still running in the background? If they do replace the Explorer, installing an alternative shell might improve security on a Windows box.
Re:This is why I use Windows (Score:4, Insightful)
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.
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...
Re:This is why I use Windows (Score:2)
>come to think of it, there are no technical benefits in doing so
Actually, there are plenty.
Such as? Come on, if you make a statment like this, back it up with examples, don't go into flamewar mode.Re:This is why I use Windows (Score:2, Insightful)
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.
Re:This is why I use Windows (Score:2, Insightful)
I do admit they are doing this less now since NT has taken over but the sole reason for instability and early versions of windows was that everything ran in the kernel and one app could violate memory on another app and cause a GP fault. WIndows 3.1 was atroci
IIS in the latest version does not (Score:4, Informative)
Re:IIS in the latest version does not (Score:2)
The method how Mindcraft and Microsoft were able to create the fud benchmarks agaisnt Linux/apache was that IIS 3.0/4.0 ran in the kernel for faster speed. Linus even commented on this saying maybe we should make an os for silly benchmarks. Tux I know is kernel level accelerator created to counter the mindcraft fud but I would not use it in a mission
Re:This is why I use Windows (Score:2, Insightful)
Re:This is why I use Windows (Score:2)
Microsoft reaped the benefits of this design somewhat when they released the WMF vulnerability workaround. By unregistering the COM dll the broken component was removed from service until it could be patched. The GDI function parameter was never flawed, the problem was where it was utilised.
I wonder how many COM libraries there are registered in a typical Windows/Office combi installation that m
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 applica
Re:This is why I use Windows (Score:2, Interesting)
Re:This is why I use Windows (Score:2)
Whatever gave you the idea that a modern system necessarily use a GUI for administration? There are plenty of systems that are managed by serial console only, and quit
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:This is why I use Windows (Score:3, Informative)
Re:This is why I use Windows (Score:2)
Microsoft made the marketing decision to make IE uninstallable. That alone doesn't make it any more or less part of the operating system.
Re:This is why I use Windows (Score:2)
What was your point again?
Re:This is why I use Windows (Score:2)
tight integration [everything2.com] of explorer and the kernel. And if you don't agree, well then who's splitting hairs
Seriously, I use Windows, Solaris and Linux daily and the latter two almost exclusively
without a GUI. You cannot tell me that KDE or Gnome are part of the OS.... GNU/Linux/KDE?
Re:This is why I use Windows (Score:5, Insightful)
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
Re:This is why I use Windows (Score:2, Insightful)
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.
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:2)
Yes, but you don't seem to understand what I'm saying. I am *not* talking about actual technical issues -- the question is one of perception: Why does Microsoft have a reputation to be bad at supporting bugs.
There are reasons for MS' being 'slow' about it!
I do not disagree. However that action *does* create a perception that Microsoft cares less or is less efficient about security. Percept
Re:This is why I use Windows (Score:2)
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."
Modifying a bounds check is a small change, though important; it doesn't break anyone's JavaScript (except the malicious stuff). If it were a problem in a specific function and the fix could modify legitimate return values or place additional constraints on the arguments, th
Re:This is why I use Windows (Score:2)
But you can afford to have a security hole that might allow an attacked to execute code wide open for any moron to exploit? It's unlikely that fixing a heap overflow bug will bring down any of your machines but if it's such a concern, why not use your testing machine (you do have one of these right?) to make sure that it doesn't?
Re: (Score:2)
Re:This is why I use Windows (Score:2)
Variable names? (Score:4, Insightful)
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:Yes people, look at this (Score:2)
Re:Yes people, look at this (Score:2)
it's probably obfuscated stuff that they released to fulfil their GPL obligations when they used and improved KHTML for use in safari
The KDE Project has released a significant update to its K Desktop Environment software that includes refinements to the Konqueror Web browser derived from a collaboration with Apple Computer's Safari browser team. [com.com]...
that's most likely where this has come from.
Re:Yes people, look at this (Score:2)
Meaningful names (Score:4, Insightful)
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 (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.
Did you look at the ECMA standard? (Score:5, Informative)
Sheesh, do a little homework first.
They are decoding UTF-8 and URL encoding (Score:2)
Right thats it! (Score:5, Funny)
Re:Right thats it! (Score:2, Funny)
*looks at his Kubuntu install*
Uh... clearly this patching shows the inherent superiority of Open Source!
Many (slow) eyeballs do what now? (Score:3, Insightful)
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.
Re:Many (slow) eyeballs do what now? (Score:2)
This is one of the most infuriating arguments that I hear about OSS, that because a vulnerability is announced and a patch comes out shortly after, OSS is somehow more secure...
When, in fact, the vulnerability could've existed since the first day the code was released.
Malicious hackers around the world... (Score:5, Interesting)
Re:Malicious hackers around the world... (Score:2)
I haven't had any problem with websites from 3.2 or 3.3 on. I've gotten so used to Konqueror that using Firefox seemed weird.
Re:Malicious hackers around the world... (Score:2)
I keed, I keed.
Re:Malicious hackers around the world... (Score:2)
I use Konqueror all the time, apart from really broken websites which I use Firefox for, or avoid.
Re:Malicious hackers around the world... (Score:2)
Ubuntu patched already (Score:5, Informative)
Rich.
Re:Ubuntu patched already (Score:2, Interesting)
Happily, the debian devels are said to be looking into a way of supplying binary diffs/ deltas of update
same goes for gentoo (Score:2, Informative)
And now the obligatory... (Score:4, Insightful)
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...
Re:And now the obligatory... (Score:2, Interesting)
Re:And now the obligatory... (Score:5, Insightful)
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.
Re:And now the obligatory... (Score:2)
Wine's been patched for the WMF thing as well.
And before anybody else says something silly about JavaScript, there's a patch for a Perl buffer overflow, too.
Re:And now the obligatory... (Score:2)
Ought to be part of any installation these days. My systems are Debian, and the patch was already in place -- apt-get update, apt-get dist-upgrade, and you're done. These days, I would imagine most popular distros have something similar.
Re:And now the obligatory... (Score:2)
No you're not, and that's exactly my point, although I'm not sure that you quite got it. This is a patch to the KDE source. It does jack shit to the binaries that you installed as part of your distro's release of KDE. In other words, if you installed Fedora, or Mandriva, or whatever, this is almost useless to you. In order to use it, you need to download and "install" the KDE source tree, apply the patch, compile the tree and install the result
Re:And now the obligatory... (Score:2)
Stupid crackers...
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:About the Patch (Score:3, Interesting)
Arbitrary code with what privileges? (Score:2, Insightful)
Re:Arbitrary code with what privileges? (Score:4, Insightful)
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.
Re:Arbitrary code with what privileges? (Score:2)
Are you so stupid that you can't go to a Linux distro site and check for security updates?
Re:Arbitrary code with what privileges? (Score:2)
Sorry for the sarcasm, but seriously, WTF are you on? Konqueror is a web browser. Now sit in a corner and think about what you've done.
Rather incompetent (Score:4, Interesting)
Also, one may only wonder why didn't they use std::vector
~velco
Re:Rather incompetent (Score:3, Interesting)
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 de
Checking malloc() is an obsolete practice (Score:5, Insightful)
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.
Re:Checking malloc() is an obsolete practice (Score:3, Insightful)
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.
It is not impossible to cleanly back out failure states. It
Mod down (Score:3, Insightful)
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
Re:Rather incompetent (Score:2)
Give up with a seg fault? Wouldn't it be better to give up with an error?
NO! Don't put those damn checks in. They are WRONG (Score:2)
PLEASE don't put these checks in. Not everything you learned in COMPSCI-101 is correct. Random checks that people like you insist on putting in are misleading, making anybody reading the code think the zero is a legitimate return value. Directly on malloc it is not confusing, but when that function returns zero and the caller checks, it can mislead somebody maintaining th
Re:Rather incompetent (Score:2)
In the case of a Javascript interpreter in something like a web browser, there doesn't seem to be any point to displaying an error message. If you can't get a few bytes for a string buffer, what are the chances you'll be able to create a dialog box to tell the user about it?
And the question on everybody's lips... (Score:3, Insightful)
Re:And the question on everybody's lips... (Score:2)
Plugging the "arbitrary code" hole? (Score:3, Interesting)
Perhaps machines need a more secure memory management scheme (such as an execute disable bit [intel.com] or Data Execution Prevention [microsoft.com]).
Yes, malware could still crash an application or machine (to the extent that the system has inadequate input checking and nongraceful failure modes) but arbitrary code execution wouldn't be possible.
Why don't people use these concepts to plug a vast range of vulnerabilities?
ummm.. they already do (Score:5, Insightful)
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.
This is just a THEORY but... (Score:2)
Okay I'm kidding... really... go look at the source code or something.
Re:This is just a THEORY but... (Score:2)
It's actually placed there by the RAND Corp., in conjunction with the Saucer People, under the supervision of the Reverse Vampires, who are...
Always remember: a Simpsons quote a day, keeps the doctor away!
Queue Linux Defense Responses! (Score:3, Funny)
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!
Re:Queue Linux Defense Responses! (Score:2)
This isn't Windows, you don't have to have KDE installed, and if you have KDE installed you don't have to have KHTML installed. Most Linux users this doesn't apply to, since the biggest distributions use Gnome anyway. In fact most vulnerabilities simply don't apply to an average Linux user - even the vulnerabilities in the Kernel - because they're to do with software not installed on their system.
Re:Queue Linux Defense Responses! (Score:3, Interesting)
Linux distro = command interpreter (login shell) + kernel (linux itself) + gui (x11 & window manager or desktop)
In order to compare Windows an
Re:Queue Linux Defense Responses! (Score:2)
Re:Queue Linux Defense Responses! (Score:2)
Just goes to show... (Score:3, Insightful)
I wouldn't call it clean (Score:2)
Re:I wouldn't call it clean (Score:2)
Re:I wouldn't call it clean (Score:3, Informative)
Code used by safari? (Score:2)
Anm
Re:KJS is also used by Apple in Safari (Score:5, Insightful)
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 ar
Re:KJS is also used by Apple in Safari (Score:3, Insightful)
Re:Bullet-proof JS (Score:2)
If developers do not find the leaks attackers will also not find them. When leaks are found they are quickly fixed. So no problem.
The real question is how many leaks are left.
Re:KDE Pros/cons (Score:2)
Also you can have GTK use Qt as the rendering engine via gtk-qt, which makes running Gnome apps under KDE a bit more pleasant; I dont know if it also works vice versa.