I have been asked by my IT department how a LabVIEW application is secure

[Taylored_Solution]

In general how does a standard LabVIEW application respond to these requirements:

The runtime environment shall not be susceptible to buffer overflows, SQL injection, LDAP and XPath injection, code injection or any other injection flaws. Malicious file execution and insecure direct object references shall be prevented at all times. 

[Sam_Sharp]

Interesting question...

It depends on what the application does and how securely it was written! Of course...if your application executes files, loads & runs VIs dynamically, communicates with a database then code could be injected in etc.

I think the most obvious one which could probably apply to most applications would be to make sure that VI Server is disabled on the application as this can be used to manipulate the application externally.

If it's an application that you're developing then how do they handle this for other programming languages? You can of course get them to test the application (haha...yeah right...) for these things if they are unsure! If it's an application that you've bought/been provided with then you have to make a judgement as to how secure you think it is.

[QFang]

I know certain ActiveX actions that are deemed "security risks" will now generate errors in the LabVIEW Run Time Engine unless the registry of the host computer has been specifically modified to allow such ActiveX calls.

I guess my point is, NI does take some steps to prevent some issues at the run-time level regardless of how your code is written, so if that is the level <they> are concerned about, I would reach out to my local NI Field engineer and/or NI Customer Support and ask for help in how to answer <them>.

As Sam_Sharp pointed out, there are several things that are difficult/impossible for the RunTimeEngine to protect against, in any language.  If the author of the code does stupid things or deliberately has maliscious intent, there are many things they can do that is outside the bounds of an RTE.   In LabVIEW, some of the 'holes' in other languages are hard (impossible??) to do.  For example, you as a coder, do not have access to creating and manipulating pointers, so you can't create code that intentionally overwrites other [edit: memory-]sectors in the host machine memory.  So that would also be a case of where the run-time-engine (and its memory manager) plugs (or significantly shores up) things and makes it "safer".

The main security threats I see coming from the LV RTE engine is that there is no way the RTE can protect against malicious file removals, file hashing, injecting bad commands and/or data into network(s) and databases etc., beyond the protection offered by the OS (file/folder permissions) and IT infrastructure (firewalls, database query protections etc.).

Not sure any of that helps you out or not.. A dialoge with NI seems required for you, perhaps bring together reps' from both parties (NI field engineer and your IT people) so that they can get a line of communication going.

[RTSLVU]

What kind of attacks are they worried about?

If your Labview exe is running behind an enterprise quality firewall there should be no way for an attack from outside to exploit any vulnerabilities in Labview.

If it's an inside job they are worried about I really doubt your Labview program will be the attack vector.

[zou]

Anti-code injection should be a requirement for the OS, the anti-virus tools, and the IT department, NOT at the application level !

Does application built by C++/VB can reject code injection ?