No Fix Planned For LabVIEW Bug, Says National Instruments

Researchers identified a vulnerability in National Instruments’ LabVIEW software that will not receive patch by the vendor.

Automated test equipment and virtual instrumentation software behemoth National Instruments said it will not patch software that security researchers at Cisco Talos said is flawed and could result in code execution by third-party attackers.

The affected software is LabVIEW, a leading program designed for rapid development of engineering applications that require testing, measurement or control.

The vulnerability (CVE-2017-2779) was discovered by Cisco Talos and disclosed to National Instruments in January and impacts LabVIEW 2016 version 16.0.

“Talos is disclosing the presence of a code execution vulnerability which can be triggered by opening specially crafted VI (virtual instrument) files, the proprietary file format used by LabVIEW,” wrote Cisco Talos in a research note posted earlier this week.

Researchers linked the flaw to an exploitable memory corruption bug that exists in the RSRC segment parsing functionality of LabVIEW’s software.

“Although there is no published specification for the file format, inspecting the files shows that they contain a section named ‘RSRC’, presumably containing resource information. Modulating the values within this section of a VI file can cause a controlled looping condition resulting in an arbitrary null write,” according to Martin Lee, technical lead, security research, with Cisco Talos.

Under these conditions an attacker could craft a Virtual Instrument file (.vi) that can be used to trigger the vulnerability, potentially resulting in code execution.

“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,” according to the Cisco Talos report.

Lee disagrees with that assessment and compared the risk associated with bug to that of a critical .NET PE loader vulnerability (CVE-2007-0041) patched by Microsoft in 2007. In that instance, remote attackers could execute arbitrary code via what was most likely was a buffer overflow attack involving an “unchecked buffer” and un-validated message lengths in the PE Loader services in Microsoft .NET Framework 1.0, 1.1, and 2.0 for Windows 2000, XP, Server 2003 and Vista.

“Many (LabVIEW) users may be unaware that VI files are analogous to .exe files and should be accorded the same security requirements,” Lee said.

In March, Cisco Talos disclosed a similar memory corruption vulnerability (CVE-2017-2775) to National Instruments which was triggered by opening specially crafted VI files. In that instance, National Instruments released a patch, LabVIEW 2016 f2.

“As with the previous disclosure, organizations should be aware that proprietary file formats without a published specification are nevertheless amenable to inspection to identify vulnerabilities. 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,” Lee said.

Discussion

  • Mitja Kolsek on

    Readers might be interested in knowing that we created a 3rd party micropatch for this vulnerability. For more information: https://0patch.blogspot.com/2017/09/0patching-rsrc-arbitrary-null-write.html
  • Jeff Phillips on

    I’m in the Product Marketing department at NI and am directly responsible for LabVIEW. Our team has been looking into this and our understanding is that Cisco Talos demonstrated a crash in LabVIEW and not errant code execution. The vulnerability writes zeroes to memory, not data or arbitrary code like the .NET PE Loader case that is cited. Further, turning zeros in memory into code execution is difficult, as confirmed by Mitre, and the file loading function cannot be invoked remotely because it is not bound to the network stack. For these reasons, we’re confident in our revised security score of 5.3. I also want ensure your readers are aware of this helpful public documentation - http://digital.ni.com/public.nsf/allkb/ECCA13EDE2300EFA86257FE100747965 - that advises users how to safely inspect files they aren’t sure about. Additionally, we’ve been working internally to determine the best way to address the vulnerability, the scope of the implications, and the best timeline in which to move forward. We now have content online (http://www.ni.com/product-documentation/54099/en/) documenting the vulnerability and relevant steps for mitigation. We will update this page when the fix is ready (I expect that in the next 3-4 weeks). Please let me know if there’s any other information my team or I can provide to help with this situation.
  • odd on

    “Many (LabVIEW) users may be unaware that VI files are analogous to .exe files and should be accorded the same security requirements,” Lee said. That's a lot like saying "most users may be unaware that c files are analogous to exe files." I'm a bit curious about the vulnerability and plan to read the links here in a second. But, if the infection is targeting a VI, wouldn't it be much easier to just add code to the VI than to try to force the file structure to run the code?

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.