Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/ : eval()'d code on line 90
  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category core
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Normal
  • Reported Version Irssi SVN
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by nemo (nemo) - 2009-04-05
Last edited by Jilles Tjoelker (jilles) - 2009-05-15

FS#662 - event_wallops() underflow resulting in out of bounds read/write.

So basically there is a vulnerability present in the "event_wallops()" function in fe-common/irc/fe-events.c.

static void event_wallops(IRC_SERVER_REC *server, const char *data, const char *nick, const char *addr)
g_return_if_fail(data != NULL);

if (*data == ':') data++;
if (ignore_check(SERVER(server), nick, addr, NULL, data, MSGLEVEL_WALLOPS))

if (g_ascii_strncasecmp(data, "\001ACTION ", 8) != 0)
printformat(server, NULL, MSGLEVEL_WALLOPS, IRCTXT_WALLOPS, nick, data);
else {
/* Action in WALLOP */
int len;
char *tmp;

tmp = g_strdup(data+8);
len = strlen(tmp); // -( nemo )- :: If strlen(tmp) is 0.
if (tmp[len-1] == 1) tmp[len-1] = '\0'; // -( nemo )- :: This is an underflow.
printformat(server, NULL, MSGLEVEL_WALLOPS, IRCTXT_ACTION_WALLOPS, nick, tmp);

I've had it for a while but have been unable to exploit it. I have verified that it's basically a 1 bit toggle on the heap. On heap implementations without meta data between chunks this means you are able to toggle the value 0x1 at the end of a previous chunk to a 0x0. A couple of possible uses i could see were to drop the reference count for a particular struct on the heap, or possibly toggle the connection_established bit in one of the dcc related structs. However i was never able to accomplish either of these.

# (gdb) x/2i $pc
# 0x200d9 <event_wallops+246>: repnz scas al,BYTE PTR es:[edi]
# 0x200db <event_wallops+248>: not ecx
# (gdb) i r ecx
# ecx 0x1 1
# (gdb) x/i $pc
# 0x200dd <event_wallops+250>: lea eax,[ecx+esi-1]
# (gdb) x/2i $pc
# 0x200e1 <event_wallops+254>: cmp BYTE PTR [eax-1],0x1
# 0x200e5 <event_wallops+258>: je 0x2012e <event_wallops+331>
# (gdb) x/i 0x2012e
# 0x2012e <event_wallops+331>: mov BYTE PTR [eax-1],0x0

As you can see, this is definitly a triggerable read/write outside the bounds of the allocated buffer and
should therefore be fixed.

I simply used a fake IRCd written in python which responded with:

evilstr = ": WALLOPS \001ACTION "

Upon joining to trigger this.

Hopefully this information is useful to you.



This task does not depend on any other tasks.

Closed by  Jilles Tjoelker (jilles)
Friday, 15 May 2009, 11:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in r5068
Wouter Coekaerts (coekie)
Sunday, 05 April 2009, 21:21 GMT
Nice catch.

Strictly speaking, this is a security issue, but - correct me if I'm wrong here - given that
1. it requires a theoretic exploiter to be an ircop or malicious server
2. it's (probably) impossible to exploit in practice
3. if it turns out it is exploitable anyways, it'll (probably?) just be a crash, so a denial of service attack

I don't think we should treat this as a security issue with real risk (making a new release asap,...).

We will fix it for the next release of course.

Thanks for the report.
nemo (nemo)
Sunday, 05 April 2009, 21:58 GMT
Hey Wouter,

Thanks for the quick response.
I agree, the likelihood for mass exploitation is very very small.

1.) I think it's quite easy in practice to convince someone to join a different ircd, so that's not too much of an issue.
2.) I wouldn't say impossible, but highly unlikely. I'd personally love to see someone write an exploit for this issue, just because all the circumstances are stacked against their favor.
3.) It's hard to say really, if someone managed to find something worthwhile and position it on the heap i wouldn't rule out code execution.

I think also the fact that this is impossible to exploit on most of the bigger heap implementations due to the meta data between chunks makes it much less of a worry. I agree that there's no reason to make a release specifically for this.

Glad to help,

- nemo