From bugtraq irssi 0.8.9 release fixes a vulnerability that allows normal IRC users to remotely crash another user's irssi client, provided that either of these conditions is met: a) irssi is running on an architecture that requires memory alignmentation (ie. not x86) b) "gui print text" signal is being used by some script or plugin. There's two scripts in scripts.irssi.org which do this: nicklist.pl and tab_stop.pl. The bug also enables another minor annoyance to all irssi users: being able to remotely change the message's "level". For example to set it highlighted so it shows up with /last -hilight command. Thanks to Rico Gloeckner for finding out this problem and Wouter Coekaerts for debugging it. Details ------- The problematic call was in src/fe-common/core/formats.c: void format_send_to_gui(TEXT_DEST_REC *dest, const char *text) .. case FORMAT_STYLE_INDENT_FUNC: { const char *start = ptr; .. signal_emit_id(signal_gui_print_text, 6, dest->window, NULL, NULL, GINT_TO_POINTER(GUI_PRINT_FLAG_INDENT_FUNC), str, start, dest); The "str" parameter wasn't supposed to be there, so signal handlers treated "start" (user given string) as "dest" and allowed faking dest's contents. The good thing here is that by default irssi doesn't modify dest's content in any signal handler, so arbitrary code execution isn't possible. By default only dest->level is read. Code design rant ---------------- There are two design problems in irssi which allowed this bug to happen: 1) Allowing remote clients to use irssi's internal text formatting functions. Simple fix would be to just drop ^D character in input. Right fix would be to separate the input data and formatting completely from each others. Anyway, I don't think this is much of a problem so I didn't change anything yet. 2) Lack of type safety in signal API. The current API was easy to implement and use, but it was done at the cost of safety. There are a few ways this could be fixed (mentioned in irssi rewrite plan), but it's a huge job. -------------------- As stated, this affects non-x86. This is just an ebuild update. I can probably update it this evening, unless the maintainer ( gregf@gentoo.org has been maintaining it appears) wants to. Cheers, -Dave Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 22061 [details] Updated irssi ebuild Minor change to rhapsody/darwin config. I have no way to test it on either however the configure script no longer uses the variable being altered with the patch. Tested on x86. -Dave
Forgot to remove the cvs header in the attached ebuild, I'm also not sure what to change this status to if anything. -Dave
upgrade to 0.8.9.
irssi-0.8.8-configure.patch needs to be updated for 0.8.9. Currently there is no configure patch for 0.8.9 and Irssi refuses to compile for me. Also, the changes introduced in Bug #33603 have not made it into the new irssi-0.8.9.ebuild.
TODO: send out GLSA
I've fixed Niklas's reported problems above and marked 0.8.9 stable on x86, alpha and ia64. The only thing left is to do the GLSA, which I'll let the security team handle.
For some reason I get the feeling that no GLSA is going to be sent out over this. The security team is very small and has limited amount of people that do the GLSA side of things. With 2004 here now we will be looking into recruiting more devs that are also technical writers. (In house devs are welcome to join in on the fun) Each herd is also always welcome to prep a GLSA (xml||txt) for sending.
I'd be happy to write a GLSA out - this will have to go after all the kernel stuff though.
Did this one get overlooked again?
I think that only thing that needs to be done is the GLSA by the looks of it
Sending out a GLSA at this point would probably not add much value -- the patched version has been stable for months now. We overlooked this one, shame on us. We do have 2-3 new security bug wranglers on staff now, so hopefully they'll help ensure this doesn't happen again. closing.
