National Instruments’ LabVIEW has a memory corruption vulnerability that could lead to code execution.
LabVIEW sees use for building data acquisition, instrument control, and industrial automation systems on a variety of operating systems: Windows, macOS, Linux and Unix.
The vulnerability was discovered by Cory Duplantis of Cisco Talos earlier this year, and reported to the company.
It can be triggered by the user opening a specially crafted VI file – a proprietary file format that’s comparable to the EXE file format.
“Although there is no published specification for the [VI] file format, inspecting the files shows that they contain a section named ‘RSRC’, presumably containing resource information,” Cisco said in a blog post.
“Modulating the values within this section of a VI file can cause a controlled looping condition resulting in an arbitrary null write. This vulnerability can be used by an attacker to create a specially crafted VI file that when opened results in the execution of code supplied by the attacker. The consequences of a successful compromise of a system that interacts with the physical world, such as a data acquisition and control systems, may be critical to safety.”
More details about the flaw can be found in this Talos report. It affects the latest stable LabVIEW version (LabVIEW 2016 version 16.0), but it’s possible that earlier iterations are also vulnerable.
“National Instruments does not consider that this issue constitutes a vulnerability in their product, since any .exe like file format can be modified to replace legitimate content with malicious and has declined to release a patch,” the researchers said.
“Talos disagrees. There are similarities between this vulnerability and the .NET PE loader vulnerability CVE-2007-0041 which was patched in MS07-040. Additionally, many users may be unaware that VI files are analogous to .exe files and should be accorded the same security requirements,” researchers said.
Since a patch is not forthcoming, LabVIEW users would do well not to open VI files of unchecked provenance. Also, two Snort rules have been made available for detecting exploitation attempts (41368, 41369).