Secunia Research finds vulnerability in ActiveX control
10:07 CET, 24th January 2007 By Ina Ragragio.
Secunia Research has discovered vulnerabilities in various audio and media applications caused due to an insecure ActiveX control. The vulnerable component, NCTAudioFile2.dll, was originally developed by NCT Company Ltd. (now known as Online Media Technologies Ltd.), and is known to be present in more than 70 products from 28 different software companies. This means that not only are certain NCTsoft products vulnerable, but most applications using the same component are vulnerable as well.
The vulnerability is caused due to a boundary error in the NCTAudioFile2.AudioFile ActiveX control; specifically, in the handling of the "SetFormatLikeSample()" method. Passing an argument with length of about 4,124 bytes induces a stack-based buffer overflow, making it possible for the attacker to execute arbitrary code on the user's system.
What's a viable attack scenario? Well, the exploit could be housed on a malicious web site that a user is tricked into visiting. Because this vulnerability involves an ActiveX component, successful exploitation requires that Internet Explorer is used to visit such a site. While we are not aware of any publicly available exploit for this vulnerability, actually crafting one is pretty straight-forward. So it's not too much to ask users to exercise caution when surfing the Internet, especially as IE6 automatically runs ActiveX controls.
Last year, Secunia Research found vulnerabilities in 18 compression programs because of a shared library (unacev2.dll) that could be exploited to cause a stack-based buffer overflow. Similar to shared libraries, ActiveX controls can also be found in various programs because you can license an existing one if you need the same functionality in your application.
As a developer, of course it is advantageous to use shared libraries or buy the license for ActiveX controls so that you can cut down on the development time of your product. On the other hand, you should also consider the security risks involved in doing so. Just because you didn't develop the original library file or component doesn't mean that you can eschew support for it, and leave it up to the original vendor to create a patch.
In line with Secunia's vulnerability disclosure policy, the vendor and all known licensees of the vulnerable component were contacted and given ample time to respond to our report. We have not heard from the vendor nor from most of the licensees.