Date:         Wed, 14 Feb 2001 14:46:10 +0100
From: Marc Roessler <marc@TENTACLE.FRANKEN.DE>
Subject:      Security hole in kicq
To: BUGTRAQ@SECURITYFOCUS.COM

Hi all,

there is some security related problem with kicq.
The authors were contacted and provided with a suggestion for a patch
which should be available soon.
I did not find anything on the archive on this, so here we go.

kicq is a free icq client clone available at http://kicq.sourceforge.net/.
Unfortunately received (untrusted!) URLs are passed to the specified webbrowser
(standard is kfmclient) without any sanity checking using system().
The only user action needed for this is to click "Open" in a popup menu.


I tried with version 1.0.0, it is vulnerable for sure.
Other versions (such as 2.0.0b1) seem to be vulerable as well,
though i did not compile them to try.



Details:

The problem is in file kicq/utils/kwebbrowser.cpp. For example:

	system(QString("kfmclient openURL '" + URL + "' &").latin1());

Other browsers (netscape, lynx, wget) are called similar, this needs to
need to be patched as well.



Demonstration/Exploit:

Exploiting is trivial.
By adding shell metacharacters such as "'", "&" and ";" it is possible
to send commands to the shell. If done creatively, the webbrowser will come
up nevertheless and the user will not become suspicious.

The worst part is that the shell stuff can be hidden from the user. The
URL display field will display 123 characters (number may vary). If the URL is
longer only the last 123 characters will be visible. Spaces count as
characters as well!

The following URL will be visible as "http://www.test.com/" to the user:
[dots are to be replaced by spaces]
---
http://www.test.com/test.html'&xterm&'truehttp://www.test.com..............................................................
---
When opened by choosing "Open URL" in the popup menu,
kfmclient will go and fetch http://www.test.com/test.html, while an xterm pops
up on the desktop.



Patch:

The obvious solution is to replace the system() stuff by execve or one of
its front-ends, making sure spaces in the URL will not be interpreted as argv
delimiters, otherwise an attacker may pass arbitrary arguments to the browser.
Also it should be checked that the first character of the URL is not "-" ..
Think about what an URL "-display attacker.com:0" will do to lynx..
This will suffice for the moment, though on the long run the 123+ character
feature should probably be fixed.
Probably it is a good idea to remove the "Open URL" feature altogether,
cut-n-paste is not a problem any more with most GUIs and 'evil' URLs might
be spotted more easily if passed manually.


Greetings
 Marc Roessler