iDEFENSE identified a vulnerability in the Opera Web Browser
that could allow remote attackers to create or truncate
arbitrary files. The KDE team has found that similar
vulnerabilities exists in KDE.

The telnet, rlogin, ssh and mailto URI handlers in KDE do not
check for '-' at the beginning of the hostname passed, which
makes it possible to pass an option to the programs started
by the handlers.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2004-0411 to this issue.

3. Impact:

A remote attacker could entice a user to open a carefully crafted
telnet URI which may either create or truncate a file anywhere
where the victim has permission to do so. In KDE 3.2 and later
versions the user is first explicitly asked to confirm the opening
of the telnet URI.

A remote attacker could entice a user to open a carefully crafted
mailto URI which may start the KMail program with its display
redirected to a remote machine under control of the attacker.
An attacker can then use this to gain full access to the victims
personal files and account.

An attacker could entice a user to open a carefully crafted
mailto URI which may start the KMail program using a configuration
file specified by the attacker. If the attacker is able to install
arbitrary files somewhere on the machine, the attacker can include
commands in the configuration file which will be executed with the
privileges of the victim allowing the attacker to gain full access
to the victims personal files and account.

4. Solution:

Source code patches have been made available which fix these
vulnerabilities. Contact your OS vendor / binary package provider
for information about how to obtain updated binary packages.

The terms "Open Source Software" (OSS) and "Free Software" (FS) are synonyms (although some people will disagree). While the former stresses the fact that the source code is freely available the latter stresses the freedom to change and redistribute the software (sometimes under certain restrictions, cf. GPL).

Nowadays, many companies make the source code of some of their software available (i.e. it could be called "open source software", but of course not in the sense of "our" definition of OSS), but they disallow changes and redistribution (so those companies' software is definitely not FS). That's why I prefer the term "Free Software" even though, at least for me, there's no difference between OSS and FS.

I believe that "free software" makes many think "free as in beer", while "open source software" means "free as in thought". I guess the internet other and advertisement channels has diminished the meaning of "free", at least in "the free world" ;)

Well, we should just use the term Libre Software. Suppose some people may not know that word, but anyone interested could easily look it up so it would prevent any confusion. "Libre" is actually in the Oxford English Dictionary (it was used in the 16th century apparently, "libre will"), so it is almost English already.

Because I agree that Microsoft and other companies confuses the issue with their "shared source" software and the like. But between the two, OSS is less confusing then Free Software IMHO.

What I don't like is FOSS or F/OSS that I've started to see just recently. It reminds me of floss.

> i think no one will install the fix by hand and just wait for updated binary packages from their vendors.

You are probably right.

> All in all i think the vulnerability is longer visible to the world as in microsoft windows.

In general we try to give the vendors/packagers some time to prepare binary packages before we announce. In this case the vulnerability was published already, so there was no point in waiting any longer. I'm sure the distributions will soon have updates available.

Time When I noticed this flaw 05.00... Time when it was fixed 05.02 :-D

Hey duuudes it's not that difficult, just download patch, patch it up, recompile and install.... Done.

Those "Windowse And Distro Newbie users" will always have to rely on MS, Feodora, Suse, you name it. Because they have better things to do, is it supposed to punish me because I at least now how to do it. I DO NOT want to wait several weeks before I get a new release and reinstall AAAALL the mumbo jumbo from start.

Having to upgrade to KDE 3.2.2 and then a patch is a needless waste of time, not everybody is having the newest version around. It reminds me of the terrible practice on the Windows platform (install service pack after service pack, then hotfixes)

Please always release a new version after critical upgrades, call it KDE 3.2.2b or 3.2.2.1 or whatever, but please:

never ever let the latest stable release contain critical bugs!

Not everybody is reading those security bulletins, there is absolutely no need to keep re-introducing old bugs into the wild.

Exactly this problem is one of the main reasons why worms and bugs never die on Windows, let's not make the same mistake and make sure that nobody upgrading to (or installing for the first time) the latest KDE is needlessly getting bugs that have already been fixed.

You can look into whatever you want, I doubt that there will be ever KDE official binary packages. And "packages that will install on many different distros" does not mean all and especially not platform agnostic.

- I want to be able to know wether a machine is vulnerable or not. That's only possible if the patched stuff gets a new version number. Otherwise we end up in complete chaos like in Windows, where as soon as the number of machines is bigger than 3, nobody knows which machine got what patch.

- Lots of people install KDE from source, why not offer them the latest in one package? What's the big advantage of hoping that they will also find the patches and apply them?

- People make mistakes and packagers make mistakes. With no new version number how do I know that my installation was really patched by the packager? There is no way to know except try out an exploit, which can't be seriously be your suggestion or is it?

It's a matter of principle: It should be clear and obvious what is vulnerable and what isn't.

Most OSS-projects (including Linux) follow that rule and release a new version whenever a critical update is needed. That way everybody (please note that often several admins are administrating several machines, and not everybody can remember who patched what) can check whether something is still vulnerable and upgrade if needed.

As soon as you bring in not-changing-version-number patches, the whole system falls apart. Some will forget that they have already patched and will needlessly patch again, others will forget that they have not patched some machines and will keep them on the net. Yes, in a perfect world everybody remembers all the patches he applies, but in a perfect world there wouldn't be any bugs that require a patch in the first place.

And this system is one of the main reasons why security on Unix is easier to maintain and more importantly: OLD BUGS DON'T COME BACK.

So *NO*, this problem cannot be solved by the vendors, this can *ONLY* be solved by the KDE-team by swallowing the geek-pride and release a new version number.

Also, what's the big harm of releasing KDE 3.2.2.1 or 3.2.2b (of course that number has to be shown in kcontrol, otherwise it's pointless)?

It's rather easy to tell if a machine has been updated, distributions change the package revision number when they release updated packages. 3.2.2-1 is unpatched and 3.2.2-2 is patched released. How do you know the patch was actually in that release? Check your distributions web page, they typically document security updates and will say "3.2.2-2: Patches KDE 3.2.2 security hole." This isn't a new problem for distributions, they've had to deal with it from day one.

On the KDE side, going through the full process of getting a new release ready just for a small patch is over kill. They can release the patch now and roll it into the next release without too much worry.

According to our beloved GNOME folks, Novell is implementing a desktop that will include OO.org, Evolution, Mozilla and (for the love of god, please no) MONO with applications (!). With the platform being SuSE, desktop beneath it may very well be KDE. Talk about a huge heavy mess, and there you have it.

Please don't try and start something here. If you look it isn't the Gnome folks who are saying this. As everyone should know by know 'they' have a track history of this sort of thing, and everyone should have learned to ignore it.

The same day the exploit was announced to the team patches were created. THhis does not surprise me. What *does* surprise me is the huge gap in time between when the exploit was aquired and the KDE team was informed.

What is the purpose in waiting so long before informing KDE? Were they waiting for Opera? If so, why?

What really matters is that patches were created on the same day that the KDE people were informed. The delay for public disclosure was less than a month.

There is always a delay between the exploit being discovered and making it known to all the right people. No one wants to disclose a security problem straight away without having analysed it fully, looked at how it may be fixed and identified the relevant people to contact. That is just the way of things. Given that patches were created on the same day and vendors were informed within two, that shows that the whole system worked on this occasion.

People make it sound as if something unspeakable is going to happen if there is any sort of delay in people being informed, or a fix being found - that's life. Anybody using this exploit for mailicious purposes will have to work out what they are going to do with it, and how they are going to attack a system. This is in stark contrast to Windows where the number of exploits that allow a malicious attack a free hand into the system (without anyone being tricked into anything) is unbelievable, so granted, a delay would be worse for people using Windows. You also have to couple this with the fact that if there is a security problem with Microsoft software the patch is sometimes your only way of remedying it - you can't just change one or two things or shut them off.