Submitted via IRC for TheMightyBuzzard
Cory Duplantis of Cisco Talos unearthed a LabVIEW code execution flaw which can be triggered by the victim opening a specially crafted VI file.
LabVIEW, the widely used system design and development platform developed by National Instruments, sports a memory corruption vulnerability that could lead to code execution.
LabVIEW is commonly used 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 victim 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 noted.
"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 report. It affects the latest stable LabVIEW version (LabVIEW 2016 version 16.0), but it's possible that earlier iterations are also vulnerable.
Additional Information:
http://blog.talosintelligence.com/2017/08/vulnerability-spotlight-code-execution.html
CVE-2017-2779
Source: https://www.helpnetsecurity.com/2017/08/30/labview-code-execution-flaw/
(Score: 4, Interesting) by LoRdTAW on Thursday August 31 2017, @03:32PM (1 child)
I've seen low volume specialized systems built around it. Though, you have to look at this problem from another angle: more vulnerable industrial automation equipment which might fall prey to another stuxnet like infection. But here's the thing, industrial automation isn't an IT problem to be solved with security fixes because security in PLC's is silly. So security has to be dealt with by IT between the automation networks and the regular IT networks which are internet connected. Or better yet, air gap the damn thing and stop masterbating over metrics.
(Score: 0) by Anonymous Coward on Friday September 01 2017, @03:29PM
Not all PLC systems can be removed from the network.
I worked on one system that separated test device passers from failures. The method to tell the difference? read the barcode, and ask the network.