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, Insightful) by Grishnakh on Thursday August 31 2017, @03:20PM (3 children)

    by Grishnakh (2831) on Thursday August 31 2017, @03:20PM (#562149)

    Honestly, I'm not sure it is. How many people actually run Labview files from other sources? Usually, it's used as an in-house tool to build automation systems or test systems. Hence, you're probably going to be running only in-house developed code on it, because every installation is completely custom and different. For this to be a problem, an attacker would probably need physical and log-in access to your system, which means they're one of your own people, and it'd be easier for them to just write some malicious code right there in Labview instead of using an exploit.

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

    Total Score:   4  
  • (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.

    • (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.

  • (Score: 1) by toddestan on Friday September 01 2017, @11:05PM

    by toddestan (4982) on Friday September 01 2017, @11:05PM (#562764)

    You can "compile" the VI's into an .exe, and distribute it so that you don't need Labview to run it. Though you still need to install NI's Labview Runtime and other associated software, which is a huge amount of bloat. Labview will even build it all into an installer, so an end user may not even know it's a Labview program (though the multi-gig installation for a simple program may kind of clue them in).

    Of course, if you are running random .exe's from someone else, they really don't need to worry about crafting special vi's to pwn you.