KDE Heap Overflow Vulnerability Found

This is why I use Windows by Anonymous Coward · 2006-01-21 03:36 · Score: 3, Funny

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

Re:This is why I use Windows by Anonymous Coward · 2006-01-21 03:44 · Score: 1, Informative

You, sir, need to be hit with the humor stick.
Re:This is why I use Windows by Anonymous Coward · 2006-01-21 03:55 · 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 by JabberWokky · 2006-01-21 04:16 · 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
Re:This is why I use Windows by Anonymous Coward · 2006-01-21 04:24 · 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.
Re:This is why I use Windows by NutscrapeSucks · 2006-01-21 04:39 · Score: 1

> not only is explorer the component for rendering HTML, but it also renders the desktop, taskbar, start menu, etc.

There was an updated 'common controls' DLL that originally came with IE4, but that's different from rendering the start menu/taskbar in HTML.

--
Whenever I hear the word 'Innovation', I reach for my pistol.
Re:This is why I use Windows by jc42 · 2006-01-21 04:42 · 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.
Re:This is why I use Windows by cyber-vandal · 2006-01-21 04:45 · Score: 2, Informative

Except that you can very easily replace KDE with another windowing system, or *gasp* turn it off altogether.
Re:This is why I use Windows by aaronl · 2006-01-21 04:50 · Score: 1, Insightful

Unfortunately, you're very correct, and you see it throughout the popular OSS projects.

The projects from Mozilla are far from "finished", but they add features instead of fixing bugs. We wind up with a somewhat slow UI, a huge memory footprint, and random crashes. The OpenOffice people are too busy needlessly throwing in features and coding Java into a C++ program instead of finishish the version. We wind up with a slow UI, very slow startup time, a huge memory footprint, and reliance on C libraries, C++ libraries, *and* the Java runtime.

I still use things like Firefox and OpenOffice, because they're still the best ones out there, but I have no devotion to them. When the devs stop playing happy little games throwing in a bunch of code from their favorite language of the year, or building an IRC client in, or messing about with plugin interfaces well after version 1.0, and just finish what they have first, then I'll be very happy. Instead we have tons of software that are *almost* done.

Exactly what you mentioned about the Linux kernel doing this has a lot of people unhappy. On the few Linux server I keep around, I use Slackware and 2.4.x kernels. I don't want the machines to crash, so I don't trust 2.6.x. They don't need new features; they need stable code, and the constant feature-add game doesn't get me stable code.

What these games *have* done is get a lot of people, such as myself, to use more stable platforms. Some people choose a Linux distro like Debian. Many others just jumped over to BSD or Solaris.

So, in the end, I'm willing to run Linux on my workstation, but I try to avoid running it on my servers. I want to minimize the potential for that server to crash, and Linux isn't giving me that anymore. About two years ago, I waved goodbye to Linux, after having used it heavily since 1993.
Re:This is why I use Windows by Zarel · 2006-01-21 04:52 · Score: 1

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.
The vulnerability is in kjs, the Javascript interpreter of KHTML. Since KMail and amaroK don't really need a Javascript interpreter, the question is, is the code written badly enough that they're still vulnerable?

--
Want a high quality FOSS RTS game? Try Warzone 2100!
Re:This is why I use Windows by G-Licious! · 2006-01-21 04:56 · 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.
Re:This is why I use Windows by belg4mit · 2006-01-21 05:04 · Score: 1

Except that it is not so *tightly integrated*. I would certainly argue that this phrase could be read "near", and there are certainly plenty of other people who write of the
tight integration of explorer and the kernel. And if you don't agree, well then who's splitting hairs :-P

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?

--
Were that I say, pancakes?
Re:This is why I use Windows by Billly+Gates · 2006-01-21 05:12 · Score: 1, Insightful

In the past MS did run everything in the kernel. To this day SQL server's indexing engine is kernel based, IIS, and many video code in the media player is as well. Go check the event viewer if you dont believe me? SQL 6.5 shows alot of kernel messages.

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

--
http://saveie6.com/
Re:This is why I use Windows by Anonymous Coward · 2006-01-21 05:19 · 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.
Re:This is why I use Windows by NutscrapeSucks · 2006-01-21 05:34 · Score: 1

You could, but you couldn't run KDE applications then, could you? As far as a KDE app is concerned, KDE is part of the "OS", just as GDI32 is part of the OS for a Windows app.

Microsoft made the marketing decision to make IE uninstallable. That alone doesn't make it any more or less part of the operating system.

--
Whenever I hear the word 'Innovation', I reach for my pistol.
Re:This is why I use Windows by JabberWokky · 2006-01-21 05:36 · 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
Re:This is why I use Windows by NutscrapeSucks · 2006-01-21 05:36 · 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.
Re:This is why I use Windows by BuR4N · 2006-01-21 05:37 · 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
Re:This is why I use Windows by Zontar+The+Mindless · 2006-01-21 05:42 · Score: 1

I use KDE apps in WindowMaker all the time.

What was your point again?

--
Il n'y a pas de Planet B.
Re:This is why I use Windows by poeidon1 · 2006-01-21 06:23 · 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
Re:This is why I use Windows by Taevin · 2006-01-21 06:33 · Score: 1

I can't afford to have a hastily written patch bring down any of my machines.

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:This is why I use Windows by Anonymous Coward · 2006-01-21 06:34 · Score: 1, Interesting

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

I suggest you look into the work being done on KDE 4. It will include something very much like Apple's Dashboard and Microsoft's Active Desktop. Implemented with KHTML and KJS.

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.

The same is true in Linux. Ever heard of a little thing called "glibc"?

Seriously, there's nothing remarkable about Microsoft's code reuse. Everybody does it. It's a good thing.
Re:This is why I use Windows by cnettel · 2006-01-21 06:48 · 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.
Re:This is why I use Windows by NutscrapeSucks · 2006-01-21 06:50 · Score: 1

> What was your point again?

That most Linux users don't know anything about computers.

--
Whenever I hear the word 'Innovation', I reach for my pistol.
Re:This is why I use Windows by Mercano · 2006-01-21 06:57 · Score: 1

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

--
#include <signature.h>
Re:This is why I use Windows by undeadly · 2006-01-21 07:14 · Score: 1

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.
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 quite a few of then does not even have VGA available (the Sun Netra serie, for instance, where even power on/off can be done from serial console).
Re:This is why I use Windows by JabberWokky · 2006-01-21 08:12 · Score: 1

patches issued in only hours probably didn't get tested well, or by many testers... with many mixes of softwares
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. Perception, not reality, which is the original question.
--
Evan

--
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Re:This is why I use Windows by teprrr · 2006-01-21 08:32 · Score: 1

IIRC amaroK strips out JS code and many other things before loading lyrics.
Re:This is why I use Windows by baadger · 2006-01-21 08:45 · Score: 1

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

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 most people don't need...
Re:This is why I use Windows by dhasenan · 2006-01-21 09:38 · Score: 1

"Maksim Orlovich discovered an incorrect bounds check 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."

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, then there would be trouble. In that case, the function in question should add an additional error check, and the full fix would be rolled out in the next release.

As for WMF stuff, that's just a failed graphics format with no reason to be included in Windows at all.
Re:This is why I use Windows by IntergalacticWalrus · 2006-01-21 11:57 · Score: 1

Good to see the mods are doing their job right, modding down people who say things that are true.
Re:This is why I use Windows by wfberg · 2006-01-21 12:02 · Score: 1

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.

The recent WMF exploit that attacked the thumbnailing process however...

--
SCO employee? Check out the bounty
Re:This is why I use Windows by TheNetAvenger · 2006-01-21 13:42 · 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.
Re:This is why I use Windows by Schraegstrichpunkt · 2006-01-21 14:09 · Score: 1

No, KDE/GNU/Linux. It's KDE running on top of GNU/Linux, not the reverse.

--
http://outcampaign.org/
Re:This is why I use Windows by aaronl · 2006-01-21 19:56 · Score: 1

I have had OpenOffice crash quite a bit when trying to read MS formats. While 2.0 has much better luck parsing those formats, it also crashes occasionally while doing so. This is especially frequent when trying to read MS Access databases into OOo Base.

I prefer using Linux to Windows on a desktop, too. The system tends to be more stable, but the applications are not. This is the case for quite a few OSS programs, such as those I mentioned. Firefox has a lot of issues with being left running, for example, which is much improved in 1.5. I run Ubuntu on my own workstation, because I get all the benefits of running a UNIX work-alike, but I also get excellent hardware support, and it *just works*. The only annoyances that I've had with it that I didn't have on Windows have been dual-monitor support, encumbered video/audio codec support, and VMWare.

As far as reasons to go to newer kernel releases, there are reasons for this. I try to keep things on the 2.4 kernel, for stability. However, as mentioned in the other response to you, there is occasional hardware that isn't supported, or supported as well, in the 2.4.x kernel as in the 2.6.x kernels. Also, depending on what you're doing, sometimes you are forced to use later released because of applications. An example of this is WebGUI... the latest release requires Apache 2, mod_perl 2, and they recommend using MySQL 5.

As I said, my reasons for switching off of Linux on my servers, and over to BSD, was stability. I've found the BSDs to just be more trusthworthy than Linux. What initially pulled me over to that side was actually running an OpenBSD router. After seeing BSD pf, I have no desire to ever touch Linux's iptables again. The more I worked with OpenBSD, the more I liked it. I liked the management capabilities from things like the ports tree so very much that I always get annoyed when going to work on my Linux servers. OpenBSD is too restrictive for some software, so I then tried out FreeBSD, and that was even nicer to work with.

As for your comment about things being stable two years ago... I said I switched *away* two years ago, because of stability issues. I don't find that it's improved over the intervening two years. I *could* run old versions of the kernel, but then I wouldn't have the security fixes. I started to get quite upset when the kernel maintainers started making big changes that affected stability in the normal maintanance cycle of the kernel. Things like messing with the scheduler, VFS, VM, etc. I don't like the idea of trusting something when going from 2.4.5 to 2.4.6 might mean that the virtual memory subsystem was replaced with a new design, and could cause data corruption. That mean that the patch release that gives me the security fix might also include a whole new critical subsystem.
Re:This is why I use Windows by man_of_mr_e · 2006-01-21 21:44 · Score: 1

You couldn't be more wrong. You've fallen for that hype. This bug is a month old, and has been know, but kept secret by the KDE team while they fixed it. Check the CVE date if you don't believe me.

--
If you need web hosting, you could do worse than here
Re:This is why I use Windows by NetRAVEN5000 · 2006-01-22 05:06 · Score: 1

It's not that hard to test KDE's JavaScript implementation - why should it take more than a few hours? Just create a test script that checks and makes sure all the functions are working properly (which is probably the same way they tested it in the first place, so all they have to do is run the script again).

--
www.linuxpenguin.net
Re:This is why I use Windows by NetRAVEN5000 · 2006-01-22 05:14 · Score: 1

How do you know it's a month old and has been known? Who told you about this bug?
Just because it's not widely publicized doesn't mean they "kept it secret". MS doesn't use MSNBC for telling everyone about new bugfixes. We /.ers know about these problems only because we visit /. where people often bring them to attention - the developers don't go out and notify everyone they know about new bugs/bugfixes.
Plus, by MS's terms, this would be seen as a "low-risk, low-priority" bug and therefore might not ever be fixed (at least not until someone exploits it).

--
www.linuxpenguin.net
Re:This is why I use Windows by NetRAVEN5000 · 2006-01-22 05:19 · Score: 1

Because that would actually make sense. You can't ridicule open-source programmers for what they do right.

--
www.linuxpenguin.net
Re:This is why I use Windows by alx5000 · 2006-01-22 15:02 · Score: 1

Oh, God, you hit the Security through Obscurity issue there!

Have you ever googled for some prolific hacker of Windoes code?

--
My 0.02 cents
Re:This is why I use Windows by Thundersnatch · 2006-01-22 15:12 · 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...
Re:This is why I use Windows by alx5000 · 2006-01-22 15:16 · Score: 1

Everybody here forgot that KDE is made with the help of mainly unpaid and anonymous contributors? Didn't anyone take account of the fact that KDE e.V. is more like a charity that like an enterprise? Did anyone know that the amount of money directly collected by either the kjs or the konqueror teams from selling their products amounts to zero?

I'm sick of this Windows/KDE comparations (not the mention the Windows/(GNU/Linux) ones). You Windows weenies will have a point against gratis and free software as soon as M$ stops charging for their products and support.

Besides, if you don't believe whether the patch solves or not the problem you can go and get a diff yourselves. Easy, huh? Try that somewhere else.

--
My 0.02 cents

Bullet-proof JS by Anonymous Coward · 2006-01-21 03:38 · Score: 1, Interesting

Man! It seems that no one can build a bullet-proof JS interpreter

Re:Bullet-proof JS by Elektroschock · 2006-01-21 04:19 · Score: 1

There is nothing wrong about this news.

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:Bullet-proof JS by Anonymous Coward · 2006-01-21 05:26 · Score: 1, Insightful

First : Developers almost never search for those leaks which mean attackers find them before developers.
Second : I hate wasting my life patching the OS on my computer.
Re:Bullet-proof JS by mageofchrisz · 2006-01-21 10:11 · Score: 1

Eh? What about the Rhino engine? Perhaps it's just because Rhino isn't as well known as SpiderMonkey or KJS, but I have yet to see any exploits be pointed out on Rhino, and in fact in some instances Rhino outperforming SpiderMonkey.

Variable names? by ajiva · 2006-01-21 03:40 · Score: 3, Insightful

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

Re:Variable names? by Anonymous Coward · 2006-01-21 05:51 · Score: 1, Insightful

Well, glancing over the code, I think that the variables are u, v, w, x, y and z and that the number of letters indicates the number of binary digits. Ie:

00261 unsigned long xx = (octets[2] >> 4) & 0x03;
00262 unsigned long yyyy = octets[2] & 0x0F;
00263 unsigned long zzzzzz = octets[3] & 0x3F;

xx is two bits, yyyy four bits and zzzzzz six bits.

So it is not totally stupid...

Right thats it! by trash+eighty · 2006-01-21 03:43 · Score: 5, Funny

I'm going back to Windows!!!

Re:Right thats it! by Anonymous Coward · 2006-01-21 03:47 · 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!
Re:Right thats it! by Zerathdune · 2006-01-21 04:30 · Score: 1

Uh... clearly this patching shows the inherent superiority of Open Source!
you say this in jest, and while I agree that there are people with this atitude, and it's annoying, the fact remains that by the time we even heard about, there was already a fix. any software is going to have issues, and if this was microsoft software, I might start to think they're considering coming through on that promise about security that gates made so long ago; this kind of response time is pretty impressive.

--
No single raindrop believes that it is responsible for the storm.

This is interesting... by Anonymous Coward · 2006-01-21 03:46 · Score: 1, Interesting

.. because KDE is supposedly developed in the so-called "modern C++" using STL. Perhaps OSS developers should look into using code analysis tools to weed out any unsafe techniques.

Re:KJS is also used by Apple in Safari by Anonymous Coward · 2006-01-21 03:48 · Score: 5, Insightful

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

how to apply? by Anonymous Coward · 2006-01-21 03:52 · Score: 1, Funny

do i just make the .diff file executable and put a ./ in front when typing out the name of the file in a root shell???

Malicious hackers around the world... by Anonymous Coward · 2006-01-21 03:53 · Score: 5, Interesting

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

Re:Malicious hackers around the world... by BrokenHalo · 2006-01-21 04:10 · Score: 1

Does anybody even use Konqueror? Can't say I personally know anyone who does...
Re:Malicious hackers around the world... by JamesTRexx · 2006-01-21 04:38 · Score: 1

I use it all the time with one or two exceptions, for which I use Firefox.
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. :-)

--
home
Re:Malicious hackers around the world... by DeafByBeheading · 2006-01-21 04:51 · Score: 1

Exactly. It hasn't been exploited in the wild because there are no uses of Konqueror in the wild. And they say that security through obsurity is a bad idea... ...

I keed, I keed.

--
Telltale Games: Bone, Sam and Max
Re:Malicious hackers around the world... by PeterBrett · 2006-01-21 06:15 · Score: 1

I really like Konqueror -- it integrates far better with my other applications (including non-KDE apps) than any other browser I've tried on Linux.

I use Konqueror all the time, apart from really broken websites which I use Firefox for, or avoid.

--
Pirate Party UK
Re:Malicious hackers around the world... by IntergalacticWalrus · 2006-01-21 12:01 · Score: 1

Except for Gmail I use Konq all the time. I find the Linux version of Firefox to be ugly and slow (mostly due to it using GTK) and lacking any sort of integration with my KDE desktop.

Ubuntu patched already by Richard+W.M.+Jones · 2006-01-21 03:56 · 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

Re:Ubuntu patched already by Anonymous Coward · 2006-01-21 04:14 · 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.
Re:Ubuntu patched already by icydog · 2006-01-21 10:30 · Score: 1

My Fedora system was patched around noon yesterday, a day before this article came out.
Re:Ubuntu patched already by shutdown+-p+now · 2006-01-21 18:26 · Score: 1

So does Linux, with xdelta. Many Gentoo users have had it enabled for ages.

And now the obligatory... by Billosaur · 2006-01-21 03:58 · 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

Re:And now the obligatory... by dioscaido · 2006-01-21 04:24 · Score: 1, Interesting

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.
Re:And now the obligatory... by Tim+C · 2006-01-21 04:35 · 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.
Re:And now the obligatory... by Zontar+The+Mindless · 2006-01-21 05:32 · Score: 1

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.

--
Il n'y a pas de Planet B.
Re:And now the obligatory... by saskboy · 2006-01-21 05:35 · Score: 1

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

--
Saskboy's blog is good. 9 out of 10 dentists agree.
Re:And now the obligatory... by Tim+C · 2006-01-21 12:15 · Score: 1

Am I wrong for thinking that most Linux users use distributions?

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

Once Redhat, or Mandriva, or whoever's distro you use releases a patch via their update service, then you can just grab it and install it. Until then, this is meaningless for anyone who doesn't know enough about computers to be compiling stuff from source. Like I said, that's fine for me (I have 7 years commercial programming experience on top of all the hobbyist stuff before that), but utterly meaningless for "normal" users; for them, this is still unpatched. Once the distros release patches, then it's patched.

--
It's official. Most of you are morons.
Re:And now the obligatory... by Waffle+Iron · 2006-01-21 13:46 · Score: 1

My Fedora system downloaded and installed *binary* patches for this problem last night. Just because this article mentions source patches doesn't necessarily mean that binary patches aren't available.
Re:And now the obligatory... by Urban+Garlic · 2006-01-21 14:17 · Score: 1

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

--
2*3*3*3*3*11*251
Re:And now the obligatory... by lasindi · 2006-01-21 14:31 · Score: 1

that's fine for me (I have 7 years commercial programming experience on top of all the hobbyist stuff before that), but utterly meaningless for "normal" users; for them, this is still unpatched. Once the distros release patches, then it's patched.

Yes, but that's a moot point. The distros released patches already (before the story even hit Slashdot). So yes, in terms of practical implementations, you're right that a patch isn't a "real" patch until distributions distribute it, but their patches came right after the source patch, so there's almost no difference.

--
I have discovered a truly remarkable proof of this theorem that this sig is too small to contain.

About the Patch by robbyjo · 2006-01-21 04:00 · 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

Re:About the Patch by porneL · 2006-01-21 05:41 · 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 :(

OS? No. by nurb432 · 2006-01-21 04:01 · Score: 1

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 )

--
---- Booth was a patriot ----

Arbitrary code with what privileges? by orzetto · 2006-01-21 04:01 · Score: 1, Insightful

Is it going to be able to run with root privileges or just as a user?

--
Victims of 9/11: <3000. Traffic in the US: >30,000/y

Re:Arbitrary code with what privileges? by undeadly · 2006-01-21 04:29 · 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.
Re:Arbitrary code with what privileges? by undeadly · 2006-01-21 05:02 · Score: 1

Liar. When was the last privilege escalation found in the Linux kernel?
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? by bcmm · 2006-01-21 05:52 · Score: 1

Well, this depends whether the bug is in the main application-level code of Konqueror, or in the kernel components they use to execute Javascript.

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.

--
# cat /dev/mem | strings | grep -i llama
Damn, my RAM is full of llamas.

Re:KJS is also used by Apple in Safari by Anonymous Coward · 2006-01-21 04:02 · 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.

Re:KJS is also used by Apple in Safari by Mattintosh · 2006-01-21 04:03 · Score: 2, Insightful

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

Rather incompetent by velco · 2006-01-21 04:03 · 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

Re:Rather incompetent by m50d · 2006-01-21 05:00 · 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
Re:Rather incompetent by elendril · 2006-01-21 05:12 · Score: 1

While checking the results of malloc and realloc is good practice, given than some OSes (like Linux, but it is configurable) almost never return NULL even if they cannot guarante memory will be available (a result of using memory overcommit), it probably won't catch any error and will not prevent a seg. fault.
Moreover, in most cases, if you do not get the memory you need, unless you have coded an alternative to perform the task (very rare), you might as well give up immediately.
Re:Rather incompetent by Dj+Offset · 2006-01-21 05:25 · 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.
Re:Rather incompetent by rbarreira · 2006-01-21 05:29 · Score: 1

Moreover, in most cases, if you do not get the memory you need, unless you have coded an alternative to perform the task (very rare), you might as well give up immediately.

Give up with a seg fault? Wouldn't it be better to give up with an error?

--

The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Re:Rather incompetent by elendril · 2006-01-21 05:42 · Score: 1

Give up with a seg fault? Wouldn't it be better to give up with an error?

Off course ! Failing immediately does not implies crashing immediately, and an error message may help a bit.

My point is that on many systems, such carefully coded error messages will be replaced by a seg. fault nevertheless. So being extra-carefull, while nice, is often overkill.
Re:Rather incompetent by stuuf · 2006-01-21 09:42 · Score: 1

Give up with a seg fault? Wouldn't it be better to give up with an error?

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?

--
Everyone is born right-handed; only the greatest overcome it

And the question on everybody's lips... by Xyde · 2006-01-21 04:03 · Score: 2, Insightful

Does this affect Safari?

Re:And the question on everybody's lips... by Mercano · 2006-01-21 07:08 · Score: 1

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.

--
#include <signature.h>

Plugging the "arbitrary code" hole? by G4from128k · 2006-01-21 04:27 · 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.

Re:Plugging the "arbitrary code" hole? by ShadowFlyP · 2006-01-21 04:37 · Score: 1

Even a no-execute bit will not prevent all of these types of a problems in C++. Classes have a pointer to the virtual function table which point to the address of the real function. Any heap-overflow could modify a classes pointer to the virtual function table to point to a different table. This table can then have a pointer to any function of your choosing, such as the "system" function.
Re:Plugging the "arbitrary code" hole? by spitzak · 2006-01-21 05:47 · 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.

This is just a THEORY but... by erroneus · 2006-01-21 04:29 · Score: 1

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

Re:This is just a THEORY but... by daikokatana · 2006-01-21 04:43 · Score: 1

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

--
http://jcsnippets.atspace.com/ - a collection of Java & C# snippets

Queue Linux Defense Responses! by Anonymous Coward · 2006-01-21 04:35 · 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! :)

Re:Queue Linux Defense Responses! by Skiron · 2006-01-21 04:44 · Score: 1

This isn't a Linux issue - this is a KDE issue.

You MS guys deliberately (or ignorantly) forget that.

Nick
Re:Queue Linux Defense Responses! by laffer1 · 2006-01-21 05:05 · 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
Re:Queue Linux Defense Responses! by trparky · 2006-01-21 05:49 · 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.
Re:Queue Linux Defense Responses! by badriram · 2006-01-21 07:26 · Score: 1

Actually the local BN nowadays does carry a a lot of secure coding books, personnally i like "Writing Secure Code", it is from MS press
Re:Queue Linux Defense Responses! by strider44 · 2006-01-21 13:40 · Score: 1

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.

Re:Crash Konqueror? by Skiron · 2006-01-21 04:46 · Score: 1

The only site that crashes my Knoq is ebay - thank god...

What about Safari? by Barto · 2006-01-21 05:08 · Score: 1

Apple's WebCore is a fork of KHTML and KJS, does anyone have information if Safari/WebCore is effected by this vulnerability?

Just goes to show... by m50d · 2006-01-21 05:09 · 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

same goes for gentoo by Anonymous Coward · 2006-01-21 05:11 · 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.

Yes people, look at this by rbarreira · 2006-01-21 05:13 · 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

Re:Yes people, look at this by pilkul · 2006-01-21 05:39 · Score: 1

Meh, there's ugly code like this in most large projects. Think how bad it must be in codebases which aren't open for everyone to see.
Re:Yes people, look at this by advocate_one · 2006-01-21 06:09 · Score: 1

did you notice this Apple copyright statement in the preamble???

00006 * Copyright (C) 2003 Apple Computer, Inc.

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....
that's most likely where this has come from... Can you imagine trying to reverse engineer the stuff to work out sensible names for it? Note the patch does NOT fix the crappy variable names, just fixes the buffer allocation

--
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Re:Yes people, look at this by Cardinal+Biggles · 2006-01-21 08:36 · Score: 1

Interesting. Could that mean that the same vuln exists in Safari?

I wouldn't call it clean by Chemisor · 2006-01-21 05:24 · Score: 1

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.

Re:I wouldn't call it clean by m50d · 2006-01-21 06:27 · Score: 1

That's why I said relatively clean. Compare to most projects and you'll see what I mean.

--
I am trolling
Re:I wouldn't call it clean by Jesus_666 · 2006-01-21 09:52 · 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)

NO! Don't put those damn checks in. They are WRONG by spitzak · 2006-01-21 05:43 · Score: 1

On modern systems it is quite impossible to print an error (in a gui box) when you run out of memory. everything tries to allocate memory.

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 the code into thinking zero is an important and useful value, and they then completely mangle the code trying to "fix" it so that zero works everywhere. I have seen this. Please avoid it! Not everything you learned in compsci-101 is correct.

You are trying to fake exceptions, and there is a reason exceptions have been added to modern languages, because you cannot fake it. Supporting exceptions everywhere may make out-of-memory work. An alternative that is practical right now is to make malloc call some code of your own at the moment it discovers out-of-memory so that you can try to free cached information or gracefully abort. In both of these solutions, malloc never returns zero, so testing is misleading and useless. So again, PLEASE don't do this!

They are decoding UTF-8 and URL encoding by spitzak · 2006-01-21 05:50 · Score: 1

I believe the variable names are an attempt to represent how many bytes were needed to produce that value. Not sure this is a great idea, rather than using a number suffix, but it seems likely this is why those names were chosen.

Meaningful names by dustmite · 2006-01-21 06:09 · 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.)

Also by dustmite · 2006-01-21 06:16 · 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.

Re:what bug?? by niXcamiC · 2006-01-21 06:18 · Score: 1

And its windows explorer like how? Besides the fact that it has a bug in it, I can't see any connections between the two.

--
Chances are any disscution on Slashdot will degrade into a flamewar about ID/Christianity within 14 posts.

Many (slow) eyeballs do what now? by general_re · 2006-01-21 06:34 · 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.

Re:Many (slow) eyeballs do what now? by daVinci1980 · 2006-01-21 08:04 · Score: 1

I hope the moderators see your post and mod you up to +100000, Insightful.

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.

--
I currently have no clever signature witicism to add here.
Re:Many (slow) eyeballs do what now? by Zerathdune · 2006-01-22 06:06 · Score: 1

granted, but it's still a whole lot better than a flaw that has existed literally for decades, is finally exposed, and it's another several weeks before the vendor releases a patch. in the GP's scenario, there are most likely only a small handful of people who are exploiting the flaw, since it is probably more likely for any given person who spots it to report it than to use it to their advantage. sure, stuff like this sometimes goes unnoticed for quite some time, but it is unnoticed by everyone, at least for the most part.
does this mean that as long as you keep your OSS up to date you're invincible? Fuck no. No one ever said OSS was impenetrable. it is however, more secure than a situation where a hole is well publisized long before there is a patch.

--
No single raindrop believes that it is responsible for the storm.

Checking malloc() is an obsolete practice by typical · 2006-01-21 06:55 · 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.

Re:Checking malloc() is an obsolete practice by frn123 · 2006-01-21 10:31 · Score: 1

I read ./ a lot and i rarely reply. Except when i see something that makes sense. Like THIS
Re:Checking malloc() is an obsolete practice by joe_bruin · 2006-01-21 17:05 · 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.
Re:Checking malloc() is an obsolete practice by typical · 2006-01-21 17:44 · Score: 1

This is the worst advice ever posted on Slashdot. Congratulations. The scary part is that it got modded "Insightful".

It certainly illustrates the diversity of views.

It is not impossible to cleanly back out failure states. It is difficult.

I agree that it is not impossible. However, I will argue that it is not worth development time. Your software will never be perfectly bug-free, so you have to figure out where to spend your time working on it. Checking malloc() and writing code to back out of allocations is just not an effective use of that time.

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.

Wrap malloc() with abort(), or something similar. If abort() fires, your program has a bug.

But handling most error cases correctly (obviously I try for total coverage) is better than handling none of them.

Maybe. Or it might lead to cascading problems, making the original bug harder to track down. I think that pretty much unilaterally all the large applications that I used to run on platforms with hard memory limits, like classic Mac OS, would die in one way or another if they ran out of memory. Maybe you'd see a series of three error dialogs come up about a lack of memory, and then the program would crash. [shrug]

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.

This is why I said "almost all circumstances" -- you're right that without an OOM killer, something like this could happen. The idea is that a typical desktop system *will* start to break under memory pressure. Probably processes will start crashing -- even if all memory allocation errors are handled and the actions backed out, things like ssh will become unusable because they have no memory to work with. Unless the system's memory usage starts dropping, even perfect software is going to sit there, immobilized.

Now, yes, the OOM killer isn't perfect, but the idea is that memory exhaustion should never be reached on a system unless a bug is present, and then the OOM killer blows away that process.

My point is that chances are pretty good that either a software package is allocating memory in a loop or has made a huge allocation if memory is exhausted -- so that package is probably the one at fault, so even without an OOM killer, abort()ing in the event of memory exhaustion is probably not unreasonable.

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.

It doesn't -- it might throw up a warning dialog when one isn't necessary, and I suppose that if you were running it on a box with 16 megs of RAM, it might fail. But you also aren't going to make the GIMP bulletproof, and this is a pretty reasonable strategy.

--
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Re:Checking malloc() is an obsolete practice by typical · 2006-01-22 07:15 · Score: 1

Oh, and one more followup. This applies to *application* code only, not to library code. I'm currently maintaining a cross-platform abstraction library. In this library always check malloc() results and propagate errors upwards (even though, on a default Linux setup, this code will never be executed). In this code, it makes sense to handle allocation failures and hand them back out, because it's fairly straightforward to propagate the error upwards and because the application using the library may be doing that init() phase where it needs allocations to be checked.

--
Any program relying on (nontrivial) preemptive multithreading will be buggy.

Re:Arbitrary code with what privileges? [O/T] by Mancat · 2006-01-21 07:05 · Score: 1

And I'm on the opposite end of the spectrum, wher I've found that many malware packages don't know what do when they are denied systemwide file and registry access, and as a result they just crash or bail out. I manage a couple of small offices, and with all users running XP with LUAs, nothing ever gets infected. Plus, if there is a piece of malware or virus that does infect their account, it makes things a lot easier for me to clean up. I don't have to start picking through system files, so I keep my hair a bit longer.

Also there is the added benefit that when they visit a site with IE, the newest exploit of the month isn't running as Administrator. I'd love to use Firefox, but a) I doubt Firefox will end up being that much more secure in the long run b) most state law online databases they use need IE, so kinda no choice there.

--
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?

Do you have any proof by badriram · 2006-01-21 07:07 · Score: 1

Does taskbar, start menu, desktop all render in html. I know "Active Destop does", not the regular one. Also i know windows explorer uses html and js to render the taskpad, and other views while browsing files.

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 sys admins and get better ones, that will put effort into making users log on as regular users.

IIS in the latest version does not by badriram · 2006-01-21 07:09 · 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.

Re:IIS in the latest version does not by Billly+Gates · 2006-01-21 12:21 · Score: 1

I dont run the latest versions of these software packages because its a home pc just used to learn programming. But its a relief IIS is no longer run in ring0.

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 critical environment where it could take down the whole machine.

But the grandfather's point with everything running in the kernel is a big problem with windows that cost microsoft some big security holes and expensive upgrades/rewrites had to be done with w2k and w2k3 to make it more stable.

--
http://saveie6.com/

Re:OS? No. by theCoder · 2006-01-21 07:43 · Score: 1

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 structurally, it's not much different from KDE.

--
"Save the whales, feed the hungry, free the mallocs" -- author unknown

Did you look at the ECMA standard? by Grendel+Drago · 2006-01-21 07:46 · 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

IE by nurb432 · 2006-01-21 08:01 · Score: 1

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.

--
---- Booth was a patriot ----

Yeah-yeah it's a big bad bug but... by 16777216 · 2006-01-21 08:14 · Score: 1

Show me a piece of code longer than 500 lines that ain't got a bug or two no matter the OS.

--
I am. Lower your shields and power down your weapons, they are useless. Your biological and technological distinctivenes

ummm.. they already do by shis-ka-bob · 2006-01-21 09:03 · 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

Alternative shells = better security? by Jesus_666 · 2006-01-21 09:12 · Score: 1

Worse, when there is a legitimate reasons for a superuser to log in, he is logging into an Explorer shell.

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.

--
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)

Re:I've got news for you by caffeination · 2006-01-21 09:49 · Score: 1

Seems this thread attracted the anti-Linux-zealots or something. Your response is only as much flamebait as your parent post, which is far from interesting. In an ideal world, he would have been "modded into oblivion" in moments, and you would never have thought to waste your time responding to his very amateur flamebaiting.
Bad luck man.

Re:KDE Pros/cons by Jesus_666 · 2006-01-21 10:01 · Score: 1

KDE has KParts, which offer some nice possibilities. Also, you can have an OS X-style menu (ie. it does not appear in the application window but in a Kicker panel) - although those only wirk with Qt applications. Someone should put compatibility for this in GTK, as it is very nice to have (it saves valuable screen real estate).
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.

--
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)

Mod down by brunes69 · 2006-01-21 12:13 · 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.

Code used by safari? by Anm · 2006-01-21 12:20 · Score: 1

I know Safari's HTML enginge was derived from KHTML. Does it also use the same Javascript engine?

Anm

You are oversimplifying things... by toadlife · 2006-01-21 12:54 · Score: 1

...and you are misinformed about Microsoft's Windows 2000 support policy.

"I don't see this! I have two comparable machines running on a KVM switch. One runs Linux (Gentoo + 2.6 kernel) and the other runs win 2k. I run OpenOffice and Mozilla on both. In general, The Linux machine runs so much faster that I use it in preference to the Windows machine for everyday tasks."

And I don't see what you're seeing. I run OpenOffice on both FreeBSD 6 and WinXP and loading times are roughly the same. They very well might be faster on FreeBSD, but I don't think that was point of the parent. The parent was probably thinking of an OO/Microsoft Office comparison. On Windows, even with Open Office "quick launch" enabled (which makes it a fair comparison) Microsoft Office blows away OO as a far as loading times and memory footprint. When you compare Firefox to IE, IE takes up less memory when ideintical pages are loaded. One more thing. You said "comparable" machine. For a fair comparison, identical machines are needed.

"And isn't that the beauty of OSS? You can use the previous kernel without being forced to upgrade to keep your machine up to date with the latest security patches! Microsoft is dropping support for Win2k so I may be forced to upgrade just to keep my desktop secure! I personally use 2.4.x kernels on my servers because the latest improvements in the 2.6.x kernels seem to all be related to desktop performance improvements so it isn't really needed on my servers and, like you, I want the most stable for my servers. I have a lot of good experience with 2.4 kernels, why change now? Security issues are still being patched in the 2.4.x tree so I don't have to worry about that."

That's great, but Windows 2000 is a 6 year old OS, and contrary to what you're saying, Microsoft will be releasing security patches for it until *June 2010*. How many ten year old linux kernels do you use? If you do use any, are security patches still back ported to it? how about drivers? If you bought a new server would the hardware it contains have drivers that support the 2.4 kernel? I've seen some linux drivers that only support a specific *point* release of the 2.6 kernel. What if you buy some product that only supports the latest version of RHEL which uses a linux kernel that you don't trust? This broad assumption that older linux kernels don't become obsoleted due to support issues is at best, a half-truth.

Also, the overall quality (both security *and* stability) of Microsoft's server and desktop products has increased steadily from version to version. Aside from application support scenarios, there is no reason not to go with the latest Windows version when purchasing a new desktop or server. I'm not sure what your hang-up has been with moving from Win2k to Win XP on the desktop. It's more secure than Windows 2000, has more features, and supports more hardware. Do you use the same desktop machine you used in 2000, or have you been installing the same copy of 2000 on each desktop machine you purchased since 2000? Since XP will be ending around the same time as 2000 (It was released around the same time), I suggest you just wait for Vista and move to it after it comes out. After all, like I said before, you'll still have security patches for Win2K for quite some time.

--
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.

Updated Debian (stable) packages available by 00lmz · 2006-01-21 13:46 · Score: 1

I don't know about you, but this Debian security advisory (+ updated packages) was dated January 20. I ran apt-get update and it showed up on the package list before the advisory was even on the security RSS feed.

Why report this? by Jerry · 2006-01-21 14:41 · Score: 1

It will be patched before the number of talkbacks reaches 350, or 24 hours, which ever comes first.

Er, wait... it's already patched, and talkbacks are only at 194 !!!
http://kde.org/info/security/advisory-20060119-1.t xt

Wow... announced yesterday and patched over night.

--

Running with Linux for over 20 years!

Safari *not* affected by ansodyuhuf · 2006-01-22 05:38 · 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.

The obligatory one-liner by http · 2006-01-22 17:59 · Score: 1

you said,

...apt-get update, apt-get dist-upgrade...

and i wondered, "why `dist-upgrade' when `upgrade' would normally suffice?"
just curious - i was trained to treat laziness as a cardinal virtue in computing.

--
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1

Re:The obligatory one-liner by Urban+Garlic · 2006-01-23 02:34 · Score: 1

It's because of my own species of laziness -- I pretty much just always use "dist-upgrade", and then I don't even have to remember that the other one exists. With sources.list configured in the appropriate way, there's no danger of suddenly getting "etch" by surprise, so it's just easier. Actually, now that I think of it, it occurs to me that I don't think I know the actual difference between upgrade and dist-upgrade. If they really are the same, then your laziness wins, it's still only one command, and less typing. Hmm...

--
2*3*3*3*3*11*251
Re:The obligatory one-liner by http · 2006-01-23 14:40 · Score: 1

Well, they're not exactly the same, but your point about sources.list is correct. If sources.list is sane, there is no difference between the two. I remember my first two attempts to perform the upgrade from woody to sarge required repeated fiddling with sources.list, and i discovered a use for the bash `until' construct:

until apt-get -y dist-upgrade; do until apt-get -y --fix-broken upgrade ; do sleep 1 ; done ; done

As a result, apt-get dist-upgrade puts the wind up my neck when perhaps it shouldn't - when sarge was declared stable, my dist-upgrade went without a hitch.

--
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1

Gaaaah! by aug24 · 2006-01-22 23:46 · Score: 1

Bloody MS apologists: why doesn't install that way by default then?!

God's teeth, but you people just don't get it. You install as secure as possible and allow the admin to open up, not the other way around.

Justin.

--
You're only jealous cos the little penguins are talking to me.

Re:Gaaaah! by badriram · 2006-01-23 03:42 · Score: 1

it is the default now in sql server 2005, it aint like they can go back in time and change defaults in a software they released in 2000. How about gaining some self control and take a chill pill. learn that security is not magic, it requires work on software(which takes a loong time), work by the system admin, and work on users behalf....
Re:Gaaaah! by aug24 · 2006-01-23 04:15 · Score: 1

I know security isn't magic, but you can't seriously defend practices like that by saying that somewhere in the docs it mentions "you should change this". It should have been like that from the start.

It's not as though security issues hadn't already reared their heads by 2000, it's just that till then it wasn't affecting MS's bottom line so they didn't give a shit.

J.

--
You're only jealous cos the little penguins are talking to me.

WMF exploit is NOT related to MSHTML by Anonymous Coward · 2006-01-25 09:07 · Score: 1, Informative

The recent WMF exploit that attacked the thumbnailing process however...

...was not a Trident/MSHTML flaw, but rather a GDI flaw. In fact, Trident was safe, as it skipped escape instructions.

Slashdot Mirror

KDE Heap Overflow Vulnerability Found

151 of 233 comments (clear)