UDP security loophole?
 

It has come to my attention that there is a potential security loophole for teams (like us) who are using UDP to send data from the dashboard to our robot. The LabVIEW UDP Recieve function (and to my knowledge, UDP in general) does not check sender IP. Hypothetically, it would be possible for a third party to send faulty packets to our robot (by sending UDP packets to 10.te.am.2). It does not seem to be a rule against said communications. Is there a good way to confirm sender IP in a UDP connection?

Re: UDP security loophole?
 

At the competition, your bridge will encrypted. Unless the hypothetical evil team has your encryption, they can't send to your bot.

Re: UDP security loophole?
 

Encrypted and isolated. The field actually builds six distinct wifi networks, one for each team.

Greg Mckaskle

Re: UDP security loophole?
 

Then how do they control you robot if the networks are separate? If they really are separate then they would not be able to enable all the robots because of the different networks. They must be bridged somewhere along the way. If so then it really is not isolated.

Re: UDP security loophole?
 

Good observation. There are six networks, each with a robot, DS, accessories like cameras, and ... an FMS NIC.

The FMS is omnipresent, on the field anyway, and the only way the robots or DSes can communicate would be by asking the FMS to pass a message. They can't directly communicate because nothing will route between the networks unless the FMS explicitly does it. Does that info make more sense?

Greg Mckaskle

Re: UDP security loophole?
 

I just want to add that the command flow is:

FMS -> Driver Station -> Field AP -> Robot radio -> cRIO

FMS orders the Driver Station to do something (Disable, Autonomous, Teleop, eStop, Bypass), and the Driver Station passes the order (and it's own user control commands) along to the robot.

All occurs on a VPN individual to each team, so there are six VPNs operating in parallel while the robots are on the field.

Re: UDP security loophole?
 

Ok i get it, but there still can be something done. Correct me if I'm wrong. So any commands or packets on the field no matter what network go through the FMS. Then a "EVIL" team could still mess other people up. It can take lots of work and stuff like that but they can spoof the IP and MAC addresses of some of their packets to mess with some other robots on the Field.

Re: UDP security loophole?
 

It's much easier to just bribe a team driver to trade sides...

Re: UDP security loophole?
 

Bribing teams... Security Loop Holes.... Not int he spirit of FIRST LOL

Re: UDP security loophole?
 

Okay, you're wrong.

No communication goes "through" the Field Management System. The mode commands (auto/teleop, enabled/disabled/emergencystopped) come from the FMS and go to the Driver Station, which forwards them on to the robot along with the joystick data. This all happens on a closed virtual network, which only one team has a connection to. "The FMS" has a separate presence on all six virtual networks, and no routing takes place between them.

Re: UDP security loophole?
 

Spoofing your IP won't do you any good, you're still not on the right vLAN.

There are much easier ways to cause field problems even with the WPA system in place, which I won't go into for obvious reasons, but I have not heard of it happening in 3 years and it is strongly against the spirit of the competition.

Long story short, there are much better ways to spend your code development hours than worrying about security of custom UDP communication.

Re: UDP security loophole?
 

Wait... so are you saying that all that work adding an authentication sequence to my standard UDP packet was for naught?

Re: UDP security loophole?
 

Yea, that's pretty much a waste of time and resources for our robots.
Maybe you learned something though, then it'd have been worthwhile.

Re: UDP security loophole?
 

FRC Robots should never be connected to an untrusted network -- EVER. Consider the following:

• All robots ship with an active FTP server with username/password FRC:FRC, which allows you to reset the software to anything you want
• You can completely reimage a rebot without authentication
• For robots running windriver, a debugger can connect without authentication -- I'm sure you can load labview code without authentication too
• If you have NetConsole active, then you can run arbitrary commands on the robot using a shell. Once again, no authentication.
• I'm sure there are many other things

So worrying about dashboard communications is the least of your worries.