Needlessly abject

I am not a teenager. I play one on the Internet.



Other Blogs


ActiveX Installer Service

Bruce Schneier posted about an eWeek article that details the proposed new ActiveX Installer Service. I was a little disappointed to see that Bruce thought it was a bad idea. I think this may be because Bruce doesn't know how bad the current situation is.

This is really an improvement over prior Windows versions, not a "poking holes" in security deveopment. It has very little to do with User Account Control at all. It's not bad, per se. It's better than things were before. I wish, in fact, that it was being backported into the current Windows XP environment.

In a presently-deployed network with Windows 2000 and Windows XP client computers and users who do not have local Administrator rights, users cannot install ActiveX controls. This ends up being a huge pain, a sink of manual labor, and clearly isn't a situation that was very well thought-out by Microsoft at all.

Most of my Customers, for example, have some web-based application that requires certain ActiveX controls to be installed to function properly. In most cases, I can deploy Windows Installer-based (MSI) packages for the controls they need (mainly Adobe Reader and Macromedia Flash), and the headache is taken care of.

For my Customers that use more "boutique" ActiveX-based applications (an outsourced payroll management system that is ActiveX-based, an "ASP" document control repository interface, etc) that are not distributed as MSI files, I have two (2) remotely viable choices in getting the controls deployed onto their PC's, and neither is very good:

(1) Capture all the registry settings and files installed during the browser-based installation with a "packaging tool" (or "by hand") and build an MSI package. Hope that I got everything right (since I don't have source code to their control) and do damage control when I screw up some nuance of the installation on a subset of the, potentially, hundreds of different PC configurations that the control may deploy onto. Update this package each time the manufacturer "updates" the control.

(2) Logon to the PC manually w/ an Administrator credential and install the control. Attempt to verify and hope that the control doesn't inappropriately store anything in the user-specific portion of the registry such that the control won't function properly when the user attempts to use it. Do this to each PC that uses the control each time the manufacturer "updates" the control.

The third choice, of course, is just to weaken the security, typically by giving the user local Administrator (or, sometimes, Power User) rights. That's totally unacceptable to me, so most of the time I end up doing a combination of the first and second above, depending on whether the control needs to be on three (3) or three-hundred (300) PC's, and depending on the frequency of "updates" by the control manufacturer. (Don't even get me started about these idiotic software firms that think that "release early, release often" is a good idea for this type of application...)

The "solution" that Bruce posted about alleviates these problems above and creates an interface that I can use to grant access for "normal" users to install ActiveX controls that I've approved. Let's be clear: I don't _like_ the fact that we need this at all-- i.e. I think Microsoft shouldn't have browser-based control installation and _ALL_ installations of software should be managed by a service like the Windows Installer. Since nobody at Microsoft values my input on this issue (and, apparently, the input of every other clueful corporate network admin), I'm stuck favoring this solution only because it's leaps and bounds better than the alternative and will end up saving my Customers money.

It seems pretty clear to me that Microsoft doesn't do a lot of thinking about how large corporate Customers are going to integrate "new innovations" into their deployments. For everything that Microsoft does to add management interfaces, automation systems, and centralized administration tools, it seems like most cool new "innovations" get marketed heavily to ISV's who end up deploying them into systems that my Customers interact with. These "innovations" usually end up being the equivalent of prototypes that got shipped, and they aren't engineered heavily enough for real world deployment, use, and management.

In the case of ActiveX controls, the majority of the ISV's I've dealt with don't have any coherent strategy for deploying the control onto large numbers of PC's in a clean, manageable way, primarily because Microsoft didn't drive the point home clearly enough to the ISV's developers that deployment is an important issue. This feature, at least, gives us some mechanism for controlling the insanity.

Windows Genuine Pain in the Ass

I'm a couple of days behind in the blogs, but I saw that Bruce Scheneier had a posting about and the rumored "Windows kill switch" that Microsoft might be planning to install.

For my part, I've already seen two (2) false positives where WGA began displaying pop-ups indicating that a copy of Windows was not genuine. Both computers were laptop computers acquired a couple of years ago from a large OEM by one of my government Customers. I know, with complete certainty, that they were "genuinely" provided by this OEM. They were still running their factory installs of Windows XP Professional (they're light-duty machines, and are used by task-oriented users w/o local Administrator rights, so they stay stable and have pretty clean software), and both of them started indicating that they were not "genuine" at almost exactly the same time of the day.

We called the OEM's technical support, and the level 1 drone let slip that he'd heard from other agents in his call center that a large number of calls related to this problem were coming in. He indicated that, at that time, the only know "fix" was to reinstall the operating system using the product key affixed to the PC. A quick reviewed of both PC's revealed that they appeared to be using the same product key in their "factory" installs. This seems pretty common w/ OEMs-- I've seen the same product key in several different OEM machines in %SystemRoot%\System32\OOBE\OOBEInfo.ini. I've seen this w/ Dell, HP, and Gateway systems.

I'm not going to debate the philosophical points re: copyright and Microsoft's control of their "intellectual property". From a security perspective, attacking this system and disabling copies of Windows sounds like a great way to disable the IT infrastructure of a competitor. I'm not the only one who is thinking of this, so I'm assuming that the malicious attackers are, too.

Valid HTML 4.01 StrictValid CSS!