Not even a month ago, it was KVIrc 3.4.0 in it’s Windows release which has been vulnerable to what has been at least a DoS/crash.
As of yesterday, there have been new exploits posted on the usual sites around the internet – but this time it is not the fault of KVIrc’s URI handler, because the bug is only exploitable if the malicious link is opened with Microsoft’s Internet Explorer and is possible because of its unique way to handle double quotes (“) in links.
This time it is not possible to just let the client of a victim crash but to execute a command of the attackers choice – opening a whole can of worms as one can execute each and any command with the privileges of the attacked user.
In an interview conducted on IRC with members of the KVIrc team they said that “the ‘vulnerability’ is present in any programs URI handling engine until they decide to work around IE’s oddities”, which, according to this posting on their mailinglist, involves using DDE to pass links back and forth between applications.
Since only a few members of the KVIrc team do have the possibility to compile the client for the Windows operating system it might take a little while until a fix pops up, but they assured IRC-Junkie that this issue is being worked on.
Update 11/22/2008, ~8 hours later: There is an updated package released for testing which contains “all the latest fixes for the bugs found in 3.4.2.”. Link to the download is in this mailinglist posting.
X-Ception says:
X-Chat suffered the same at one point if i recall correctly.
phrozen77 says:
[quote comment="246"]X-Chat suffered the same at one point if i recall correctly.[/quote]
Yes. So did mIRC, GAIM and probably a few more.
Quension says:
It’s sad and frustrating that every time this issue comes up, the people involved try to blame IE. Apparently nobody actually reads the Microsoft-provided documentation for working with URI handlers:
http://msdn.microsoft.com/en-us/library/aa767914.aspx
I can certainly understand being surprised by the issue, but trying to blame someone else for your own misunderstanding is just not cool, whether it’s IE or something else entirely. Especially when we’ve gone through all of this before, and everything is still documented from the last round of research!
Oh well, at least they worked around it.
(FWIW, the proper commandline fix for this is to have a special parameter, e.g. “-uri”, that is only accepted as the first argument on the command line, and is used in the handler registration. From then on, the rest of the commandline is treated as arbitrary data, instead of processed for additional parameters. Think of it like the “–” argument for many GNU apps on linux.)
Quension says:
…and once again, blog software mangles my posts. Sigh. The GNU app example is supposed to be a double dash.
fabio says:
the faulty design of an operating system should be corrected to be not easily exploitable by a common developing behaviour. About every chat client (and other software, eg trillian, firefox) had to patch itself to prevent a problem caused by a faulty url handling method interface. The shell commandline of this os is not able to handle correctly urls that comes from a part of the os itself, and this way to follow urls is the os default one.
Quension says:
Usually people who say things like “shell commandline” are thinking in unixy terms, which aren’t applicable here. What happens in a URI handler is a simple macro-based generation of the commandline; argument separation, quoting, wildcard expansion, and other processing is done by the application, not the OS. In particular, cmd.exe or any other commandline UI is not involved here.
I assume the phrase “comes from a part of the os itself” is referring to IE, but note that URI handling is a generic mechanism. Many different kinds of software can be a source for URIs, including the above mentioned chat clients and other software.
I won’t make any comment on whether the design of the interface itself is faulty or not, but I will note again that this issue is not unique to Windows’ URI handling. The GNU convention of the double dash argument exists precisely because of how most unix shells handle command lines. On POSIX systems, when you enter a wildcard on the command line, the shell itself is responsible for searching for file and directory names that match; it then replaces the wildcard on the command line with the matching names. The resulting commandline passed to the application is the same as if you had typed out each name yourself, instead of using a wildcard.
The problem here is that filenames may begin with a dash, just like a commandline option you might enter yourself. If you enter a wildcard, and a matching file or directory name begins with a dash, then the application will interpret the name as an option instead, possibly with disastrous consequences.
This issue is identical to the Windows URI case: assuming a commandline was entered by the user directly, when it may in fact come from another source. Proper defensive processing is required. In the unix world, the solution was to create a special argument for each application to disable option processing for the rest of the commandline. The same solution applies to Windows URI handlers.