Forgot your password?
typodupeerror
KDE GUI Security

KDE Heap Overflow Vulnerability Found 233

Posted by CowboyNeal
from the holes-in-the-dike dept.
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 discussion has been archived. No new comments can be posted.

KDE Heap Overflow Vulnerability Found

Comments Filter:
  • by Anonymous Coward on Saturday January 21, 2006 @11:36AM (#14526298)
    Microsoft would never tie a web browser into the operating system... err, wait.
    • While i realize you were trying to be funny, KDE doesnt tie the browser into any OS. its tied into the DE.. Quite a difference there. ( still potentially dangerous, as the DE has a lot of rights at the system level, but it is different )
      • I'm no Windows fan, but technically, the same is true of IE. It's tied into the desktop environment the same way KHTML is. The two big differences (which help KDE) are (a) most users don't run as root in KDE, while most users run as root (Administrator) in Windows, and (b) KDE isn't the only DE for Linux, while Explorer is the only DE in Windows. That latter point is why people tend to think that IE is tied into the OS. It's not; it's tied into the only DE in Windows. Overall, not much different, but s
        • by nurb432 (527695)
          With current versions of windows the DE ( and thus IE ) is a bit lower level, as many of its libraries are required for the OS to actually function. True, there are some kernel level items that wont need DE/IE, but it doesnt leave you with much..

          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.
  • Variable names? (Score:4, Insightful)

    by ajiva (156759) on Saturday January 21, 2006 @11:40AM (#14526317)
    Who has variables named "vvvv" and "uuuuu"? At least make them somewhat useful, even if they are temporary variables.
  • by trash eighty (457611) on Saturday January 21, 2006 @11:43AM (#14526325) Homepage
    I'm going back to Windows!!!
    • by Anonymous Coward
      I *know*! This is just another example of how shoddy Windows is, just another buffer overflow in a long line of security travesties that is Microsoft... wait, this is KDE?

      *looks at his Kubuntu install*

      Uh... clearly this patching shows the inherent superiority of Open Source!
  • by Anonymous Coward on Saturday January 21, 2006 @11:53AM (#14526367)
    ...yawn and pay no heed. Have any vulnerabilities for Konqueror ever actually resulted in exploits in the wild?
  • by Richard W.M. Jones (591125) <rich.annexia@org> on Saturday January 21, 2006 @11:56AM (#14526387) Homepage
    The patch for this [ubuntu-linux.com] was waiting on my Ubuntu desktop for installation when I got up this morning ...

    Rich.

    • by Anonymous Coward
      I'm not sure if "patch" is the correct word, since it basically re-downloads all of the kdelibs and the necessary data which weigh in at 10s of megabytes.
      Happily, the debian devels are said to be looking into a way of supplying binary diffs/ deltas of update .debs eventually, which will be nice. Shame it's taken such an incredibly long time, though - MS has had the technology for aeons.
    • same goes for gentoo (Score:2, Informative)

      by Anonymous Coward
      kdelibs-3.4.3-r1 and kdelibs-3.5.0-r2 were both released yesterday with the former being marked stable on most archs.
  • by Billosaur (927319) * <wgrother AT optonline DOT net> on Saturday January 21, 2006 @11:58AM (#14526394) Journal
    ...nothing to see here... move along...

    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...

    • While you have a point, this patch obviously didn't get too much review -- decbuf is reallocated using realloc, and as far as I can tell the value is never checked before being dereferenced to make sure the allocation didn't fail. So this patch needs another patch, and it is the kind of thing that 'the other operating systems' wouldn't be able to get away with.
    • by Tim C (15259) on Saturday January 21, 2006 @12:35PM (#14526567)
      There are patches already available. Fix it. Move on.

      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.
      • SuSE already have patches for this. I would imagine all the other major distros do, too.

        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.
      • > 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...

        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.
    • I don't *like* patching software. It leaves thousands of CDs and DVDs out there with ticking time bombs, or hunks of rock software that are unsafe to install, without then connecting to highspeed Internet, and downloading the fix. I found Ubuntu's auto-update to be pretty easy to use, but it's still a pain, and forget the ease if you're on dialup.

      Stupid crackers...
  • About the Patch (Score:3, Informative)

    by robbyjo (315601) on Saturday January 21, 2006 @12:00PM (#14526403) Homepage

    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.

  • Is it going to be able to run with root privileges or just as a user?
  • Rather incompetent (Score:4, Interesting)

    by velco (521660) on Saturday January 21, 2006 @12:03PM (#14526420)
    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
    • by m50d (797211)
      KDE began in a time when STL support in many C++ compilers wasn't up to much, so for cross-platform capability (always a design goal) they couldn't really rely on it. Not sure whether that has anything to do with this.
    • by Dj Offset (260006)
      And the proposed patch leaks if realloc fails and does not check the return value of realloc. *sigh*

      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

      • by typical (886006) on Saturday January 21, 2006 @02:55PM (#14527363) Journal
        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.
        • This is the worst advice ever posted on Slashdot. Congratulations. The scary part is that it got modded "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)

      by brunes69 (86786)
      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
  • by Xyde (415798) <slashdot@[ ]rrr.net ['pur' in gap]> on Saturday January 21, 2006 @12:03PM (#14526422)
    Does this affect Safari?
    • And, if it does, does that mean Dashboard widgets are affected too? Apple uses WebCore to render those, too. See, Microsoft isn't the only one guilty of that sort of sin. Combine it with the vulnerability they had at release, where a website could force feed you widget, and you have problems.
  • by G4from128k (686170) on Saturday January 21, 2006 @12:27PM (#14526525)
    So many vulnerabilities seem to involve writing past the extents of a data structure (stack, heap, buffer, etc.). But how does this lead to the ability to execute arbitrary code? It would seem that the system must lack an ability to clearly segment memory in the distinct data spaces or to distinguish between data and code.

    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?
    • by shis-ka-bob (595298) on Saturday January 21, 2006 @05:03PM (#14528011)
      Wikipedia has a few articles that might interest you. Please look at Stack Smashing Protection [wikipedia.org] 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.
  • ...what if it was actually a backdoor placed there intentionally by secret society agents?

    Okay I'm kidding... really... go look at the source code or something.
    • ...what if it was actually a backdoor placed there intentionally by secret society agents?

      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!

  • by Anonymous Coward on Saturday January 21, 2006 @12:35PM (#14526568)
    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! :)

    • Response 5: Doesn't apply to me.

      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.
  • by m50d (797211) on Saturday January 21, 2006 @01:09PM (#14526759) Homepage Journal
    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.
    • If you actually look at the code you'll see plenty of bad coding practices. vvvv and uuuuu as variable names? malloc and free in C++ code? Cut-n-paste code where a loop ought to be? It looks like something that I might find on the "Daily WTF" site.
      • That's why I said relatively clean. Compare to most projects and you'll see what I mean.
      • 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.
  • I know Safari's HTML enginge was derived from KHTML. Does it also use the same Javascript engine?

    Anm

It's time to boot, do your boot ROMs know where your disk controllers are?

Working...