New IE Security Hole - And It's a Big One!
Tuesday August 24th, 1999
Yet another hole has been found in Internet Explorer's ActiveX implementation. This one allows arbitrary code to be written to the user's hard-drive. The bug was found by Georgi Guninski, who has found many security bugs in IE and Communicator. To read more about it, click here to visit Georgi's page. If you click "Test it" beside the name of this bug ("Executing programs with IE 5.0") while using IE, the page you visit will write a small bit of sample code to your StartUp menu. You've been warned. Georgi calls this bug "the most significant of my discoveries and the most dangerous also".
Thanks to Zaw for the news.
#1 Combine with Back Orifice...
Wednesday August 25th, 1999 8:19 AM
Combine with Back Orifice and this can be very dangerous. You see, in order for Back Orifice to work, a file has to make it onto the machine you are trying to get into.
This hole would be an extremely easy way to do this. Oh man, think of the installed base of these easily hackable computers. I know the hole exists on my computer after visiting Georgi's page.
You may be able to do more with it than Java but you pay the price with that in security.
Basically, thats the reason why I don't use IE.
#3 Grand central tunnel, no less! HA!
Wednesday August 25th, 1999 9:21 AM
That's what you get when you tie a 40MB Web browser in with an already dubiously secure OS. A duh!
#4 New IE Security Hole - And It's a Big One!
Wednesday August 25th, 1999 9:31 AM
It is dangerous with ANY remote Control programs like PCAnywhere SMS, not just Back Orifece
Mozilla supports ActiveX in some sort of way doesn't it? If so will it affect Mozilla too??
#6 Will it affect Mozilla?
Wednesday August 25th, 1999 10:04 AM
Mozilla does not currently support ActiveX. The control developed by Adam Locke is an ActiveX wrapper for gecko. It allows the mozilla rendering engine to be embedded in other aplications like Internet Explorer. ...I think...
Yes. It IS an ActiveX control, not ActiveX complient (you can embed gecko into IE, but not the other way around). I don't think Mozzila would implemant it, since ActiveX is an OS proprietary technology (have they ported it to MacOS's yet?)
I admit I did once wonder aloud if they Should implement a windows only ActiveX clomplience, just for more cross-browser, but after this, I'm glad that no one was listening.
#18 Will it affect Mozilla?
Thursday August 26th, 1999 3:05 AM
The Mozilla control is obviously ActiveX but it only allows itself to embedded into other apps at present (including IE). Since the control is not signed, IE will only run it if you turn off the normal security settings or run it locally.
I am 100% certain that there are security flaws waiting to be found so making the Mozilla control not safe for scripting is a sensible precaution.
As to whether Mozilla will host controls inside itself, my thoughts are that it can and should (though in a very limited way). ActiveX controls are demonstrably a bad idea in the Internet but are useful in the Intranet and in custom applications (such as an encylopedia built using Mozilla).
The Mozilla control project can already be built as a ActiveX plugin (like the NCompass one) but it is experimental and not done by default. At present it will only runs controls that are already on the PC. It will not attempt to download and install them if they are not. It is likely that it will never download controls that are not there due to issues surrounding control signing and CAB.
Neither are controls scriptable, though this is more due to a problem I am having with Liveconnect. Even when I fix this only controls marked as safe for scripting will be exposed to scripts.
I went to the page, and received an error too, basically it was because it was trying to write to the c:\windows\..\startup directory, and I am running NT, where c:\windows doesnt exist.
I think the error I got was 'path not found'. is this what you were seeing too?
by Stromgol <firstname.lastname@example.org>
Wednesday August 25th, 1999 4:09 PM
yes, that is the exact message. (I'll try to make less spelling mistakes in this post;) It seems that the test only works when you are using windows 9x : english version.
The immediate patch is to unregister the offending object that is being exploited or to remove it's "safe for scripting" capability.
This will prevent any malicious code from calling it, though it might cause problems if it is used elsewhere (e.g. from the active desktop)
by Stromgol <email@example.com>
Wednesday August 25th, 1999 12:19 PM
#11 New IE Security Hole - And It's a Big One!
Wednesday August 25th, 1999 3:15 PM
well.. get the source and write one for nt.. changeing path of window/..startup to winNT's Startup folder.
I'm sure that can minipulate the registery also.
Communication has a lot of security related bugs, too.
Yes! let's all go back to Lynx, or worse.. Teletext!
#16 New IE Security Hole - And It's a Big One!
Wednesday August 25th, 1999 8:22 PM
Changing the directory to fit NT may not be quite as easy as it sounds. You could try to put it in C:\WinNT\Profiles\All Users\Start Menu\Programs\StartUp but that'll only work on people with Admin privlages. Of course, MY startup folder is D:\WinNT\Profiles\Jake\Start Menu\Programs\StartUp so that wouldn't work to well for me. I guess the best security is to just have a strange configuration... :O)
Then again, this isn't a hacker site and we're not discussing how to best exploit this bug (and I really wouldn't want to, I'd rather see it patched), so I guess I'll just shut up now.
I know this is completely off topic, but I have a question. An ActiveX control is basically just a specialized COM object right? So wouldn't it be possible to port ActiveX to all platforms using the Mozilla XPCOM architecture? Or is there something specialized about ActiveX that allows it to only run on Windows?
Thursday August 26th, 1999 3:14 AM
In theory it would be possible to write an XPCOM that worked on all platforms (with recompilation of course).
The problem is that ActiveX is an application of COM for visual and automated objects that requires each object to implement certain COM interfaces. So assuming you were copying Microsoft's APIs you would have to create the XPCOM equivalents of IDispatch, IOleControl, IOleObject, IDataObject, IOleInPlaceObject, IOleInPlaceSite, IQuickActivate, IPersistPropertyBag etc.
If you can persuade them to download an unsigned active x control (easy enough to do with many lusers), you can use it in IE4 also.