Subject: irssi - potential remote crash 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.