Command injection through URL in Pidgin
elb at pidgin.im
Sun Jun 9 13:22:05 EDT 2013
John Houwer spake unto us the following wisdom:
> execve("/usr/bin/xdg-open", ["xdg-open", "http://127.0.0.1/`date`"], [/* 73
> vars */] <unfinished ...>
OK. This should be perfectly safe. I just looked at my system, and
xdg-open uses 'sensible-browser "$1"', which keeps the quotation on
$1; sensible-browser also never interpolates the URL as a shell
argument. Something on your system is busted. (Ahh, gentoo ...) I'm
surprised to see that this is an execve; glib is doing something
"clever" with the arguments to its spawn command, which is OK By Me.
I think we should fix our code use g_spawn_sync or g_spawn_async
> 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 ...>
Escaping shell metacharacters is probably a good idea, as it
defends us from stupidity in chains like whatever xdg-open is
devolving to on gentoo. I'm not sure I consider it an urgent security
bug in Pidgin, but I think we should probably put it on Tomasz's TODO
> 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'd like to figure out exactly where in the chain this breaks down.
If you have time to chase down the ultimate error so that it can be
reported to the correct package, that would be great. We would be
willing to help you do this. I suggest looking at xdg-open to see if
you can figure out what it's invoking for this URL.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: Digital signature
More information about the security