Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4243 to the following vulnerability: 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 allow remote attackers to have an unspecified impact via a crafted media file that uses HTTP chunked transfer coding, related to an "overflow." References: http://service.real.com/realplayer/security/01192010_player/en/ http://xforce.iss.net/xforce/xfdb/55796
Upstream patch: http://lists.helixcommunity.org/pipermail/filesystem-cvs/2008-January/000676.html https://helixcommunity.org/viewcvs/filesystem/http/httpfsys.cpp?view=log#rev1.113 According to upstream, this issue does affect Helix Player 1.x. Patch changes the code to use strtol instead of the strtoul and checks whether the value returned is not negative. When using strtoul, pChunkedEncoding->size can be set to ULONG_MAX and can lead to integer overflow / insufficient buffer allocation in: pChunkedEncoding->buf = new char[pChunkedEncoding->size + 1]; 1.0.x versions of Helix Player including the latest one - 1.0.9 - available from the upstream download page does, however, still use strtol and uses signed long for the size member of the HTTPChunkedEncoding. Change to unsigned long / strtoul was only introduced after 1.0.9. With signed type, size can be LONG_MAX at max, which does not lead to an integer overflow when 1 is added to it. Negative size is also caught and results in error return code from CHTTPFileObject::DecodeChunkedEncoding. The code in 1.0.x looks as: pChunkedEncoding->size = strtol(pChunkedEncoding->buf, &errstr, 16); if (pChunkedEncoding->size > 0) { /* allocate / memset memory */ } else if (pChunkedEncoding->size == 0) { /* end of chunk header, change state to "expecting chunk body" */ } else { rc = HXR_FAILED; break; }