How to uniquely identify serial resources without relying on NI MAX aliases?

[ijustlovemath]

Hi all,

I discovered a rather interesting (and alarming) behavior when doing some routine testing on a control system I work on.

The system has two pumps, A and B, which each infuse a unique substance into the system in order to control it. Years ago, I found that you could uniquely name a device in NI MAX so that every time it is plugged in, no matter the port, it shows under the same name in VISA controls.

Yesterday, I was explaining this to a colleague, and how NI MAX must have some sort of internal database which maps some unique identifier on the device to this alias. This is then communicated to running applications who request VISA resources through some proprietary protocol, indirectly connecting the applications to the hardware. As a proof of concept, I opened NI MAX while the application was running, renaming the alias of A to the alias of B and vice versa. Then, magically, pump A thought it was pump B and pump B thought it was pump A.

This obviously alarmed my colleague who was instantly thinking of the security risks of such behavior, which are indeed pretty grave for our application.

The fact that you can hotswap aliases with only a minor popup box warning that such an alias already exists, and have the same aliases refer to different devices with the application none the wiser is very cool from an architecture perspective, but not cool for the security risk.

In an ideal world, we'd still use aliases for initial setup, but would cache some specific device identifiers which uniquely identify the pumps so this hotswapping behavior does not occur. I know there's the Vendor ID and PID, but I don't think those are unique to every pump.

So, here's my question:

- How does NI MAX map these aliases uniquely (regardless of port, cable, plug in order etc) under the hood? Can an applications programmer access those mechanisms through VISA property nodes? If so, how?

[JÞB]

VISA maps an alias to a serial device enumeration.  Serial enumerations are maintained by the Windows registry under the serenum Hive Keys <HKEY>

LabVIEW does have a Windows Registry API and a System Hardware API.  Between the two you can inspect and the unique identification of your pumps and programmatically validate / repair VISA aliases that may have been tampered with.   You will need administrative privileges to mess with the HKEYs.

[ijustlovemath]

Read access to registry requires admin privs? That's less than ideal, we'd like our application to run with the minimum privileges possible... but that's very useful, thank you!

[billko]

---

@ijustlovemath wrote:

Read access to registry requires admin privs? That's less than ideal, we'd like our application to run with the minimum privileges possible... but that's very useful, thank you!

---

I think he was referring to "fixing" tampered registry settings.

[RTSLVU]

---

@ijustlovemath wrote:

Read access to registry requires admin privs? That's less than ideal, we'd like our application to run with the minimum privileges possible... but that's very useful, thank you!

---

Well speaking of privileges, I believe NI-Max needs to be ran "as administrator" to make any actual changes to VISA alias.

So simply restricting the user to a "standard user" and not have "local administrator" privileges should prevent a user from making those changes.  

[ijustlovemath]

The post is not about the security concern of users tampering with registry settings; the app currently runs with read and write permissions to a single directory, the lowest possible level of access.

The concern is with NI MAX (which can be ran as a standard user, try it), in which a user can rename existing aliases with the app none the wiser.

As a proof of concept, try this:

1. Setup a serial device that writes to a port continuously, name this device "TestDeviceA" in MAX

2. Setup a second serial device that does the same, name this device "TestDeviceB" in MAX. Make sure they are writing different data.

3. Write a simple VI with two loops that reads from "TestDeviceA" in one loop, and "TestDeviceB" in another loop, outputting to a string (concatenating old to new with a feedback node or similar)

4. Run this VI.
5. While the VI is running, open NI MAX, rename "TestDeviceB" to "TestDeviceA." MAX will warn you about the existing alias, but will allow you to make the change.

6. TestDeviceA will now be named "TestDeviceA-1", and its loop will now be reading from TestDeviceB. TestDeviceB's loop will fail to read anything.

7. Rename "TestDeviceA-1" to "TestDeviceB" and the loops will have completely switched.

Perhaps that makes the original concern a bit more clear.

[RTSLVU]

---

@ijustlovemath wrote:

The concern is with NI MAX (which can be ran as a standard user, try it), in which a user can rename existing aliases with the app none the wiser.

---

Interesting as every computer in our lab pops up the Windows UAC and requires an administrator password to even launch NI-Max.

[ijustlovemath]

What version of NI-VISA are you running? I'm not seeing any UAC prompts for MAX.

[FireFist-Redhawk]

---

@ijustlovemath wrote:

The concern is with NI MAX (which can be ran as a standard user, try it), in which a user can rename existing aliases with the app none the wiser.

---

There is probably a more elegant solution to your problem, but just so you are aware, you can configure NI MAX (and any other program) to run as administrator by going to the location of the executable file, right click, Properties > Compatibility > Change settings for all users > Run this program as an administrator.

[RTSLVU]

It's not NI-Max it's the way Windows UAC and user privileges are set up.

As machines where I use my user login and I am set as "local administrator" NI-Max runs without UAC popup.

But on our lab computers where we use a "generic user", that generic user is restricted and NI-Max requires administrator privileges