Hi, I have discovered a buffer overflow vulnerability that allows remote code execution in an ActiveX control bundled by a manufacturer of video surveillance systems. The company is Lorex Technologies, a major video surveillance manufacturer that is very popular in the US and East Asia. Their affected product range is the EDGE series, which has 16 products in it. I have confirmed that all 16 are vulnerable at this point in time. These security DVR's are remotely accessible, and when you access it on a Windows computer with Internet Explorer, they try to install the vulnerable ActiveX control INetViewX. The Lorex manual[1] instructs the user to blindly accept the ActiveX control install when prompted. The full list of devices, as well as links to the firware download, can be found in [2]. Their products offer remote video viewing capabilities, and you can find some of them on Shodan[3]. The buffer overflow can be triggered by a really long string (10000+ characters) in the HTTP_PORT parameter. The instruction pointer can be very easily controlled in XP by the characters 109 to 113 in the string. Please refer to the PoC file lorex-testcase.html. You will see that the HTTP_PORT parameter is composed of D's, apart from chars 109 to 113 which are four A's. If you open this file in IE after installing the control, you will see that IE will crash with an EIP of 0x41414141. Changing the four A's to any other value will cause EIP to crash on that value. The list below tells a better story about what is affected and how it can be controlled: Win XP SP3 with IE6 - Fully exploitable as described Win XP SP3 with IE8 - Could not get it to crash (????) Win 7 x64 with IE10 fully patched - Fully exploitable, though not as easy as for XP (see analyze -v [4] and !exploitable [5] outputs) To verify this vulnerability you can download and extract the firmware using binwalk (http://code.google.com/p/binwalk/). To do so, please follow the instructions in [6], and then install the ActiveX control in INetViewProj1_02030330.cab. I have contacted Lorex and they initially said they would fix it, but went radio silent shortly afterwards. 17.11.2013 - Initial contact via support page 18.11.2013 - Email to sales, no response. 21.11.2013 - Second email to sales, received response by sales saying they will forward it to technical support and get back to me. 04.12.2013 - Third email to sales saying that technical support never contacted me back. No response. 08.01.2013 - MITRE assigns CVE-2014-1201 to this issue. 09.01.2013 - Public disclosure. All references can be found at: https://github.com/pedrib/PoC/lorexActivex/lorex-report.txt Proof of concept: https://github.com/pedrib/PoC/lorexActivex/lorex-testcase.html Regards, Pedro Ribeiro (pedrib () gmail com) Agile Information Security