Symantec Intel Handler Service Remote Denial-of-Service

Credit: Core
Risk: Medium
Local: No
Remote: Yes

CVSS Base Score: 5/10
Impact Subscore: 2.9/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: None
Integrity impact: None
Availability impact: Partial

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security Technologies - CoreLabs Advisory Symantec Intel Handler Service Remote DoS 1. *Advisory Information* Title: Symantec Intel Handler Service Remote DoS Advisory Id: CORE-2010-0728 Advisory URL: [ te-dos] 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 Lucangeli 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 <JMP.&HNDLRSVC.#17_?GetString@AMSHandler@@QAEHPAXKPADPAPAD@Z> - -----/ 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 [ asc]. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - iEYEARECAAYFAk0GR4UACgkQyNibggitWa1iKQCfYtzFZOnNGpclzNZEDrwM08wr gwsAn2UYlqC0+IpliLAVTn/ItK4Sc3ne =Up/o -----END PGP SIGNATURE-----


Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2021,


Back to Top