UDP security loophole?

[mathgeek0001]

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?

[martin417]

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

[Greg McKaskle]

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

Greg Mckaskle

[Pirate King]

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

Greg Mckaskle

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.

[Greg McKaskle]

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

[Mark McLeod]

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.

[Pirate King]

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.

[Mark McLeod]

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

[Pirate King]

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

[Alan Anderson]

Correct me if I'm wrong. So any commands or packets on the field no matter what network go through the FMS.

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.

[RufflesRidge]

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.

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.

[mathgeek0001]

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

[Mark McLeod]

Wait... so are you saying that all that work adding an authentication sequence to my standard UDP packet was for naught?
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.

[virtuald]

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.