From shok@CANNABIS.DATAFORCE.NET Fri Sep 3 13:58:49 1999 From: Shok Resent-From: mea culpa To: BUGTRAQ@SECURITYFOCUS.COM Resent-To: jericho@attrition.org Date: Fri, 13 Aug 1999 11:01:58 +0400 Subject: w00w00's efnet ircd advisory (exploit included) [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!10chars@trivial) joins #199chars 2. Client 2 (trivial!trivial@trivial) joins #199chars 3. Client 1 sets mode #199chars +pio Client 2 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 [Part 2, "ircd hyb6 exploit" Application/OCTET-STREAM (Name: "ircdexp.tgz") 5KB] [Unable to print this part]