xorl %eax, %eax

irssi create_addr_conn() NULL Pointer Dereference

with 4 comments

Recently, Jesús Olmos (aka sha0) of Bugguroo Security reported a vulnerability which affects 0.8.15 and probably other releases too. I usually wait for any bug report I read to have an official CVE ID number before publishing a blog post, but in this case I’ll skip that part and just discuss the bug which is a fairly interesting one.
The vulnerable code path begins at src/core/servers-setup.c where the following routine resides.

create_addr_conn(int chat_type, const char *address, int port,
                 const char *chatnet, const char *password,
                 const char *nick)
        CHAT_PROTOCOL_REC *proto;
        SERVER_CONNECT_REC *conn;
        SERVER_SETUP_REC *sserver;
        CHATNET_REC *chatnetrec;
        proto = chat_type >= 0 ? chat_protocol_find_id(chat_type) :

        conn = proto->create_server_connect();
        return conn;

For better understanding of the vulnerability have a look at the ‘CHAT_PROTOCOL_REC’ structure definition located at src/core/chat-protocols.h header file.

        int id;

        unsigned int not_initialized:1;
        unsigned int case_insensitive:1;

        char *name;
        char *fullname;
        char *chatnet;

        CHATNET_REC *(*create_chatnet) (void);
        SERVER_SETUP_REC *(*create_server_setup) (void);
        CHANNEL_SETUP_REC *(*create_channel_setup) (void);
        SERVER_CONNECT_REC *(*create_server_connect) (void);
        void (*destroy_server_connect) (SERVER_CONNECT_REC *);

        SERVER_REC *(*server_init_connect) (SERVER_CONNECT_REC *);
        void (*server_connect) (SERVER_REC *);
        CHANNEL_REC *(*channel_create) (SERVER_REC *, const char *,
                                        const char *, int);
        QUERY_REC *(*query_create) (const char *, const char *, int);

So, mainly it’s a collection of callback functions. As sha0 pointed out, if the attacker makes a call similar to:


That he accidentally did in a Perl IRC bot he was coding, it will leave ‘proto’ pointer uninitialized since it will invoke chat_protocol_find_id() passing a value that will eventually return NULL as you can see below.

CHAT_PROTOCOL_REC *chat_protocol_find_id(int id)
        GSList *tmp;

        g_return_val_if_fail(id > 0, NULL);

        for (tmp = chat_protocols; tmp != NULL; tmp = tmp->next) {
                CHAT_PROTOCOL_REC *rec = tmp->data;

                if (rec->id == id)
                        return rec;

        return NULL;

The above snippet was taken from src/core/chat-protocols.c file and of course, if we manage to make g_return_val_if_fail() return NULL like sha0 did in his Perl IRC bot, the subsequent call to ‘proto->create_server_connect()’ will result in a NULL pointer dereference at the 0x20 offset.
Jesús Olmos who discovered this vulnerability suggests using a simple check against NULL for ‘proto’ pointer before using it but he also discusses an interesting approach for exploiting this vulnerability which you can find here.

Using Nelson Elhage’s CVE-2010-4258 vulnerability (which by the way has countless more uses) he could make a call like:

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

To bypass the check on unpatched Linux systems. In addition, we must also consider the numerous users that use irssi as their IRC client on other operating systems such as BSD derivatives, Windows, Solaris etc. It’s an interesting bug since if you’re able to map some code to the 0x20 offset a function pointer is used to call that address immediately.

Written by xorl

February 1, 2011 at 19:47

Posted in vulnerabilities

4 Responses

Subscribe to comments with RSS.

  1. “if the attacker makes a call similar to”
    If the attacker can make such a call, he has no reason to exploit anything, he’s already in.

    As I just noted on the bug report (http://bugs.irssi.org/index.php?do=details&task_id=790), this is no security problem, not even a bug.

    Wouter Coekaerts

    February 6, 2011 at 22:40

  2. This blog post is completely wrong but I didn’t bother updating it since spender did my work and let people know that it was incorrect. :)
    Thanks for the info anyway Wouter Coekaerts


    February 7, 2011 at 05:39

  3. Hello friends (and spender),

    The Keen Observer team has been away on business for a few months, idly managing to read only titles of blog posts here. I see that Brad has managed to make continuous attempts at mockery of the efforts xorl makes with this blog.

    Firstly, I would request that Brad explore other avenues outside of mmap_min_addr and NULL dereferences. It’s a small wonder why his enlightenment framework was his latest and greatest piece of work, (where before this, only a few trivial bugs here/there were made public), with grsecurity being his sole claim to fame (techniques pipacs is mostly uncredited for)

    Secondly, I see that Mr. Oberheide, and Mr. Rosenberg (Linux kernel bug famewhores, that rally around Brad) have recently managed to make a grand public mockery of themselves at a conference, claiming to bypass grsec/pax (Don’t know much about the affair). I’m glad that they finally came out of the closest with their level of skill, using artificial and antiquated means to try to gain five minutes of fame. (I’m sure Daniel is making strides to circumvent this general opinion by releasing kernel patches with x86 asm he stole off tavis, en-masse), and killing bugs with minimal { severity, elegance of dscovery (grep grep grep), elegance of exploitation }

    It’s nice to be back. But, the team at Keen Observer has got many things on our plates for the time being, the “scene” and the “sceners” are truly a bore at this point. My personal joy, for now, is being able to learn new things that Daniel and John don’t have the creative or intellectual ability to emulate without phrack papers, and irc.oftc.net/#grsecurity, along with a $50,000 CS degree.

    So, with this, we raise our glasses, salut!

    Keep killing weak bugs
    Keep writing stupid famewhore shit in comment
    Keep making grasps for glory.

    None of the more capable people we ally with are even interested in owning you, for one reason. You release everything you’ve got, which counts for rather little in terms of actual skill.

    And since you won’t ever shut up. Eventually, all you’ll do is put yourself to public shaming.

    Please be safe!

    The Keen Observer team.

    Keen Observer

    May 25, 2011 at 01:47

  4. I won’t comment any of your writings above.

    I just want to say, nice to see you’re back. :)


    May 25, 2011 at 20:50

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s