Slashdot Mirror

← Back to Stories (view on slashdot.org)

KDE Heap Overflow Vulnerability Found

Posted by CowboyNeal on 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."

52 of 233 comments (clear)

  1. This is why I use Windows by Anonymous Coward · · Score: 3, Funny

    Microsoft would never tie a web browser into the operating system... err, wait.

    1. Re:This is why I use Windows by Anonymous Coward · · 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.

    2. Re:This is why I use Windows by JabberWokky · · Score: 4, Insightful
      The main difference is that Microsoft often takes weeks or months to release patches, all the while trying to downplay the significance of the bug. With this, the patch was available almost immediately, and within hours, updates were packaged, tested and in distro repositories (I just woke up, and Kubuntu is happily patching itself).

      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
    3. Re:This is why I use Windows by Anonymous Coward · · Score: 4, Informative

      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.

    4. Re:This is why I use Windows by jc42 · · Score: 2, Informative

      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.
    5. Re:This is why I use Windows by cyber-vandal · · Score: 2, Informative

      Except that you can very easily replace KDE with another windowing system, or *gasp* turn it off altogether.

    6. Re:This is why I use Windows by G-Licious! · · Score: 2, Insightful

      Unfortunately, this is the downside to modern component-based strategies - it's not a Microsoft-specific problem.

      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.

    7. Re:This is why I use Windows by Anonymous Coward · · Score: 2, Interesting
      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.)

      I'm speechless. I'm trying to find a polite, non-patronising, way of answering this.

      FYI: few, if any, CPUs have an opcode called "SC". There are various CPUs with instructions I'd take to be an equivalent of what you're describing, such as TRAP on the 68000, but SC? Where did you get that one from?

      What you're describing is not an operating system but a kernel, and many kernels use regular subroutine calls rather than "SC" equivalents to get into them. If your definition of "operating system" were valid, many things we call operating systems today wouldn't be. The Amiga, for instance, far from having a revolutionary operating system as described by most of its enthusiasts, never came with one. (You called exec, the kernel, though standard subroutine calls, not through the TRAP instruction.)

      If your definition were true, it would also mean that the word "kernel" is redundant. Few operating systems require special access to any function but the kernel. Microkernels would be unusable operating systems, not tiny components of full operating systems.

      A modern operating system consists of a range of subsystems, some in the kernel, some outside of it. The goal of an operating system is to manage the resources of a computer, which includes providing a console for the user (modern systems use GUIs) to start and stop and interact with running programs, allocating memory and time to running programs, providing necessary intercommunication systems with different programs and subsystems, etc. Basing a definition of "operating system" in a 1950s definition that appears to be synomynous with kernel, and inaccurate to boot, strikes me as bizarre.

    8. Re:This is why I use Windows by JabberWokky · · Score: 4, Informative
      I take it you are not a software developer/engineer, because if you were professionally for any entity of size or one that deals with SENSITIVE data? You'd know why those slowdowns exist... for many reasons, some I did not even hit on, above...

      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
    9. Re:This is why I use Windows by NutscrapeSucks · · Score: 2, Informative

      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.
    10. Re:This is why I use Windows by BuR4N · · Score: 2, Insightful

      "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
    11. Re:This is why I use Windows by poeidon1 · · Score: 2, Insightful

      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
    12. Re:This is why I use Windows by cnettel · · Score: 3, Insightful
      *sigh*

      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.

    13. Re:This is why I use Windows by TheNetAvenger · · Score: 3, Insightful

      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.

    14. Re:This is why I use Windows by Thundersnatch · · Score: 2, Informative
      ...and new accounts are created with superuser access by default.

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

  2. Variable names? by ajiva · · Score: 3, Insightful

    Who has variables named "vvvv" and "uuuuu"? At least make them somewhat useful, even if they are temporary variables.

  3. Right thats it! by trash+eighty · · Score: 5, Funny

    I'm going back to Windows!!!

    1. Re:Right thats it! by Anonymous Coward · · Score: 2, Funny

      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!

  4. Re:KJS is also used by Apple in Safari by Anonymous Coward · · Score: 5, Insightful

    The obvious question is - does the same bug exists in the KJS-derived Safari Javascript?

  5. Malicious hackers around the world... by Anonymous Coward · · Score: 5, Interesting

    ...yawn and pay no heed. Have any vulnerabilities for Konqueror ever actually resulted in exploits in the wild?

  6. Ubuntu patched already by Richard+W.M.+Jones · · Score: 5, Informative
    The patch for this was waiting on my Ubuntu desktop for installation when I got up this morning ...

    Rich.

    --
    libguestfs - tools for accessing and modifying virtual machine disk images
    1. Re:Ubuntu patched already by Anonymous Coward · · Score: 2, Interesting

      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.

  7. And now the obligatory... by Billosaur · · Score: 3, Insightful
    ...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...

    --
    GetOuttaMySpace - The Anti-Social Network
    1. Re:And now the obligatory... by Tim+C · · Score: 4, Insightful

      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.

      --
      It's official. Most of you are morons.
  8. About the Patch by robbyjo · · Score: 2, 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.

    --

    --
    Error 500: Internal sig error
    1. Re:About the Patch by porneL · · Score: 2, Interesting

      Hey! But I have Konqueror compiled for OS X. Now I'll have to recompile everything using my half-speed single-core G5 :(

  9. Re:KJS is also used by Apple in Safari by Anonymous Coward · · Score: 2, Informative

    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.

  10. Re:KJS is also used by Apple in Safari by Mattintosh · · Score: 2, Insightful

    Probably, but expect silence until Tuesday, when a patch will suddenly appear to bump Safari to 2.0.4.

  11. Rather incompetent by velco · · Score: 4, Interesting

    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

    1. Re:Rather incompetent by m50d · · Score: 2, Interesting

      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.

      --
      I am trolling
    2. Re:Rather incompetent by Dj+Offset · · Score: 2, Informative
      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 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.

  12. And the question on everybody's lips... by Xyde · · Score: 2, Insightful

    Does this affect Safari?

  13. Plugging the "arbitrary code" hole? by G4from128k · · Score: 2, Interesting

    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 or Data Execution Prevention).

    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?

    --
    Two wrongs don't make a right, but three lefts do.
    1. Re:Plugging the "arbitrary code" hole? by spitzak · · Score: 2, Informative

      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.

  14. Re:Arbitrary code with what privileges? by undeadly · · Score: 3, Insightful
    Is it going to be able to run with root privileges or just as a user?

    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.

  15. Queue Linux Defense Responses! by Anonymous Coward · · Score: 3, Funny

    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! :)

    1. Re:Queue Linux Defense Responses! by laffer1 · · Score: 2, Interesting

      Yes, but most linux distros ship with an X11 desktop environment. I can't think of too many besides gentoo that don't come with either KDE or gnome. Its also a very common add-on to distros without one or bsd's that run in desktop mode. And if you think about it, running a gui is a comparable was to look at windows. Windows = command interpreter + kernel + gui
      Linux distro = command interpreter (login shell) + kernel (linux itself) + gui (x11 & window manager or desktop)

      In order to compare Windows and Linux from a desktop point of view, you must look at the whole package. An end user would.

      Of course you are right that its not a linux specific issue. It can affect linux distros, *bsd, or UNIX distros that include or have the environment installed. But, think of it this way.. it can affect all *nix installs that have KDE which is very popular.

      As for his list, I found it quite amusing. I'm not MS fanboy, but you have to admit that many people have this perception that MS has a lot more bugs. I think Microsoft screws up patching quite a bit. If you look at original vulnerabilities though, its no different than a full linux distro with gui (redhat for example), or OSX. I've had to patch my mac and freebsd machine just as much as my windows box lately. (freebsd has has 5 holes in the core os recently plus any ports like firefox or KDE)

      I think its about time to realize that open source has grown up. It has just as many holes as closed source software. People are starting to find them more often. Look at firefox. I no longer use firefox because i feel safer. I use it because I like the UI. The difference is that most OSS holes don't cause code to run as root since *nix developers are more likely to run code as a user vs system (root).

      Security minded people often forget that programmers are NOT taught about security in college and its not like the local BN has a book called "learn to code safely and check your input." There are a few security books out there, but they often are not written for everyday programmers. In college, I was taught what a buffer overflow is and told to check input. I've never been given an example besides a simple x > 2 check example in any class. Once a professor mentioned regular expressions, but didn't describe what they did. Its quite sad. I don't see how we can expect closed or open source developers to code securely if we don't teach them.

      --
      MidnightBSD: The BSD for Everyone
    2. Re:Queue Linux Defense Responses! by trparky · · Score: 2

      I vouch for you on that one. I took a class in Java Programming, nothing was ever mentioned about making sure that input was correct. Now, being a person who knows that vulnerablities can exist, I mentioned that you have to be careful when handling user input, but the professor just pushed it off and said that we would talk about that later. Later never came.

  16. Just goes to show... by m50d · · Score: 2, Insightful

    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
  17. same goes for gentoo by Anonymous Coward · · Score: 2, Informative

    kdelibs-3.4.3-r1 and kdelibs-3.5.0-r2 were both released yesterday with the former being marked stable on most archs.

  18. Yes people, look at this by rbarreira · · Score: 3, Informative

    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
  19. Meaningful names by dustmite · · Score: 3, 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.)

  20. Also by dustmite · · Score: 4, 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.

  21. Many (slow) eyeballs do what now? by general_re · · Score: 2, Insightful
    ...the fact remains that by the time we even heard about, there was already a fix.

    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.
  22. Checking malloc() is an obsolete practice by typical · · Score: 4, Insightful

    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.
    1. Re:Checking malloc() is an obsolete practice by joe_bruin · · Score: 2, Insightful

      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 is difficult. Don't confuse the two. Your job as a programmer is not to make your life easy, it's to write programs that function correctly. Handling memory errors correctly (say, not losing the user's states and corrupting their current working file due to allocation error) is part of the program's role. Advice like this leads to the type of apps that die mysteriously for no apparent reason, leaving no trace or debug message of what went wrong.

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

      No. I test most. I have good confidence in my coding skills for the rest. Yes, there are bugs, that is inevitable. But handling most error cases correctly (obviously I try for total coverage) is better than handling none of them.

      * 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?

      Well, in my embedded systems, I do. On more conventional machines, not really. But I do know that any well written code will not allocate excessively-large objects on the stack and avoid recursion. My code will never use more than a few kilobytes of stack space (or hundreds, in embedded situaitons), and if that much is not availabe, the program never had a chance of working correctly.

      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.

      This is an incorrect assertion and a terrible programming practice. Imaging your Linux box is running 1000 processes, 1 sshd and 999 apache instances. If traffic spikes up, and the apaches start consuming more memory, the system may not have enough to give them, and they may gracefully handle it. But if sshd was coded using your standards, it would crash if someone tried to initiate a connection because it did not check its malloc return. I think we can all agree that under no circumstances should increased memory use by apache (not a bug) cause sshd to crash.

      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.

      And how exactly does the GIMP know how much memory is available to it at any time? It may be running on a box with 16 megs of RAM, or 16 gigs. The system may have memory allocated to other things right now that was available five seconds ago. I'd like to see portable code that can predict when nontrivial resource allocation will fail.

      All in all, this kind of programming leads to the worst kind of software. Code with no regard for memory utilization. Code that does not know if realloc worked and goes on silently corrupting memory until it fails later down the line. Code that leads to memory leaks, buffer overflows, and denial of service attacks due to its disregard for error conditions. I hope that I shall never encounter your code in my lifetime.

      --
      Any (nontrivial) program will be buggy.

  23. IIS in the latest version does not by badriram · · Score: 3, Informative

    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.

  24. Did you look at the ECMA standard? by Grendel+Drago · · Score: 5, Informative

    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
  25. ummm.. they already do by shis-ka-bob · · Score: 4, Insightful

    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
  26. Re:I wouldn't call it clean by Jesus_666 · · Score: 2, Informative

    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)
  27. Mod down by brunes69 · · Score: 2, Insightful

    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.

  28. Safari *not* affected by ansodyuhuf · · 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 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.