[UNIX] BNC IRC Proxy Server Remote Buffer Overflow
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 11 Nov 2004 18:31:33 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
BNC IRC Proxy Server Remote Buffer Overflow
" <http://www.gotbnc.com/> BNC is an IRC (Internet Relay Chat) proxying
server under the GPL. It allows users to connect to chat servers by
bouncing off the computer which is running BNC. Basically, it forwards the
information from the user to the server and vise versa."
A buffer overflow vulnerability exhibit itself under certain conditions
when receiving replies from a remote IRC server.
* BNC version 2.8.9 and prior
* BNC version 2.9.0
When BNC is connected to an IRC server it will 'USER' and 'NICK' commands
whenever needed. The server's response is processed in part by the
getnickuserhost() function which contains a flaw allowing the buffer
overflow. The vulnerable code:
int getnickuserhost(char **argv,char *buf,char *fix)
if(buf[p] == '!')
if(buf[p] == '@')
The 'buf' variable points to a 512+1 static buffer (located in the BSS
segment) which contains the IRC server's response. The 'fix' variable
points to a some local stack buffer of 3 bytes. If the '!' or the '@'
characters are present in the server response (buf), they will be written
to 'fix'. The number of those characters that can be written into 'fix' is
not limited, hence leading to a possible buffer overflow.
The getnickuserhost() function is called from the following functions:
srv_nick(), ismenuh(), while ismenuh() is called from srv_part() and
process_join(), allowing for more than one code paths leading to the
vulnerable code. An example with the srv_nick() function is presented
int srv_nick(struct cliententry *cptr, char *prefix, int pargc, char
repc = getnickuserhost(nuh, prefix, repv);
if( prefix[p] == '\0' )
if(repc > 0)
Since the stack can only be overflowed using the '!' and '@' characters,
exploiting the buffer overflow might not be trivial. It could be exploited
with off-by-one or off-by-two frame overflow, but some partial EIP
overflow could also prove to be useful. It is also possible to overflow
the 'c' counter that could have some impact later in the loop.
The result of running the PoC code is listed below:
[root@laptop bnc2.8.9]# gdb ./bnc 11313
Program received signal SIGSEGV, Segmentation fault.
0x21212121 in ?? ()
eax 0x1 1
ecx 0x30 48
edx 0x30 48
ebx 0x21212121 555819297
esp 0xbffff790 0xbffff790
ebp 0x21212121 0x21212121
esi 0x21212121 555819297
edi 0x21212121 555819297
eip 0x21212121 0x21212121
eflags 0x210246 2163270
Naturally the BNC daemon dies and all users are disconnected. At the very
least the impact of this buffer overflow is a denial of service attack
against the BNC server.
The vendor has already released a fixed version which mitigates this
vulnerability. BNC version 2.9.0 can be downloaded or a patch can be
The information has been provided by <mailto:email@example.com> LSS
The original article can be found at:
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.