Red Hat Bugzilla – Bug 853321
CVE-2011-5129 xchat: Heap-based buffer overflow (crash, ACE) via long response string
Last modified: 2016-03-04 06:33:20 EST
A remotely exploitable Denial of service was reported in xchat 2.8.8 and
earlier on KDE.
Specifically when an xchat client connects to a server and a large string
is sent by the server the xchat program will crash.
Unfortunately xchat 2.8.9 is only available as a Windows binary, source
code for 2.8.9 does not appear to be in the xchat site:
National Vulnerability Database (NVD) entry:
Heap-based buffer overflow in XChat 2.8.9 and earlier allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long response string.
I dont think this is really a flaw at all. Looking at xchat source, the following should prevent any buffer overflow.
server_read (GIOChannel *source, GIOCondition condition, server *serv)
serv->linebuf[serv->pos] = lbuf[i];
if (serv->pos >= (sizeof (serv->linebuf) - 1))
"*** XCHAT WARNING: Buffer overflow - shit server!\n");
The data read from the server is stored in lbuf, whose size is 2050 bytes. Data is read via:
len = _SSL_recv (serv->ssl, lbuf, sizeof (lbuf) - 2);
The total data which is read from the server really is just 2048 bytes.
Later in the loop each bye from lbuf is copied into the serv->linebuf buffer and the position of the copied byte is stored in serv->pos.
serv->pos may not be zero when the data is copied into serv->linebuf.
In the above piece of code, if serv->pos (The place where data needs to be copied into the serv->linebuf, stack buffer), exceeds the size of lbuf, it prints a warning message on stderr and does not increment serv->pos.
So any new data to be read from lbuf, is copied into the last value of serv->pos, leading to no buffer overwrite.
This bug is not a security issue. For detailed explanation, refer to: