w00w00's efnet ircd advisory (exploit included)

[shok () CANNABIS DATAFORCE NET (Shok)]

[http://www.w00w00.org, comments to shok () dataforce net]

SUMMARY
efnet ircd hybrid-6 (up to beta 58) have a vulnerability that can allow
remote access to the irc server.  In most cases, you'll gain privileges of
the 'irc' user.

COMMENTS
This vulnerability was discovered by jduck and stranjer of w00w00 at
least 2 months ago.  After discussing the vulnerability, it was reported
to Dianora by jduck and fixed.  Hopefully the vulnerable irc servers have
been fixed.  If not, it's unfortunate Dianora didn't notify the vulnerable
irc servers or they didn't take these 2 months to fix themselves (note:
we didn't wait that long on purpose.. we were just sidetracked with a
million other things).

DESCRIPTION
The vulnerability is in the invite handling code (m_invite).  In a
channels with operators (ops) and modes +pi (paranoid + invite-only), a
channel invitation is reported to all other operators.  The buffer used to
store the invitation notice can overflow its boundaries by up to 15
bytes.

Steps:
1. Client 1 (9chars!1. Client 1 (9chars!10chars@trivial) joins #199chars
2. Client 2 (trivial!2. Client 2 (trivial!trivial@trivial) joins #199chars
3. Client 1 sets mode #199chars +pio Client 2
4. Client 1 invites Client 3 (9chars!4. Client 1 invites Client 3 (9chars!10chars@63chars) to #199chars

Note: client 1 and client 3 should _not_ be from the same host.  With our
exploit, client 3 (compile/run hostname.c) first, then compile/run
ircdexp.c.

Client #1's server = vulnerable irc server (such as irc.arpa.com)
Client #2's server = trivial
Client #3's server = ComStud irc server (such as irc.prison.net), because
                     it allows shellcode chars in hostname

Using the following spoofed host (59 chars):
shellcodeshellcodeshellcodeshellcodeshellcodeshellcode.AAAA
[The ComStud ircd will check for a '.']

Here, EIP = 0x41414141 (AAAA).  The other registers are negligable.
The hostlen is actually 63 bytes, but for this specific overflow, EIP is
overwritten at buf[54-58].

We have to take stdout/stdin descriptors into consideration.  We are very
limited in size (only have 54 bytes for shellcode), so we can't fit bind
shellcode.  Instead, we took the standard Linux x86 shellcode, dropped
exit handling code, added a close'd stdin, dup'd cptr->fd (cptr is the
first argument passed to m_invite).  Since we only have 54 bytes to work
with, we can't fit code in to close stdout and dup cptr->fd, so output
will be sent to whatever terminald ircd was started from.  If you do not
wish for the output to be seen, redirect everything (via '>') /dev/null.

As for how to go about spoofing, you have options:
1) Use the old DNS poison caching method
2) Use custom "fake binds" that will just pass on your shellcode as a
   hostname in response to a DNS query (idea from nyt).

Option #2 is the approach we will take (hostname.c generates the shellcode
we'll use). This will work fine as long as you IP/hostname hasn't already
been cached.  Because these "fake binds" are pretty popular (or have been
in the past), they should be easy to come by and are outside the scope of
this advisory.

So full steps are, client with the spoofed hostname, connect to a ComStud
ircd server (such as irc.prison.net), another client join the arbitrary
client, and another client join the target ircd hybrid-6 server (such as
irc.arpa.com).  Once the channel is +pi (and your channel, ident,
username, etc. all the right length), invite the client with the spoofed
hostname.  Fine-tune until you have root.

Thanks to: stranjer and jduck for their input and discovery of this
vulnerability.

People that deserve hellos: Mike (mike () eEye com), vacuum
(vacuum () technotronic com), awr (andrewr () rot26 net), dmess0r
(dmessor () el8 org).

-- Matt Conover (Shok) & w00w00 Security Team

<!-- attachment="ircdexp.tgz" -->
<HR>
<UL>
<LI>APPLICATION/octet-stream attachment: ircdexp.tgz
</UL>