Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday August 31 2017, @11:54AM   Printer-friendly
from the don't-touch-that-VI-(file) dept.

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/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by LoRdTAW on Thursday August 31 2017, @03:32PM (1 child)

    by LoRdTAW (3755) on Thursday August 31 2017, @03:32PM (#562153) Journal

    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.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Friday September 01 2017, @03:29PM

    by Anonymous Coward on Friday September 01 2017, @03:29PM (#562543)

    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.