Bug 853321 (CVE-2011-5129)

Summary: CVE-2011-5129 xchat: Heap-based buffer overflow (crash, ACE) via long response string
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Stefan Cornelius <scorneli>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: caillon, jlieskov, jrb, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-05 06:37:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 853449    

Description Kurt Seifried 2012-08-31 04:12:13 UTC
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:

http://xchat.org/files/source/2.8/

Comment 2 Jan Lieskovsky 2012-08-31 14:55:39 UTC
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.

References:
http://www.securityfocus.com/bid/50820
http://www.osvdb.org/77629
http://www.exploit-db.com/exploits/18159/
http://packetstormsecurity.org/files/107312/xchat-dos.txt
https://bugzilla.novell.com/show_bug.cgi?id=778254

Comment 4 Huzaifa S. Sidhpurwala 2012-09-05 06:11:01 UTC
I dont think this is really a flaw at all. Looking at xchat source, the following should prevent any buffer overflow.

static gboolean
server_read (GIOChannel *source, GIOCondition condition, server *serv)
...
...
                        default:
                                serv->linebuf[serv->pos] = lbuf[i];
                                if (serv->pos >= (sizeof (serv->linebuf) - 1))
                                        fprintf (stderr,
                                                                "*** XCHAT WARNING: Buffer overflow - shit server!\n");
                                else
                                        serv->pos++;

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.

Comment 5 Huzaifa S. Sidhpurwala 2012-09-05 06:37:02 UTC
Statement:


This bug is not a security issue. For detailed explanation, refer to: 
https://bugzilla.redhat.com/show_bug.cgi?id=853321#c4