ActiveX Buffer Overruns Advisory 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. Protection: 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.a sp 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. Also, I haven't tried 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, I have shown how to simply RET to ExitProcess directly. This will cause the host to terminate.

============================================================ 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.

============================================================ 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.

============================================================ 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.

============================================================ 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.

============================================================ 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.

============================================================ 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 First year IT student at QUT, Brisbane, Australia. Sponsors?