UDP security loophole?

[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]

Originally Posted by Pirate King

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]

Originally Posted by Pirate King

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]

Originally Posted by mathgeek0001

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.