Command injection through URL in Pidgin

[John Houwer]

Hi,

the files in
http://gentoo.mneisen.org/distfiles/xdg-utils-1.1.0_rc1_p20120916.tar.xzare
on my system, this seems to be a gentoo specific issue. It works with
the package and git (HEAD) from freedesktop.org

There are bug-reports for this issue but they don't address the security
implications. I will raise the issue there too.

https://bugs.gentoo.org/show_bug.cgi?id=447662

Thank you.

Regards John



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

> 2013/6/9 John Houwer <john.houwer at gmail.com>:
> > Hi,
> >
> > I'm using fluxbox.
> >
> > execve("/usr/bin/xdg-open", ["xdg-open", "http://127.0.0.1/`date`<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 checked it on my system and xdg-open doesn't seems to be broken (but
> I may be wrong). I've also checked original packages [1] and they
> seems different from mine (openSUSE). So, I assume, every linux
> distribution have its own - could you provide yours? Optimally, you
> could provide all xdg-* scripts.
>
> Tomek
>
> [1] http://portland.freedesktop.org/download/
>
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/70758030/attachment-0001.html>