Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Marc Roessler (marcTENTACLE.FRANKEN.DE)
Date: Wed Feb 14 2001 - 07:46:10 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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.


    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.


    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]

    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.


    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