null pointer derreference at create_addr_conn()

[irssibot]

• • • Issue #790 opened by @sha0

  //// jolmos at buguroo.com security advisory and patch

== THE VULNERABILITY ==

There is an explotable null pointer derreference at create_addr_conn()

From a perl script, i created:

                Irssi::server_create_conn('80.249.66.107',6667,'','l23oi3','');

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_protocol_get_default();

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

== THE SOLUTION ==

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

231a232,234

  if (proto == NULL)
          return NULL;

== THE EXPLOIT ==

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.

== CRETDITS == Jesús Olmos aka sha0 from buguroo.com

contact emails: jolmos[at]buguroo.com, and sha0[at]badchecksum.net

[irssibot]

• • • Comment 1292 by @coekie

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...

[irssibot]

• • • Comment 1293 by @sha0

For example, here http://scripts.irssi.org/ 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('80.249.66.107',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.

regards.

[irssibot]

• • • Comment 1294 by @coekie

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.

[irssibot]

• • • Closed by @coekie