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.