ShaunR

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

Well. It's probably a bit more than that. How do you know how big of an array to pass? If data overwrites the end of the array it will crash LabVIEW.

I haven't looked but it sounds like a c string issue. Rather than returning an array of bytes, a c string type is used to get the data into LabVIEW. Often people prefer the c string because it only requires one call forgetting it can't be used on binary data, whereas to get an array of bytes you usually have to call the function first with a NULL array of length 0 to get the length then call it again with an array of the right dimension size (if there is no dedicated function for that purpose).

I don't know about Zxing but the LabVIEW bar code reader reports it is a Pharmacode with the string "1314"

Never expose a database directly and always always use TLS or SSH tunnelling. Use certificate pinning wherever possible. The preferred method is a web server to authenticate and then HTTPS or websockets depending on the type and frequency of data. The current trend is for web APIs which you can easily do in LabVIEW and insulates your software, somewhat, from SQL injection.

The VI is incomplete. If you press the run button it will show you the errors and most of them will be unwired inputs. The TODOs need to be implemented.

Isn't that what non-disclosure agreements are for?

I think you are going to need NIs input on this one.