Excel 2003 SP3 and COM Addins

Rob just posted a useful summary of SP3 changes on the earlier post here. And Dennis points out WOW are advising not to install yet.

That prompted to me to look at it a bit more, and this one may prove to be a headache for developers of COM add-ins and their customers:

Enable or Disable specific COM add-ins based on category

The rationale is sound enough:

Say you download a COM add-in (dll) or COM control (ocx) to try out, currently you could try and use it in many products in many places. Neat, but it may not work in many of those cases.

I have a COM add-in to do worksheet metrics, it makes no sense to allow people to open that in Word. So a simple way to cut down the attack surface is to force it to only load in Excel. (no Word, no PowerPoint, no Office forms, no Outlook, no IE etc etc)

Not too important for my metrics stuff, but if the component was malware you just reduced by 80/90% or more the chance of that thing being invoked. Or put it another way, you maybe just forced the bad guys to write (and test (yeah right!) and maintain) seperate versions of their tiresome badware for each Activex container they want to target. Oh, unless its just a case of registering it into each category? Which it looks like it is. And multiple categories is OK?

So thats the good, it should genuinely cut down on peoples vulnerability, and make social engineered mischief just that bit harder. The other good is that this new lock down is not turned on by default – so its not like anything should stop working.

The bad? Should some semi smart sys admin decide they will enable this (and over time that will make more and more sense – on by default in a few years time?) COM add-ins (including VBAIDE ones) will stop working unless they get ‘categorised’.

The possibly bad – I only saw an ExcelRTD category – not sure if that will cover all Excel COM and Automation add-ins.

I only saw a C++ snippet to register your add-in in a particular category – so I don’t know if you can do it in VB6 at all, or if its just a WINAPI call, or an external step.

I’m not sure if you could add your own categories, probably not.

Dunno if my shimmed .net COM add-ins can be categorised.

From what I have read it looks like registering a COM component will be a 2 step process if this ComCatCheck is enabled in your target environment. Register as normal, then register that Class ID under the various categories it should run under. For fun register yours in the white list and your competitors in the black (do not load) list – tee hee.

Thats the theory as I see it anyway. I’ll need to actually try it all out to understand it properly. I don’t think there are any COM add-ins as part of the standard Excel install that might break?

Anyone know any more?

Cheers

Simon

Advertisements

5 Responses to “Excel 2003 SP3 and COM Addins”

  1. Dennis Wallentin Says:

    Simon,

    I view it as:

    If any of my COM Add-ins stops to work then I know an additional source that explain why they no longer work and which one I actually can resolve.

    What worries me most is that we, micro^2 developers, will face a more and more challenging situation due to how MSFT implement security.

    Perhaps we will be forced to simple skip free add-ins because we cannot cover all possible scenarios.

    Kind regards,
    Dennis

  2. Simon Says:

    Excellent point Dennis.
    I am happy to give away xlas as they are so easy to build and deploy. COM stuff and .net stuff has such a deployment burden and so much potential to not work its not appealing to give away these types of component. Especially when deployment troubleshooting can be a major time drain, hard to reproduce locally, and is usually less fun than developing.

  3. Dennis Wallentin Says:

    I can agree with You on the deployment burden.

    The major shortcoming of native XLAs is that they cannot use thirdparty ActiveX controls which has a negative effect on creating user friendly UIs.

    In view of what MSFT have done so far with security and to what we can do in Excel 2007 I assume that the days of providing native XLAs without any security concern will be soon gone…

    Despite the burden of deployment for COM add-ins I still prefer them over native XLAs.

    Kind regards,
    Dennis

  4. TonyG Says:

    I just stumbled upon this discussion from a comment that Simon made in a usenet forum. Thanks for the misc tips, Simon. I’m having a heck of a time trying to deploy my Excel addin. Pain is expressed in my blog:
    http://nebula-rnd.com/blog/tech/2007/11/excel-tools5.html
    I need to make sure I’m properly registering with HKCU and check an issue with the COM shim wizard, otherwise I’m out of ideas. I’ve posted to a number of forums with no response at all – like no one knows how to do this. Weird – and no hope in sight from VS2008, VSTO, or .NET 3.x. Sigh.

  5. Донат Says:

    Я думаю так же, давайте обьеденятся

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: