Microsoft's Urgent Patch Precedes Black Hat Session

Julie188 writes "Mystery solved! Microsoft's latest emergency out-of-band patch was weird beyond belief. A notice was sent to journalists and researchers late Friday evening that the patch was coming Tuesday, but Microsoft refused to explain the flaw and even put a cone of silence around researchers who would have otherwise talked about it. But finally, one researcher broke ranks and explained that the patch was caused by a flaw introduced in Microsoft's own development tools. This flaw was also the source of the emergency ActiveX patch, which took about 18 months to complete and which supposedly fixed the problem by turning off ActiveX (setting a 'killbit' on the control). Researchers at Black Hat on Wednesday will be demonstrating how to override the killbit controls and get access to vulnerabilities supposedly stopped with a killbit. What's really scary is that Microsoft has issued 175 killbits fixes so far."

Comments

Re:sensationalist much?

[mortonda]

You missed the part where they knew about the flaw 18 months ago. That's just... sad.

Re:Imagine.

[commodore64_love]

I would upgrade to a Macintosh and abandon the Microsoft/ActiveX/Exploder trojanware completely, but Mac has its own undesirable flaws. Namely - A $100 fee every year to upgrade from 10.4, to 10.5, to 10.6, and so on.

i.e. Macs are expensive to maintain. In contrast I bought a Mickeysoft XP PC in 2002 and haven't spent a dime since then for OS updates. i.e. Cheap.

(And Linux won't install my Netscape ISP's Web Accelerator software - so that's not an option either.)

Re:sensationalist much?

[commodore64_love]

I thought the weridness came from using a "killbit" solution. Any spybot programmer will easily be able to override that.

Re:The real mystery

[commodore64_love]

>>>Whoever thought making C/C++ an implementation language for anything as complicated as an OS ought to be shot.

In the 1980s the C language was the best option. There wasn't anything better. And since Windows/DOS and Windows/NT were developed during the 80s, we still live with the legacy. Simple as that.

It's the commonality.

[tjstork]

The thing about Active X is that is just a way to put an object oriented wrapper around a DLL. So really, its just a DLL.

The problem with DLLs is that they are good for process re-use on a desktop but not the kind of thing you want to be shoving into a browser. However, if Microsoft closed off Active X entirely in browsers, they would break Flash and third party OpenGL and movie plugins... and probably would wind up getting ripped for it.

The thing to keep in mind is that Firefox and other browsers that allow for DLLs to be loaded as plugins are going to have these problems as well. It's just that, there are less firefox plugins than there are activex controls out there, so the universe of the problem is smaller.

Re:It's the commonality.

[neonsignal]

There is truth in your argument that third party additions to a browser pose a security problem, but you are comparing coffee and fish.

Plugins pose a security risk because you are running software from unknown sources as part of your browser. However, you don't need to install the plugins in order to enjoy the browser functionality.

Active X on the other hand was always intended to be integrate with web pages, which means that in many cases you would not even have been able to view the content without downloading a COM object of dubious origin. Fortunately this has largely failed, and most web content is still accessible without it (though there are a number of commercial services on the other hand that require Active X to work).

The better comparison with Active X is other dynamic web code, such as scripting languages like javascript, and of course Java, which have been used for similar purposes. There are clear differences, because Active X is running native code, and so is notoriously difficult to sandbox effectively. It is obviously a matter of degree; no system is fully secure. But whereas exploits of Active X tend to often be total (access to the host machine), exploits of systems such as javascript often revolve around more subtle issues such as masquerading.

I actually think there is merit in having internet distributable native code. But having said that, there are multiple issues. I don't think the solution is merely to improve the containment of the downloaded code (indeed, that only makes it harder for the plugin to do anything useful). The problem is one of trust: how do I know if the binary code is trustworthy (Microsoft rubberstamp certification just doesn't do it for me!); and why do most sites need Active X at all (shouldn't we just be trying to agree on some browser standards like video formats so that typical functionality can be built into the browser!).

Re:It's the commonality.

[imess]

Not to be confused with Firefox Addons, which seem to be fairly secure, and are pieces of javascript.

This is not true. You can have native DLLs in Firefox addons. Check out the Glasser addon, for example.

Re:It's the commonality.

[DavidTC]

Yeah, and EnigMail over in Thunderbird. Likewise the 'minimize to tray' addons somehow make the Windows calls to do that, although I think they're calling already existing functions instead of providing a DLL with them.

I'm not entirely sure how they do any of that.

So it would be more accurate to say that most Firefox extensions are Javascript. 99% of them. (They have to be, to work on multiple OSes.)

Re:It's the commonality.

[thePowerOfGrayskull]

he thing to keep in mind is that Firefox and other browsers that allow for DLLs to be loaded as plugins are going to have these problems as well

People tend to like to forget about that. ActiveX is no more or less unsafe than FF plugins. Executable code running on the client machine, non-sandboxed. Both FF and IE will prompt you before installing such things, and that's the extent of the protection you get from them. Both can be very easily abused by a malicious creator - all you have to do is get people to install it (bunnies!); or install it yourself as part of another application.

Re:The real mystery

[VGPowerlord]

I thought Vista was supposed to be built with .NET, only to have those plans scrapped. If MS isn't building their OS with C# and .NET, there must be a reason.

I think you're confusing Vista with Singularity.

Re:The real mystery

[recoiledsnake]

No, significant parts of Vista were supposed to be rewritten in C# but due to performance(or other) reasons, the plan was ditched in 2003/2004 and a normal C++ upgrade to XP was started. This was one of the big factors in the delay of Vista's release.

Re:It took 18 months...

[VGPowerlord]

The ActiveX killbits weren't the only thing updated. Microsoft also updated Visual Studio 2003 SP1, 2005 SP1, 2008, and 2008 SP1; along with their respective runtimes.

Re:Imagine.

[billcopc]

Except Windows apps from today still run on a 10-year old Windows 2000 machine, for the most part.

Mac apps are, like their makers, excessively trendy so whenever a new OS X build is released, the great majority of developers "embrace" the new features and it seems very few are committed to backward compatibility. This much is true of both big-name vendors and homebrew/shareware authors ("Free" isn't so big yet in that sphere).

You DO NOT have to reboot if you install manually

[dobedobedew]

I'm not going to get into why having automatic updates on is generally a bad idea, that subject has already been beaten to death here.

WindowsXP-KB972260-x86-ENU.exe /quiet /norestart

That is the one for XP with IE6, the filenames are different for the other flavors. The list of all of the different patches is at:
http://www.microsoft.com/technet/security/bulletin/ms09-034.mspx/

Re:The real mystery

[cyberdrop]

The reason was not performance. It was an compability issue.
Currently there can only one version of the CLR be loaded into a process. The CLR version of the first .NET DLL is used in the process.

This is also the reason why you should not make shell extensions in .NET. The Windows Explorer would load the shell extension dll in unknown order. If the first one is a .NET 1.0 Dll all .NET 2.0 Dlls would not load.
If a Programm delay loads the CLR a simple call to the Open File Dialog would cause the .NET 1.0 CLR to be loaded into the process.

This problem will finally be solved in .NET 4.0. I think we will see the use of .NET in Windows 8...

Re:Imagine.

[cyberdrop]

The code is not embeded in the web page!

An ActiveX Control is a Plugin for your browser. The browser is also bound to an particular operating system and processor architecture!

Re:The real mystery

[cyberdrop]

.NET is perfectly fine for anything other than writing plugins or plugin hosts for parts of the operating system.

Re:Imagine.

[TheRaven64]

Namely - A $100 fee every year to upgrade from 10.4, to 10.5, to 10.6, and so on

I don't like to contradict your wonderful hyperbole with mere facts, but the upgrade from 10.5 to 10.6 is going to cost $29, and comes two years after the release of 10.5, making the cost $14.50 per year, not $100. The upgrade from 10.4 to 10.5 cost $129 I believe (although it was $20 if you had bought 10.4 after 10.5 was announced) and was release 2.5 years after 10.4, making the cost per year $51.6. If you bought both of these upgrades, you will have spent $35.11 per year on upgrades.

Re:The real mystery

[DavidTC]

I also didn't like how ActiveX morphed from a special browser-only technology into a synonym for COM and then into a replacement for OLE.

ActiveX was never a browser-only technology. It was just they referred to the embedding of COM controls in web pages as ActiveX, and eventually started renaming everything 'ActiveX'.

For people who don't know what we're talking about: COM started as a way to embed DLLs that provided specific functional in programs, essentially, 'plugins' that program builders could use that all operated much the same way. I.e., a lot of them you could mark out part of the application and have them responsible for drawing it, and receive signals when they part was active, etc.

Developers could go out and license, for example, a nice TIFF control to embed a picture in their application, or whatever. All the 'common controls' soon moved to this format. They contained all their 'header' information and whatnot inside them, so developers could take a COM file and see what was exported and whatnot in a consistent manner.

Like I said, it's like shared libraries, except all the functions are named and accessible via consistent means. They all use the same way to do things, so you can load them into your application without knowing what they are. (And hand over part of your document to them, or whatever.)

Creators could even do things like license these controls, where people could redistribute them, but not program using them.

ActiveX essentially is COM and OLE2. This were .ocx controls, the successor to .vbx controls, which is where the X in ActiveX comes from. (For those of you who remember your history, the very first version of this was called OLE, Object Linking and Embedding.)

All in all, this not a bad idea. In fact, most OSes have something like it...OSes start off with something like DDE or shared memory, and then end up with higher level functionality built on that to allow you to consistently embed parts of applications in others. Linux has something called, I believe, DCOP.

The problem came about when Microsoft started letting those DLLs be embedded in its web browser, instead of making people write DLLs with customer entry points and functionality, like Netscape had done. (And then it started renaming everything to ActiveX.)

I can see why it did it, in fact, using the COM format to embed controls makes sense, it's letting it use the existing controls that was the problem.