Bug in determining correct host/IP of client with shared variable ACL

[Novgorod]

Hi,

I have a PC with DAQ hardware and a little "server" application, which lets multiple clients query processed measurement data via shared variables. Since it's deployed on a university network, I don't want everyone on the network to access the shared variables, especially since some are also used to control the server by the clients, i.e. have write access. For that, I use the DSC module, which provides simple shared variable security via access control lists (ACL). It lets me set up a list of the IPs or host names of all machines on the network, which are allowed to access the shared variables (with some reverse engineering this can be even done programmatically; thanks for the comfort, NI ). I know it's not perfect security, since anyone can spoof the IP or host name if he gets to know the list (but would risk IP collisions on the network), but it's secure enough and I intentionally don't use the user/password security in order to keep it simple and (more importantly) backwards compatible with older client software.

Now for the bug: Apparently, the client sends his host/IP to the shared variable engine without verifying that it is indeed the IP of the actual network connection between client and server. If the client has several NICs installed, it pics the host/IP of one of the NICs (probably the first one listed in the system?) and sends it to the server for authentication. For example, let's say the client has a network camera or some other local device attached to a dedicated NIC (#0), using the IP address of 10.0.0.1. The client is also connected to the LAN with a 2nd NIC (#1), using the address 192.168.0.3. The shared variable ACL authentication doesn't work if 192.168.0.3 is in the server's ACL - it only works if 10.0.0.1 is in the ACL, but that IP is not even on the same network. This is quite an issue because it makes the entire ACL authentication unpredictable and potentially even less safe if I have to whitelist generic IPs like 10.0.0.1, which are e.g. used for local devices, in order to get clients with multiple NICs to work (the bad guys can simply spoof a 2nd NIC like that and wouldn't even cause collisions on the "real" network).

I know this is a bit of an exotic application case, but there must be a way to force a client to send the "correct" NIC's host/IP for authentication or otherwise the whole point of shared variables ACL is missed. Can anyone think of a solution and is this known to NI?

[mikeporter]

Are you married to using shared variables? There are other techniques that are easier and don't have the added complication of having a separate shared variable engine running somewhere. Shared variables can also be very inefficient if the size of the data is large.

I'm thinking specifically of VI Server.

Mike...

[Novgorod]

Can you elaborate what you have in mind? It's not a huge project and the data volume and update rate is very moderate (max. a kilobyte or so per second per client), so shared variables seem to be the most suitable solution for easy network access...

I know VI server has very easy to configure ACL (and I'm wondering whether it has the same host/IP bug; I'll test it), but how would that be "better" than shared variables? You'll need to access data via references and properties, right? I have no problem with the SVE service running in the background, the only issue is reliable authentication...

[Novgorod]

It's been almost a year now... Could anyone reproduce the bug and does NI know about it?

[billko]

I don't think it's a bug.  I'm pretty sure the operating system handles where the packets are supposed to go.  You can force an application to use a certain connection, but that's a Windows thing, not a LabVIEW thing...

[Novgorod]

Maybe I didn't say it clearly enough in the first post: The client reports a wrong IP address to the server and the server "believes" it without checking the actual IP address of the client's connection.

There is only one physical network connection between the client and the server (192.168.x.x in my example). Additionally, the client has another NIC connected to a completely different and isolated network (10.0.0.x), which exists e.g. only between the client and an IP camera device or something like that. The server doesn't know anything about that other network and there is no physical way for the client to reach the server through any other NIC than the one bound to the 192.168.x.x network! The physical ni-psp connection is therefore established over the 192.168.x.x network but for some reason (probably the enumeration sequence of NICs in windows) the client wrongly reports his other 10.0.0.x address to the server and the server doesn't verify it.

I don't have time to reverse engineer the ni-psp protocol, but I assume that upon connection the client says to the server something like this: "I'm a psp client, my IP address is 10.0.0.1 and my computer name is such-and-such". This would make kind of sense, because the ACL works also with computer names (afaik) and I don't think the psp server has anything to do with NetBIOS/WINS and all that windows network stuff (plus it has to be system independent to work on Linux/embedded as well). However, this would defeat the whole purpose of ACL for shared variables because anyone who talks psp could spoof any "authentication" information. I don't know how to work around that in the case of computer name/DNS (other than not using it at all), but at least in the case of IP address authentication it would be trivial for the server to compare the announced IP address by the client with the actual IP address of that connection (or ignore whatever the client announces). And the client implementation for windows should do the same check before announcing the IP address to the server, rather than blindly taking the first enumerated IP address of the system...