Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4248 to the following vulnerability:
Buffer overflow in RealNetworks RealPlayer 10, RealPlayer 10.5 220.127.116.110
through 18.104.22.1681, 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
According to upstream, relevant upstream fixes are:
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.
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.
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