[NT] Multiple Vendor Insecure use of CreateProcess()

From: SecuriTeam (support_at_securiteam.com)
Date: 11/21/05

  • Next message: SecuriTeam: "[NT] Multiple Vendor Antivirus Software Fails to Access Maliciously Named Files" 
    To: list@securiteam.com
Date: 21 Nov 2005 17:14:51 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Multiple Vendor Insecure use of CreateProcess()
    ------------------------------------------------------------------------

    SUMMARY

    The Microsoft Windows API includes the
    <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp> CreateProcess() function as a means to create a new process and it's primary thread.

     
    <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocessasuser.asp> CreateProcessAsUser() is similar but allows for the process to be run in the security context of a particular user.

    Improper use of Windows API command CreateProcess allows attackers to
    execute arbitrary programs with in Microsoft's Windows.

    DETAILS

    Vulnerable Systems:
     * RealPlayer version 10.5
     * Kaspersky Anti-Virus for Windows File Servers version 5.0
     * iTunes version 4.7.1.30
     * VMWare Workstation version 5.0.0 build-13124
     * Microsoft Antispyware version 1.0.509 (Beta 1)

    The format of the CreateProcess() function is as follows:

    BOOL CreateProcess(
      LPCTSTR lpApplicationName,
      LPTSTR lpCommandLine,
      LPSECURITY_ATTRIBUTES lpProcessAttributes,
      LPSECURITY_ATTRIBUTES lpThreadAttributes,
      BOOL bInheritHandles,
      DWORD dwCreationFlags,
      LPVOID lpEnvironment,
      LPCTSTR lpCurrentDirectory,
      LPSTARTUPINFO lpStartupInfo,
      LPPROCESS_INFORMATION lpProcessInformation
    );

    The 'lpApplicationName' variable contains the name of the module to be
    executed. However, this can be a NULL value, in which case, the module
    name to be executed will be the first white space-delimited token in the
    lpCommandLine string.

    It is a known issue, that if lpApplicationName contains a NULL value and
    the full module path in the lpCommandLine variable contains white space
    and is not enclosed in quotation marks, it is possible that an alternate
    application will be executed. Consider the following scenario:

       CreateProcess(
          NULL,
          c:\program files\sub dir\program.exe,
          ...
       );

    In this case, the system will successively expand the string when
    interpreting the file path, until a module is encountered to execute.
    The string used in the above example would be interpreted as follows:

       c:\program.exe files\sub dir\program name
       c:\program files\sub.exe dir\program name
       c:\program files\sub dir\program.exe

    Therefore, if a file named program.exe existed in the c:\ directory, it
    would be executed instead of the intended application.

    Despite the fact that this is a known issue, several popular applications,
    insecurely call the CreateProcess() and CreateProcessAsUser() functions.
    This creates a scenario whereby arbitrary code could be executed. In the
    scenario detailed above, if an attacker were able to install arbitrary
    code in a file at c:\program.exe, when the vulnerable application was
    launched, the code would be executed. The arbitrary code would generally
    be executed under the privileges of the executing user but could also be
    launched with elevated privileges if an insecure call were made
    CreateProcessAsUser() using elevated privileges. This attack would involve
    some form of social engineering or need to be combined with another attack
    to first get the arbitrary code installed in the correct location.

    CVE Information:
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2936>
    CAN-2005-2936
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2937>
    CAN-2005-2937
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2938>
    CAN-2005-2938
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2939>
    CAN-2005-2939
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2940>
    CAN-2005-2940

    Disclosure Timeline:
    09/19/2005 - Initial vendor notification
    11/15/2005 - Coordinated public disclosure

    ADDITIONAL INFORMATION

    The information has been provided by
    <mailto:idlabs-advisories@lists.idefense.com> iDEFENSE.
    The original article can be found at:
    <http://www.idefense.com/application/poi/display?id=340&type=vulnerabilities> http://www.idefense.com/application/poi/display?id=340&type=vulnerabilities

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NT] Multiple Vendor Antivirus Software Fails to Access Maliciously Named Files"

    Relevant Pages