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."
You, sir, need to be hit with the humor stick.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
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.
--
Error 500: Internal sig error
More Safari/KJS info. I took a look at the Apple code. It appears the URI encode/decode function were completely rewritten and have no resemblance to the KDE/KJS original functions.
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.
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.
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.
The "operating system" provides a runtime environment for application software. ... This is something that technically clueless Linux users invented.
... ;-)
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
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Except that you can very easily replace KDE with another windowing system, or *gasp* turn it off altogether.
kdelibs-3.4.3-r1 and kdelibs-3.5.0-r2 were both released yesterday with the former being marked stable on most archs.
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
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.
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
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
The idea that things like runtime libraries are part of the OS shows a profound lack of understanding of computer architecture.
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").
Whenever I hear the word 'Innovation', I reach for my pistol.
No-execute does not even stop normal buffer overflows, though it makes them harder. You can still overwrite the return address on the stack, or another pointer to code.
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.
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.
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
As was pointed out in previous posts, this code comes from the ECMA reference implementation and there are valid reasons for variable names like "uuuuu" and "vvvv": The length of the string indicates the number of bits stored in the variable and the letter indicates where the contents of the variable go when two variables are concatenated.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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 that the vulnerable functions are: encodeURI, decodeURI.
Now you can download JavaScriptCore from http://www.opensource.apple.com/darwinsource/10.4. 4.ppc/. 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.
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...