Bug 561361 (CVE-2009-4248) - CVE-2009-4248 HelixPlayer / RealPlayer: RTSP SET_PARAMETER buffer overflow
Summary: CVE-2009-4248 HelixPlayer / RealPlayer: RTSP SET_PARAMETER buffer overflow
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-4248
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://web.nvd.nist.gov/view/vuln/det...
Whiteboard:
Depends On:
Blocks: CVE-2009-0375, CVE-2009-0376, CVE-2009-4241, CVE-2009-4244, CVE-2009-4246
TreeView+ depends on / blocked
 
Reported: 2010-02-03 14:35 UTC by Tomas Hoger
Modified: 2019-09-29 12:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-09 11:06:56 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0094 0 normal SHIPPED_LIVE Critical: HelixPlayer security update 2010-02-09 10:14:30 UTC

Description Tomas Hoger 2010-02-03 14:35:14 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4248 to the following vulnerability:

Buffer overflow in RealNetworks RealPlayer 10, RealPlayer 10.5 6.0.12.1040
through 6.0.12.1741, RealPlayer 11 11.0.0 through 11.0.4, RealPlayer
Enterprise, Mac RealPlayer 10 and 10.1, Linux RealPlayer 10, and Helix Player
10.x allows remote attackers to have an unspecified impact via a crafted RTSP
SET_PARAMETER request.

References:
http://service.real.com/realplayer/security/01192010_player/en/
http://xforce.iss.net/xforce/xfdb/55801

Comment 2 Tomas Hoger 2010-02-03 15:15:37 UTC
Reading the patch pointed out by upstream, I fail to see the buffer overflow mentioned in the upstream advisory.  It adds couple of checks to avoid NULL pointer dereferences and check if strlen return value does not wrap to negative when assigned to 32bit signed integer variable.

Even negative contentLen shouldn't have any bad impact, as CHXBuffer::SetSize treats length as unsigned and BinFrom64() would not decode anything and rather return 0, resulting in the truncation of the buffer to size 0.  Looks like the only place where overflow can happen is some time later, if processing of the buffer set by m_pDataRevert->ControlBufferReady() has some problems with 0-sized buffers.

Comment 3 Tomas Hoger 2010-02-04 15:41:09 UTC
There is a possibility how overflow can happen in RTSPProtocol::HandleSetParameterRequest.  CHXBuffer class uses 2 types of storage for buffer - it has a short (15 character) static buffer that is used when short amount of memory is needed, or allocates needed buffer dynamically if more memory is needed.  When instance of this class is created as an empty buffer, it uses static buffer by default (e.g. when direct pointer to a storage area is requested using GetBuffer method).  SetSize(contentLen) may fail to allocate memory, but its return value is not checked.  Hence if an attacker can trigger a memory allocation failure, BinFrom64() will try to base64 decode input into the short CHXBuffer-internal buffer.

Comment 5 errata-xmlrpc 2010-02-09 10:15:54 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0094 https://rhn.redhat.com/errata/RHSA-2010-0094.html


Note You need to log in before you can comment on or make changes to this bug.