Message-ID: <4D06478F.9010803@coresecurity.com>
Date: Mon, 13 Dec 2010 13:19:27 -0300
From: Core Security Technologies Advisories <advisories@...esecurity.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: [CORE-2010-0728] Symantec Intel Handler Service Remote Denial-of-Service

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

      Core Security Technologies - CoreLabs Advisory
           http://corelabs.coresecurity.com/

Symantec Intel Handler Service Remote DoS



1. *Advisory Information*

Title: Symantec Intel Handler Service Remote DoS
Advisory Id: CORE-2010-0728
Advisory URL:
[http://www.coresecurity.com/content/symantec-intel-handler-service-remote-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 10.1.4.4010 (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@...Handler@@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:
[http://corelabs.coresecurity.com].


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
[http://www.coresecurity.com].


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: [http://creativecommons.org/licenses/by-nc-sa/3.0/us/].


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
[http://www.coresecurity.com/files/attachments/core_security_advisories.asc].
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0GR4UACgkQyNibggitWa1iKQCfYtzFZOnNGpclzNZEDrwM08wr
gwsAn2UYlqC0+IpliLAVTn/ItK4Sc3ne
=Up/o
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists