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 Linux
  • Severity Medium
  • Priority Normal
  • Reported Version irssi 0.8.15
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by Jesus Olmos (sha0) - 2011-02-01
Last edited by Wouter Coekaerts (coekie) - 2011-02-06

FS#790 - null pointer derreference at create_addr_conn()

//// jolmos at security advisory and patch


There is an explotable null pointer derreference at create_addr_conn()

From a perl script, i created:


Which ip parameter is incorrect, first param is chat_type.

Then, on create_addr_conn() there is a problem calculating the proto structure for this buggy chat_type:

proto = chat_type >= 0 ? chat_protocol_find_id(chat_type) :

chat_type is > than 0 then, chat_protocol_find_id(evil_chat_type) is called, and return null becouse of: g_return_val_if_fail(id > 0, NULL);

Then proto will be setted to null.
proto struct has some callbacks, at 0x20 is the create_server_connect() callback.

proto is null, then this call will fail:

conn = proto->create_server_connect();

in asm:

0x80daccc: call 0x80ca2d0 <chat_protocol_find_id>
0x80dacd1: mov %eax,%edx <--- eax and edx will be null
0x80dacd3: mov %edx,-0x24(%ebp) <---- save edx
0x80dacd6: call *0x20(%edx) <----- call [0x00000020] It will jump to the address dereferenced on 0x00000020


proto struct should be checked for null case after chat_procotl_find_id() call, here is the patch:

diff ./src/core/servers-setup.c ./src/core/servers-setup_ok.c
> if (proto == NULL)
> return NULL;


This vulnerability is a null pointer derreference, is necesary to create the _CHAT_PROTOCOL_REC struct on the 0x00000000 address of the irssi process, but this
address is not user space, then cannot be allocated.
The linux kernel access_ok() function checks if an address is an user-space address or not. There is a flaw on this kernel function (CVE-2010-4258),
This kernel flaw, lets map 0x00000000 address from a thread maked with a some special flagged clone() call:

clone((int (*)(void *))kernel_access_ok_bypass, (void *)((unsigned long)stack), CLONE_VM | CLONE_CHILD_CLEARTID | SIGCHLD, NULL, NULL, NULL, target);

Once 0x00000000 is allocated, we have to write any writable address on 0x00000020 for example stack where is the shellcode waiting to be called.

IMHO: Is not an interesant attack vector, and 0x00 only can be mapped locally but sholud be corrected.

Jesús Olmos aka sha0 from

contact emails: jolmos[at], and sha0[at]

This task does not depend on any other tasks.

Closed by  Wouter Coekaerts (coekie)
Sunday, 06 February 2011, 20:27 GMT
Reason for closing:  Not a bug
Wouter Coekaerts (coekie)
Thursday, 03 February 2011, 09:35 GMT
I don't see how this problem is security-related. This cannot be exploited remotely, right?
The only way to abuse this if you are a local user that can execute Perl code, and then after exploiting this, you gain the privilege to execute code, which you already had.

By this reasoning Irssi::command is a huge security hole, because it can directly execute any command you want!

Please enlighten me if I'm missing something here...
Jesus Olmos (sha0)
Thursday, 03 February 2011, 09:47 GMT
For example, here are alot of scripts, if you submit one plugin with something like exec('rm -rf /') people will detect that is a malicious plugin.
But what about a Irssi::server_create_conn('',6667,'','',''); people will think the first parameter is the ip and it's ok, and the attacker will recive reverse shells.

I understand that is not a direct attack vector, I have not submitted this issue to bugtrac, but I think it should be solved, the problem is on core and can be other execution paths.

Wouter Coekaerts (coekie)
Sunday, 06 February 2011, 20:27 GMT
The steps needed to get malicious code at the address that server_create_conn execute will execute will look a lot less innocent.
I'm sure there are a lot less far-fetched ways to execute code at a certain address.
Irssi's scripting interface doesn't try to be (much) safe(r than C code). Passing bad values to functions will cause bad behaviour; nothing unexpected there.