Command injection through URL in Pidgin

[John Houwer]

Hi,

I'm using fluxbox.

execve("/usr/bin/xdg-open", ["xdg-open", "http://127.0.0.1/`date`"], [/* 73
vars */] <unfinished ...>

If I run a URL from claws-mail I get:
execve("/usr/bin/xdg-open", ["xdg-open", "http://127.0.0.0/$%28xterm%29"],
[/* 74 vars */] <unfinished ...>

xdg-open is a /bin/sh shell script, if it gets executed I'm pretty sure the
arguments get interpreted before any code from the script is run.

I can see that one can argue that xdg-open is broken, and maybe it is. I
believe in multilayer security! In my opinion xdg-open should not have this
design and pidgin should escape this stuff.
As it is now, xdg-open relies on validated input. This is a bad decision,
but so does the shell. ;)

I don't have a gnome or kde setup near me, so I don't know if the problem
exists there too.

Regards John


On Sun, Jun 9, 2013 at 6:49 PM, Tomasz Wasilczyk <tomkiewi at gmail.com> wrote:

> 2013/6/9 Ethan Blanton <elb at pidgin.im>:
> > John Houwer spake unto us the following wisdom:
> >> http://example.org/$(xterm)
> >> opens a xterm (linux)
> >>
> >> http://example.org/$(touch<tab>/tmp/ownage)
> >> Creates the File /tmp/ownage! If you use a <space> the URL will stop. If
> >> you use a <tab> you can inject what you want to.
> >>
> >> In preferences the browser is set to "desktop default".
> >>
> >> I think this is a major concern. The user needs to click on the link,
> but
> >> you know how it is nowadays. ;)
> >
> > This is a major concern.  We should be inoculated from this, but there
> > may be a bug.  It is also possible that there's a bug in the desktop
> > handler, or in the program/script handling the ultimate URL.  What
> > desktop environment are you using?  On gnome we use gnome-open, and on
> > KDE we use kfmclient; in both cases, the URL is escaped with
> > g_shell_quote.  Can you get a strace of this process, with arguments,
> > and find the exec we're actually invoking?
> >
> > In general, though, I don't like this code.  We should ultimately be
> > reducing to execv, not exec.  It looks like we're using
> > g_spawn_command_line_sync, and we should be using g_spawn_sync.
> > Regardless of where the bug lies in this (in our code or in the
> > desktop), this should be changed.
>
> What do you think, if I would rewrite that code to use execv (of
> course, hidden behind glib)?
>
> Tomek
>
> > Ethan
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> >
> > iQEVAwUBUbSiCf8fixZ3H8crAQi58ggAsATOsqlecIVO437QRcdy4so29yWi/gQ3
> > nfs/UyIEktRAd6sXrcNee8nMTmg40ATXJMe5wCzZmfYs1ItZTA0J0qhOeUhlUmYE
> > sxujMYuBuSDBxbubRZONNVOLqBu6wJns+OLtrAvrM7Zd0S7SXtQmp/eoqnkq+ky5
> > uIgL8XDifzj4iBcyqplvoUJ0YGJoGXotFENbAL7tF8sX9X3Kn9uHTFpfdBqFWplK
> > vX/iMOPDooWkHr4grhSKNeXOF394vfMI7LFyfS3iuz1fWnbRuWIALJ9l98vNtqfU
> > Q0fHFPkvH1IZU5pyXu5L0fxxXRSm9ol1Sm7rCduuwoekNBch3SUIQQ==
> > =9n9p
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > security mailing list
> > security at pidgin.im
> > http://pidgin.im/cgi-bin/mailman/listinfo/security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20130609/5d578ab5/attachment.html>