ShaunR

Well. Just to fan the flames of fear a bit more . I worry more about all the web/DNS servers, updaters, databases and weird and wonderfully named background tasks/services,(some of which I have no idea what they are for) that get installed by NI out-of-the-box, than tricksy code like that. I try and push that sort of defence problem to IT. However, when you install LabVIEW the attack surface increases 100 fold. It would be helpful if NI produced a document detailing all the services and background apps - what they do, what they are for and, more importantly, what LabVIEW features rely on which. A lot of them could also be on-demand rather than continuously running as I have found out by trial and error.

Just coerce to lower (or upper) case then it's just y|n|yes|no|true|false|on|off|0|1

You may also be interested in the responses when I posed the question Security? Who cares?. I don't think much has changed since then.

So you are not using client certificates? Verification does not mean "secure". On LavaG it means someone has inspected it and it works without errors and seems to work as advertised. Similarly the NI process is basically a few initial tests to make sure it installs and doesn't impact existing LabVIEW features. It's probably virus scanned several time whilst on the NI network. Yes you are [taking the risk]. That has nothing to do with the "ecosystem". It is the trade-off between your effort and leveraging other peoples effort. It applies to all open source projects. The premise is that security flaws will be identified by having more eyes on the code, not that it is unequivocally "secure". If you want someone else to take the responsibility, then use a company that specialises in security. That is the converse of "monolithic". Many services interacting to produce a cohesive system is what Systems Engineers are for. In that domain there is the concept of "compartmentalise and contain" - meaning attempting to design a system so that problems (be they security or otherwise) are limited to single modules/services and unintended consequences cannot propagate to other services. This is a kind of "design for damage limitation" and you can do your part for your contribution. You can't outsource security and keeping your private keys on some elses server is a trend that I resist. I stated previously that is was a bad idea to connect anything to the internet so connecting everything to someone elses servers that you do not have physical control over, don't know where it is residing, and that can be cut off on a whim is not a viable solution for me.

A bit of light background reading.

Yes. I'll see if I can upload the video to my website for download. There are some interesting responses from NI.

If you are using "WSHttpBinding" then that is SSL, IIRC. You can sniff the network packets with wireshark if you have the private key(s). You should always go over others code regardless of licence (if you have the source). At the very least, one might learn something. That's what Limited Liability Insurance is for but there are some things you can do to try to mitigate these possibilities (no USB ports, no network access, basic OPSEC etc.). OpenSSL is written in C. You are using .NET (C#?). You could write an SSL protocol provider in LabVIEW, if you wanted to. They may have bugs, but the protocols are language agnostic as are mitigations such as keeping a server room locked, not connecting an application to the internet/network and not telling people your passwords. Security is a huge specialist domain. You will hear about things like "defence in depth" which means not relying on a single mitigation or security feature, rather, many layers of protection. "Reducing the attack surface" - making methods of ingress as small as possible whilst still maintaining functionality. You are thinking about it, which, IMO, is already ahead of the average programmer (especially in IoT ). There was a very good video at one of the NI meetings at CERN by their IT manager (2014ClaEu_Day3_03_Control System Security). Well worth a watch if you can find it. Good communication with an IT department is paramount as they are your first and best line of defence and have the expertise. Once an adversary is inside the network, your options are more limited and they have demonstrated a certain skill level. Oh yes. One final point. DON'T CONNECT ANYTHING TO THE INTERNET!

If you are writing the software, then it is all within your control. What do you consider "reasonable"? What is a .net secure comm? What has licencing to do with security and what are you afraid of and whom? (refer to my previous statement about threat models). Security is language agnostic. Kind of. For the most part they think long and hard about certain things but my biggest bugbear is their deployment of OpenSSL libraries which is sporadic and doesn't seem to have a high priority in keeping up to date. I have, on more than one occasion, thought about deploying my own instead of using theirs for this reason.

You're welcome. Maybe it's time to think beyond the ostrich defence to adversaries?

I'm not so sure. For it to affect LabVIEW you have to open it. If that results in a crash then you have to restart LabVIEW (which will be fine) and then open it again for it to crash again. The effect doesn't seem to have LabVIEW-wide permanence so I'm not sure how you would DOS LabVIEW, rather, a developer would just curse the VI and move on unaffected. I suppose a plug-in architecture may be problematic, but as soon as a plug-in keeps crashing I expect it would be removed. The demonstrations also don't show a privilege escalation, rather, some C code to memcpy. Apart from the glaring obvious question of how do you execute C code within LabVIEW without DLLs etc; the exfiltration would be somewhat problematic. There are several levels of additional complexity to make that a useful attack. I'm not saying it can't be done, but for a random VI on the net or in your email client, there doesn't seem to be much of a consequence from opening it that we don't experience daily anyway-LabVIEW crashes or out of memory. That's why I remain unconcerned about this particular threat, for now, as it seems more of an academic exploit. There are far more egregious methods of DOSing LabVIEW applications and if it were shown that arbitrary code in the VI could be executed (therefore making exfiltration easier) then I would probably be more concerned.

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.

Quite probably. But I have a VI lib for setsockopt that works on Windows, Linux and Mac for the aforementioned calls. The knarly part is the path to the libraries that implement it.

The only difference is 0x1 for Linux (SOCK_STREAM) and 0xFFFF for windows (SOL_SOCKET). For Linger, Buffer sizes and Nagle the parms and constants are identical between platforms. Besides. The issue he is having is under windows as far as I can tell.

Well. The VI is in vi.lib but the Nagle vi uses setsocketoption so it would just be a case of changing the level to SOL_SOCKET, the optname to SO_LINGER and supplying a cluster of of 2x UINT16 for the optval.

Just spit-balling but you may be seeing the effects of lingering. (or not lingering as the case may be) You can try setting the linger ON with a zero time-out (using setsocketoption) which will cause an abortive close. There is a VI that enables one to obtain the underlying raw TCPIP connection that can then be used by setsocketoption. It's usually used for TCP_NODELAY

Personally. I would start by looking at the TCP/IP connection. In your original code; you are opening and closing the connection with every image (or every couple of images).That is inherently slow. I would be looking to keep the connection open during acquisition and trying to stream the data to the receiver. You haven't stated your image size and frame rate but a 640x480 image at 30fps is about 70Mb/s which is achievable even on a 100Mb wired connection. This is what I was hinting at when talking about optimising and that it probably wasn't sufficient in its current form. Additionally, it would also solve your closing prematurely problem.

Try both and see which one fits your project. I think you will find your current VI will be insufficient for what you are trying to achieve. The thing to be aware of with the producer/consumer it that it always ends with the same quandary - what to do if the consumer cannot keep up with the producer? If your current code can keep up, that's fine. If it can't; you need to optimise. If it still can't then you need to send pointers rather than data (kind of an optimisation). If even that doesn't work, you need to decide what data to lose. If you can't lose any, then........ Yes. As it stands currently, inside.

Take a look at the producer/consumer. There is a project template when you create a "new" project.

Database. Learn about graphs and advanced data structures. I would recommend SQLite, MySQL or Postgres (and you shouldn't be putting it all in a single table.)

At a very simple level just add a conn.send('ACK') after print('File has been saved.') in your Python code. Then in your LabVIEW code insert a Read.vi before the close.

Yeah. It's not ideal since it depends on how much data is being sent. A more robust method is to send an ACK back so that a read function (before close) blocks until all bytes have been received.

Add a delay between the last write and close and make sure you are not terminating (closing) the connection before all bytes have been transmitted.

But I was promised in the 1980s that we would all be working 2 day weeks by now because of the automation. That would be a better way to solve the traffic problem

We should start using the Deci calendar immediately

OK. That's fair enough. One thing to be aware of are functions that you can request, say, 1024 bytes but they can return less. In that scenario the length is often written to with the actual bytes transferred. Then that "actual" value should be used with a resize array on the data read. With those types of functions it is also a common error to choose "value" instead of "pointer to value" for the length since 99.9% of the time it seems to work fine with "value"....until LabVIEW crashes 7 hours into a test