Leaderboard

NI released a number of patches for different versions. Was it only those versions affected? Or was it only those versions they applied the patch to and the issue still exists in previous versions? The problem I have with these sorts of threads (not necessarily here on Lavag, but in general) is that no-one ever defines their threat model. Who is it you are defending against? What are their capabilities? What are you prepared to give up in the name of security? Do you want Norton Security Suite running on your 500kB embedded platform? Is it the big bad nation state Stuxnetting your production line? Is it Joe Bloggs in the next cubical experimenting with a script he found on Youtube? My base line threat model is a skill level of a mediocre LabVIEW programmer, who can use Wireshark and has too much free time and a TCP connection to the device. Therefore my main worries are more with developers seemingly oblivious to even basic OPSEC rather than some alphabetty organisations with thousands of programmers. Does your websockets or web application have any authentication? Does it even use TLS? What happens if I send a 10GB file via websockets to your server Are you still using VI Server across your network? (which is unencrypted). Are you sending raw SQL back and forth between databases, unecrypted and with no authentication? These are the sorts of things I see in every company I have ever consulted with and would only require 10 minutes with wireshark to bring down complete production lines and smash robots into conveyor belts.Until that level of basic security is addressed it is just obsessive fearmongering to worry about specially crafted VIs that may cause a crash. Hell. LabVIEW crashes all the time. Until developers take ownership of their application security - and by that I mean really think about it rather than just using HTTPS because a webserver requires it, I see no real reason why NI need to fret about academic attacks and it is Kudos to them that they responded in the manner they did.

Yes the auto running VIs thing can be annoying, especially when people help out on the forums and are opening code from unknown sources. My LabVIEW Tray Launcher I wrote takes over the .VI file extension and if a VI is set to run on open, it has an option to ask if you really want to run it, or just open it. An installer is also linked to on that page.

It is in the basic RSRC format structure of VIs and the code to load that into LabVIEW has basically not changed much since about LabVIEW 2.5. So it is safe to assume that this vulnerability has existed since the begin of multiplatform LabVIEW. I doubt that it was there in this way in the Mac only versions 2.2.x and earlier as VIs were then real Macintosh resource files and LabVIEW used the Macintosh resource manager for loading them. (Note that the Mac OS 7 from those times wouldn't even survive a few seconds of being connected to the net! It's security was by nowadays standards mediocre and its only security from modern internet attacks was its lack of a standard internet connectivity out of the box; you had to buy an expensive coax network plugin card to make it connect to TCP/IP and install a rather buggy network layer that was redesigned more than once and eventually named Open Transport, because it connected the Mac to a non-Apple only standard network ). NI puts the latest three versions before the current one into maintenance mode and only releases security patches for them, as well as making sure that driver installations like NI-DAQmx etc support those four versions. Anything older is put in unsupported status and is normally not even evaluated if a bug exists in it. If a customer reports a bug in an older version and it gets assigned a CAR, then that older version may be mentioned, but retrospective investigations in older than the last 4 versions is officially not done by NI. This threat is assigned on the nist.gov link that I mentioned a Common Weakness Enumeration 787 status, which is an out of bounds write access, or buffer overflow write error. As such it is pretty easy to use as a DOS attack and potentially also as a code privilege execution escalation but those are tricky to exploit and LabVIEW makes them even trickier to exploit due to its highly dynamic memory management scheme.