MS08-008 Critical Bulletin Likely Affects OPC
Microsoft Security Bulletin MS08-008 Vulnerability in OLE Automation Could Allow Remote Code Execution issued today is likely to affect OPC servers. Remember that OPC was originally an acronym for OLE for Process Control.
This is a serious vulnerability rated Critical by Microsoft for most OS and would allow a remote attacker to run shell code after the exploit. The bulletin talks about “remote code execution if a user viewed a specially crafted Web page”. It will be interesting to see if an OPC server can be compromised and then used to allow remote code execution if an OPC client connects to the compromised server.
We are looking into this and will have more detail in a future blog entry. We did find the answer below from the FAQ very interesting. It is possible that an OPC server that distributes their own version of oleaut32.dll could still be vulnerable even after the Microsoft patch. Yet another reason to assess the software quality of your vendors.
If third-party applications use or install the affected OLE component, could I still be vulnerable even after I have installed all required Microsoft security updates?
No, this security update replaces and re-registers the affected OLE component provided with the operating system. If third party applications follow the recommended best practices for using a shared component as a side by side assembly then they are also not affected. Customers are potentially at risk if third party applications do not follow the recommended best practices and instead redistribute a version of oleaut32.dll with their application. Microsoft Knowledge Base Article 921503 also contains instructions for customers that wish to manually check for the registered affected OLE component. Customers are encouraged to contact their third party solutions developer for addition information.
Author: Dale Peterson
Posted: February 12th, 2008 under OPC, Vulnerability Disclosure.
Comments: 5
Comments
Comment from Jake Brodsky
Time: February 13, 2008, 1:14 pm
This will be a real test to see how responsive the OPC driver vendors are to a vulnerability like this.
Comment from Ron Southworth
Time: February 14, 2008, 1:46 am
Hi Dale Apparently MS has a security fix.
Habbib posted a quick comment and a link on the SCADA mail list that may be worth reading.
Comment from Jim Luth
Time: February 14, 2008, 11:59 pm
OPC COM Servers use a “custom” COM interface, not the “OLE Automation” interface so OPC Servers would be immune to this vulnerability. However, some vendors do ship the OPC Automation DLL that may be affected by this vulnerability.
Pingback from OPC Exchange Blog, Featuring Eric Murphy » Blog Archive » OPC and the OLE Automation Vulnerability
Time: February 15, 2008, 12:39 am
[...] Dale pointed out in a recent post the ‘O’ in OPC originally stood for OLE for Process Control. Even in the beginning the name [...]
Comment from Ralph Langner
Time: February 15, 2008, 4:46 pm
Jake, what would the test result tell us? In the part of the world where I live in: nothing…
Hundreds of OPC servers have been implemented by small contractors, since the cited “vendors” didn’t have IT folks on staff who could or would implement an OPC server. After all, many of those vendors (such as equipment manufacturers) didn’t think OPC connectivity would be crucial technology that they should better master themselves. So many of them went shopping for the best bargain, i.e. dirt cheap. Anyways, they finally did locate some small software company that got into the contract. Unfortunately, this company may no longer in business. And even if they are… chances are 99% they didn’t implement the OLE/DCOM stuff themselves but used some OPC server library that they didn’t bother to analyze.
However, let’s just assume you’re lucky and your “vendor” tells you that they didn’t use the Windows library in question. Does this mean your OPC installation is secure? No way. This is one thing that I don’t like about the message that this blog entry carries between the lines. OPC is not potentially insecure because this newly discovered OLE vulnerability exists. In the average OPC installation, there are between three and five hardcore vulnerabilities, and these can’t be fixed by replacing a DLL or applying a security patch.
Write a comment