May customers are asking us about the recent Microsoft Security Bulletin MS08-008 regarding the vulnerability with OLE Automation.   Looking at things, it doesn’t look like this should have any bearing on OPC Servers since they use the custom interface, and the vulnerability is with OLE Automation.  Of course it is still a very good idea to patch your systems since the consequences can be quite serious and there are some OPC clients out there that make use of OLE Automation.

As Dale pointed out in a recent post the ‘O’ in OPC originally stood for OLE for Process Control.  Even in the beginning the name wasn’t really correct since the OPC specifications (DA, HDA and  A&E) are technically based on COM.   Since Component Object Model (COM) and Object Linking and Embedding (OLE) are very closely related, it’s easy for confusion to set in.    It doesn’t help matters that Microsoft introduced the term OLE first.  As the scope expanded Microsoft realized OLE didn’t fully fit the bill, so they created a new binary compatible, language independent, extremely lightweight protocol called COM.  In COM, software components implement their services as one or more COM objects. Every object implements one or more interfaces, each of which exports a number of methods.  COM components communicate by invoking these methods.     OLE is a set of standard COM interfaces that enable users to create compound document by linking and embedding objects (components) into container applications, hence the name OLE.  In other words COM is a specification while OLE is a particular implementation of this specification. 

When reading the FAQ notes on the MS08-008 vulnerability, it appears to be confined to applications developed using the Visual Basic 6 platform and the oleaut32.dll (the workarounds in particular mentioned instantiating the Microsoft Forms 2.0 ImageActiveX Control in Internet Explorer).    Since OPC Servers are developed using the custom COM specification, this shouldn’t apply to them.   Although most industrially robust OPC clients will be developed on COM, it is possible to develop OPC Client applications using the Automation interfaces, by using the opcdaauto.dll from the OPC Foundation (or other vendors).   I’m sure most OPC vendors will be posting details on their products.  You can find the MatrikonOPC details here.

The MS08-008 vulnerability deals with a client-side remote code-execution vulnerability that affects Object Linking and Embedding (OLE) automation when handling specially crafted script requests.  A successful exploit will result in the execution of arbitrary attacker-supplied code in the context of the currently logged in user.  Typically this would be a web-based attack scenario, where an attacker could host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have to persuade users to visit the Web site, typically by getting them to click a link in an e-mail message or Instant Messenger message that takes users to the attacker’s Web site.   I suppose if the vulnerability can be exploited using a specially crafted web page, it stands to reason someone could create a devious OPC client that did the same thing, (or other nasty stuff for that matter).   This is yet another reason to only install or use software from a known and trusted OPC vendor.

We’ll still be following this one closely to see what else might develop, but in the meantime I would say apply the patch and keep enjoying your OPC connectivity.

UPDATE:   Seems my clarifications might have been confusing to some.  If so, my apologies.  To be clear: the vulnerability would not directly affect the OPC Server interfaces, but could exist in other parts of a server package like GUIs or configuration software.  It would also be present in OPC clients or tools developed on VB 6.0 or use the oleaut32.dll.   The most prudent course of action is patch your system.   Digital Bond has done some more ground work that is definitely worth a read, and details a work around until you get things patched.