Hi, xchat's upstream notified me today of the following: > Hi XChat package/port maintainers, > > I encourage you to make a new version with the following patch: > > http://xchat.org/files/source/2.6/patches/xc268-sec-url.diff > > I would consider it a low to medium security fix, with more details to > come later. The patch should apply to almost any version. > > Regards, > Peter. I bumped xchat to 2.6.8-r2, including the patch. I'm restricting this bug, waiting on upstream to provide more info and make the issue public. Sven
somehow this was overlooked... Sven, any news on this one? Is it public now? I saw that 2.8.0 was realeased, but did not see any mention of security issues can we start on getting 2.6.8-r2 stable?
I haven't received any more information from the authors. The FreeBSD project patched their port, but that was about it. I'll ask the authors.
no response from upstream :( So, what to do next? Mark 2.6.8 or 2.8.0 stable?
it looks like the patch is already included in 2.8.0, so i think we can get that marked stable if there are not important reasons not to so this issue is still not public? then we might want to handle the stable marking in a new bug, otherwise feel free to open this up anyone can think of an impact for this issue?
2.8.0 is ok to be marked stable. about opening this bug, i don't know. i haven't seen anything like a security announcement from the other projects also informed about the issue. the freebsd project patched their port, but i can't find anything in the debian package changelog. personally i'd handle the stable marking in a separate bug.
2.8.0 is stable on most arches, that bug is totally obsolete. BTW, i don't really know what to do with an "unspecified vulnerability". Let's close it, feel free to reopen if you disagree.
We still need this stable on at least alpha. CC'ing kloeri to handle that.
Kloeri any news on this one?
Finally done. Sorry about the delay.
This one is ready for GLSA vote. I tend to vote NO.
The patch doesn't give any useful hint, but I haven't deeply looked into the code. I vote no-glsa too.
I'm not sure what's wrong with the isspace function without digging a lot deeper. I vote no, because I can't find any security implications of this, even from other distros or places like secunia.
Sven any news on the status of this one? Before we close it I'd like it to be opened up.
I also vote no.
Keeping it open until we can unrestrict it. Sven, any news on that?
Can someone tell us in this is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4455 ? i can't find a clear description of CVE-2006-4455
No, that is a completely other thing. The patch mentioned here changes my_poptParseArgvString, which is only used for /exec commands as far as I can tell. It changes isspace to an explicit check for a single space. But I don't know the implications of this. Upstream didn't respond and didn't make anything public on this issue.
making it public with upstream's approval (I contacted them by e-mail), and finally closing.
This is all old news, but just for interest's sake I'll post all the conversations I had about this: From: Matthew Earl I have been studying the code which is called when an xchat user clicks a link in your xtext widget. I believe I have discovered a vulnerability which under certain (not unlikely) conditions, could lead to arbitrary code execution. The vulnerability is born out of the difference between the set of space deliminators used for identifying words in an xtext widget, and the set of space deliminators for separating arguments in the util_exec function. URLs are identified from the body of the xtext control as words satisfying certain conditions (eg. they begin with http://). In turn, words are identified as pieces of text with a character satisfying is_del to the left, and a character satisfying is_del to the right. The is_del macro is satisfied if and only if its argument is one of ' ', '\n', ')', '(', '<', '>', '\017', '\02' [src/fe-gtk/xtext.c line 79]. When a URL (as identified by the above rules) is clicked, the URL is composed with a application (eg. firefox) to form a command, (eg. firefox http://xchat.org/) [src/fe-gtk/fe-gtk.c fe_open_url_locale()]. This string then finds its way to the function util_exec, in src/common/util.c. This function splits the string into arguments based upon characters satisfying the isspace() function in declared in ctype.h. On some locales (including mine), there are characters which satisfy isspace(), that do not satisfy is_del. What is more, the IRC protocol permits these characters in PRIVMSG commands, and xchat prints them in its xtext control. The two characters satisfying these conditions on my machine are '\11' and '\12'. The upshot of this is that one could add extra arguments to the command used to open the URL, provided the characters in the arguments are not deliminaters as defined by is_del. It also turns out that firefox has a command line argument to enable a debugger, and another option to declare the debugging binary that firefox should be invoked with. I present a malformed URL which when opened with "firefox %s" set as the program to open URLs will cause glxgears to open: http://example.com/\12-debug\12--debugger\12glxgears (\12 should be replaced with the 12th ASCII character). What happens is xchat interprets the whole string as the URL, and produces the string: firefox http://example.com/\12-debug\12--debugger\12glxgears which is sent to util_exec. util_exec then splits based on characters satisfying isspace(), to give the argv vector that is fed into execvp. On my machine the effect of this is as follows: argv = {"firefox", "http://example.com/", "-debug", "--debugger", "glxgears"} The script in /usr/bin/firefox then interprets this and invokes the following command, as if glxgears were a debugger: glxgears /usr/lib/firefox/firefox-bin http://example.com/ -a firefox Now clearly this could be made much worse by substituting "glxgears" with "rm" for example. Further still, extra arguments on the end of the URL (by the \12 method), will be carried through to the command that firefox eventually invokes. This can trivially be used to delete arbitrary files, and it is conceivable that through creative use of Linux command line tools arbitrary code execution is possible. Similar attacks may be possible for other operating systems and/or different browser preferences. Although this exploit requires clicking a malformed link to work, I think it would be quite easy to catch people out, with potentially dire consequences. For this reason I am announcing this privately rather than on the bug tracker or a public mailing list. Please let me know what you think. Matt
From: Lubomir Kundrak Hi Peter, Thanks for the information. We are not going to consider this to be a security bug, because (as you noted), the URL opener is gnome-open, not firefox directly and we believe it to be safe.
