LabView vulnerability allows hackers to hack your computer

[OriginalAlphaBeta]

Anyone else come across this? https://thehackernews.com/2017/08/hacking-labview-vi-file.html?m=1

They talk in the post about Labview 2016 but I presume it is still vulnerable in Labview 2017 (which I'm using)?

[GerdW]

Hi Original,

while this vulnerability is bad for LabVIEW as we depends on the VI loading routine inside LabVIEW you (as developer) should always be careful when opening VIs from "outside":

- they might be set to "run when opened"

- they might include code to delete your C: drive (after they "run when opened")

- they might include other hidden bad stuff

- due to problems in the VI it might corrupt the running LabVIEW IDE forcing you to kill it and so sending any unsaved work to NIL:

While you can avoid this "run when opened" feature (by dragging the "unknown" VI as a subVI into another VI) I can't see the result of the linked security warning. What happens with this "arbitrary null write"?

[mcduff]

I am sure this is not the only vulnerability. 

See https://lavag.org/topic/19527-smash-call/

That being said, has anyone ever heard of an exploit in the wild? I am not going to worry too much about this.

I wonder if NI scans any of the files that are uploaded here.

Cheers,

mcduff

[RavensFan]

I don't put any faith in articles that use a word such as "equipments".

[wiebe@CARYA]

I'd be more worried about everyone using OPC without any security. It's fairly easy to "hijack" this communication, and your plant would be doing stuff without anybody noticing. Pretty sure that's fairy easy with shared variables as well. Redirecting TCP\IP communication isn't that hard.

AFAIK, this hack could be done with any program. What they are saying is: if you run something malicious, it could do harm. Yes, even if it's a VI... If you open (and run) a Java, Python, C++ or C# file, you have the same "vulnerability".

On the other hand, it seems that this hack would execute when the VI is loaded. This means a virus could be made that spreads itself though all VI RSRC sections. So inspecting the VI and deciding not to run it won't work. The damage is already done. The code in the RSRC might not be doing anything else then replicate itself. Until a certain condition is met, and then it could activate some evil. Pretty much like stuxnet.

But it would be a lot easier to make a virus with scripting. When run, it infects other VI's... Using weird flags you can make this script invisible. Although you need to run the VI, it probably has the same effect, and it's a lot easier.

In both cases it will be probably be noticed. VI's will become slower, larger, and SCC will show unexplainable changes.

[rolfk]

I don't see how this vulnerability could allow arbitrary code to be executed. What I do see from the description is that someone could create a VI that when loaded in LabVIEW, crashes your LabVIEW program. Wow, that is big news!

Anyhow it seems that NI has already responded to this here and is in the process of creating a patch for it. And give them a few weeks to test, package and retest that patch.

[wiebe@CARYA]

Rolf,

That right, it only crashes LV (fills LV memory with 0's)...

[Hooovahh]

I mentioned this in another thread, but if you are worried about VIs that run on open, you can install my LabVIEW Tray Launcher, which takes over the .vi file extension, and shows you what version of LabVIEW the VI can be opened in and what ones are running.  In addition to that it has the ability to ask if a VI should be ran when opened, or just opened and not ran.

[Hooovahh]

I saw an article on Reddit that goes into detail on what this vulnerability involved and how it works.  The article is pretty negative since it was written before NI said they works do something about it.

https://0patch.blogspot.com/2017/09/0patching-rsrc-arbitrary-null-write.html?m=1

[rolfk]

It's basically a blog for their own product (which you can download for free) and their service to support manufacturers with micro patches. It does however have a potential flaw. I don't see anywhere in the source code for their micropatch an exact version number nor what the file should contain before it gets patched. So considering that NI releases several patches per LabVIEW version which can certainly also replace this particular DLL (it's the manager core DLL that contains all the code for the low level managers in LabVIEW), there is a chance that they micropatch an already patched version that doesn't have the code at the same address and therefore potentially creates a non working DLL.

NI does usually update the version number of DLLs but only the bug fix level and that seems nowhere checked, nor a test that the DLL contains at the specific location the byte sequence that needs patching. And it obviously only patches the 32 bit version of LabVIEW.

And since it seems to actually modify executable code files, I doubt that it works in a tightly secured corporate environment at all. Most virus scanners will likely consider it a thread as it would need to use some highly suspicious mechanismes to do its work.