icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

[R1] HP LoadRunner Multiple Remote DoS



HP LoadRunner contains multiple flaws related to packet handling that can lead to a remote DoS, or one that could possibly lead to remote code execution, although that was not tested extensively.

#1: Multiple Service Connection Request xsr_string Field Handling NULL Pointer Dereference Remote DoS (HPSBGN03609 / CVE-2016-4361)

Affected: 11.52, 12.02. Not Affected: 12.50

Based on limited testing, since it appears to be fixed in the latest version, it is possible to trigger a NULL pointer dereference when sending the same packets to a combination of services based around magentservice.exe (the agent listens on multiple TCP ports including 54345, 50500, and 5003) and the xdr_string field in a connection request message. This was trivially reproduced by using Nessus with thorough_tests enabled, specifically the loadrunner_agent_detect.nasl, loadrunner_agent_service_ip_name_overflow.nasl, and hp_loadrunner_cve-2013-4800.nasl plugins.

(cd8.ccc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\HP\LoadRunner\launch_service\bin\launcher.dll - 
eax=00000000 ebx=01a51940 ecx=8184f62f edx=70011000 esi=01a51a58 edi=01a51a58
eip=6ccc91d8 esp=021de114 ebp=01a519e8 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
6ccc91d8 8b00            mov     eax,dword ptr [eax]  ds:0023:00000000=????????

#2: Malformed Packet Handling Remote DoS (HPSBGN03609 / CVE-2016-4361)

Affected: 9.5. Not Affected: 10.50, 12.02

A malformed packet set to TCP port 5001 or TCP port 5002 causes the crash. As of version 12.02), the service no longer listens on those ports effectively 'fixing' the issue. This can be performed using Nessus with thorough_tests enabled. Since fixed in the latest version, further testing was not performed.

#3: mchan.dll Packet Handling Invalid Memory Access Remote DoS (HPSBGN03648 / CVE-2016-4384)

Affected: 11.52, 12.02, 12.50

By sending a specially crafted packet to the LoadRunner agent listening on TCP port 54345, a remote attacker can crash the service. A "-server_type=6" request (LinkList server) without a "ll_server_index=..." declaration in a connection request triggers the invalid memory access, possibly due to ll_server_index being uinitialized. This has not been fully tested to determine if remote code execution is possible.

(658.33c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=9b7e9a20 ebx=01e4dcf8 ecx=003f7558 edx=00000434 esi=fffffffd edi=003f7558
eip=6f2a8851 esp=01e4dc68 ebp=01e4dcf8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
6f2a8851 8b10            mov     edx,dword ptr [eax]  ds:0023:9b7e9a20=????????

A quick note on the CVE assignments. Working with HP on these issues has been extremely frustrating on many levels (see the horrendous timeline below). Once both HP advisories were out, we used them to determine that the CVE assignments were sloppy at best. Ultimately, CVE-2016-4361 (SSRT102274) should have represented all three issues in this advisory. However, when HPSBGN03648 was published with CVE-2016-4384, looking at the affected / fixed versions tells us that represents #3. So CVE-2016-4361 would actually cover #1 and #2 in this advisory. Here is the breakdown including our internal tracking numbers:

CVE-2016-4359 (PSRT110020, ZDI-CAN-3516 / ZDI-16-363) = TRA-13 = TRA-2016-16
CVE-2016-4360 (PSRT110032, ZDI-CAN-3555 / ZDI-16-364) = TRA-27 = TRA-2016-17
CVE-2016-4361 (SSRT102274) = TRA-14 #1 / #2 / #3 = TRA-2016-26
CVE-2016-4384 (PSRT110230) = TRA-14 #3  = TRA-2016-26

We are fairly confident that HP's internal records do not match this, but since we are the ones policing a CNA for not doing proper CVE assignments and us being involved with all of these disclosures, we are clearly stating the above to be the definitive CVE assignments.


HPE has released Performance Center v12.53 and LoadRunner v12.53 / v12.50 patch 3 to address these issues, we think. HPSBGN03648 says that "all versions prior to v12.50" are affected, implying 12.50 is the fix. However, they then say 12.50 patch 3 is the fix, implying 12.50 is vulnerable. We fully encourage you to reach out to HP and ask them for clarity if this impacts your organization.

Disclosure Timeline

2015-09-10 - Issues tested against latest version
2015-09-30 - Reported to HP via security-alert@hp.com
2015-09-30 - HP replies, assigns SSRT102274
2015-11-24 - Ping vendor for update
2015-11-24 - HPE (they gained a letter) reports no movement, will ping Dev team again
2015-12-04 - HPE replies, still under investigation
2016-02-17 - Ping vendor for update
2016-02-19 - Vendor replies, will get status by Monday
2016-03-15 - Ping vendor for update
2016-03-22 - Vendor replies, waiting for update, PSRT110020 has been assigned
2016-04-14 - Ping vendor for update
2016-04-15 - Vendor replies, "R&D Team is still working on the remediation"
2016-05-16 - Ping vendor for update
2016-05-17 - Vendor replies "patch release in final steps and should be released in next few days"
2016-05-18 - Vendor says plan is to release fix by end of May.
2016-05-31 - Vendor releases fix and advisory
2016-06-10 - Ask vendor about CVE assignment uncertainty
2016-06-13 - Vendor ACKs mail, will look into it
2016-06-22 - Ask vendor for update about CVE assignment
2016-06-22 - Vendor says they had a meeting today, working on request...
2016-07-05 - Vendor re-states the obvious, does not answer question.
2016-07-05 - Ask vendor for clarity, explain the question again
2016-07-14 - Vendor sends a list of CVE to PSRT/SSRT breakdown, still does not resolve question
2016-07-14 - Ask vendor for clarity, ask to be put in touch with who actually did the assignment
2016-07-15 - Vendor sends longer mail that still ignores the outstanding question
2016-07-15 - Tenable replies, enumerating the confusion very clearly, asks for the CVE assignments that appear to be missing
2016-07-18 - HPE says they assign "for any new vulnerabilities reported to us", will confirm and get back to us on this assignment.
2016-08-08 - Ping vendor for update on assignments.
2016-08-09 - HPE replies, still waiting for feedback from R&D.
2016-08-18 - Tenable reminds HPE that 'coordinated disclosure' is a two-way street, and HPE did not coordinate this release. Informs them that we will publish our advisory in the coming weeks since they already published theirs.
2016-08-20 - HPE says current plan is to release a new advisory for the two issues in question.
2016-08-26 - HPE says still working to finalize bulletin content.
2016-09-16 - HPE says Product Engineering team has approved content, will publish bulletin next week.
2016-09-20 - HPE releases HPSBGN03648 without coordinating our own advisory. Mentions one remote DoS, leaving us with 4 CVE and 3 issues.
2016-09-21 - Tenable spends 30 minutes doing deductive reasoning to figure out CVE assignments, which likely doesn't jibe with HP internally.

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com