Symantec Intel Handler Service Remote DoS

ID CORE-2010-0728
Type coresecurity
Reporter Core Security
Modified 2010-12-13T00:00:00


Core Security - CoreLabsSymantec Intel Handler Service Remote DoS

1. Advisory Information

Title: Symantec Intel Handler Service Remote DoS
Advisory Id: CORE-2010-0728
Advisory URL:
Date published: 2010-12-13
Date of last update: 2010-12-13
Vendors contacted: Symantec
Release mode: User release

2. Vulnerability Information

Class: Input validation error [CWE-20]
Impact: Denial of service
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2010-3268
Bugtraq ID: N/A

3. Vulnerability Description

The Intel Alert Handler service (hndlrsvc.exe) fails to correctly process the 'CommandLine' field in the AMS request. A source address in a MOV instruction is calculated from values present in the request, causing a remote denial-of-service.

4. Vulnerable packages

  • Symantec Antivirus Corporate Edition (Windows 2000 SP4).
  • Older versions are probably affected too, but they were not checked.

5. Non-vulnerable packages

6. Vendor Information, Solutions and Workarounds

The Intel Alert Management System is only present in versions of Symantec Endpoint Protection previous to 11.x. During the SEP 11.x engineering phase SEP was rewritten so that it no longer uses Intel AMS code. The installation of AMS is disabled by default for SEP versions that include it. The only workaround is to disable Intel AMS.

7. Credits

This vulnerability was discovered and researched by Nahuel Riva from Core Security Technologies. Publication was coordinated by Jorge Lucángeli Obes.

8. Technical Description / Proof of Concept Code

The request is handled in prgxhndl.dll, called from hndlsrvc.exe, more specifically from function 0x501A105D:

    501A105D  /. 55             PUSH EBP
    501A105E  |. 8BEC           MOV EBP,ESP
    501A1060  |. 81EC 60040000  SUB ESP,460
    501A1066  |. 8D45 F4        LEA EAX,DWORD PTR SS:[EBP-C]
    501A1069  |. 57             PUSH EDI
    501A106A  |. 50             PUSH EAX
    501A106B  |. 68 34301A50    PUSH prgxhndl.501A3034                   ;
    ASCII "CommandLine"
    501A1070  |. FF75 0C        PUSH DWORD PTR SS:[EBP+C]
    501A1073  |. 8BF9           MOV EDI,ECX
    501A1075  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]
    501A1078  |. E8 33010000    CALL

Inside that function, GetStringAMSHandler() is called to parse the content of the 'CommandLine' field present in the request. In turn, GetStringAMSHandler() forwards the request to function AMSLIB.18 present in AMSLIB.dll, and this function ends up calling the function that crashes, AMSGetPastParamList(), also in AMSLIB.dll:

    500733AE  |. 8B45 E4        MOV EAX,DWORD PTR SS:[EBP-1C]
    500733B1  |. 50             PUSH EAX
                               ; /Arg1
    500733B2  |. E8 54F3FFFF    CALL AMSLIB.AMSGetPastParamList
                               ; \AMSGetPastParamList

The crash occurs at address 0x5007278B:

    50072786  |. 8B45 F0        |MOV EAX,DWORD PTR SS:[EBP-10]
    50072789  |. 33C9           |XOR ECX,ECX
    5007278B  |. 8A08           |MOV CL,BYTE PTR DS:[EAX]
    5007278D  |. 85C9           |TEST ECX,ECX
    5007278F  |. 75 16          |JNZ SHORT AMSLIB.500727A7

When trying to read at the memory area pointed to by EAX, this value is invalid and the service crashes. This part of the code is parsing (inside a loop) the argument passed in the 'CommandLine' parameter. It seems that in many parts of the loop the pointer that is loaded from [EBP-10] is calculated from a value present in the request.

9. Report Timeline

  • 2010-08-12: Initial notification sent to Symantec.
  • 2010-08-19: Given that there was no answer since the initial notification, Core requests a confirmation of reception.
  • 2010-08-19: Vendor replies that the initial notification was not received.
  • 2010-08-20: Core resends original advisory draft.
  • 2010-08-20: Vendor acknowledges reception of advisory draft.
  • 2010-08-25: Vendor replies that the issue looks like a duplicate of another one, already planned to be fixed in a September/October timeframe. Vendor will investigate further and give a definite reply.
  • 2010-08-26: Core acknowledges this reply.
  • 2010-08-26: Vendor confirms that the issue is a duplicate, but will give credit to Nahuel Riva as "secondary finder". Vendor asks to postpone the publication of the advisory until a fix is released.
  • 2010-08-27: Core agrees to postpone the publication of the advisory, given that an estimate release date for the fix is provided.
  • 2010-08-27: Vendor replies with an estimated release date for the end of September.
  • 2010-08-27: Core agrees with the estimated release date, and requests the date of the initial report of the vulnerability.
  • 2010-09-09: After two weeks with no replies, Core again requests the date of the initial report of the vulnerability, and asks if the release of the fix is still on track for the end of September.
  • 2010-09-16: Vendor replies that they will not be able to release fixes before the end of the year, as they have to correct third-party code by themselves.
  • 2010-09-21: Core requests confirmation that the vendor won't release a fix before the end of the year.
  • 2010-09-22: Vendor confirms that they won't be able to release fixes until the end of the year, as fixing third-party code is taking time. However, the vendor explains that current versions of the product have the vulnerable functionality disabled, that old versions of the product do not install the vulnerable functionality by default, and that installation of this functionality is not recommended.
  • 2010-10-05: Core requests version numbers for vulnerable and non-vulnerable versions of the software, and asks if vulnerable users can update to a non-vulnerable version.
  • 2010-09-06: Vendor replies with the version numbers and confirms that vulnerable users have to wait for the patch.
  • 2010-10-07: Core decides to push the release date forward and wait for the release of the patch.
  • 2010-10-22: Core asks Symantec for a precise release date for the fixes, and explains that the publication of the advisory won't be pushed further than December 2010.
  • 2010-10-23: Vendor replies that the last known date was during December, and that they will confirm a firmer date.
  • 2010-11-01: Core asks Symantec if a firmer release date has been confirmed.
  • 2010-11-03: Vendor replies that the engineering team has not confirmed a release date, and asks if Core can hold the publication of the advisory until the end of the year.
  • 2010-11-25: Core replies that the December 13th release date is fixed, and requests an update on the status of the patches.
  • 2010-12-13: No update received, advisory CORE-2010-0728 is published.

10. References

11. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: <>.

12. About Core Security Technologies

Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at <>.

13. Disclaimer

The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: <>

14. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at /legacy/files/attachments/core_security_advisories.asc.