Responsible disclosure practices
 

As FRC's control system moves towards popular technologies, it seems inevitable that security vulnerabilities will be discovered in components of the FRC control system. If someone were to find a software vulnerability somewhere in the FRC control system, what's the procedure to responsibly disclose it to FIRST and allow ample time for patching before public disclosure? Previous exploits have been demonstrated against FMS publicly (you may recall the 2012 Einstein incident), and I think it would be a good idea if FIRST had some clear policy laid out so people don't resort to demonstrating exploits live.

Re: Responsible disclosure practices
 

It's worth noting that the FRC control system is *not* designed for security. As far as I've seen, none of the communications control protocols are encrypted or authenticated in any way shape or form. The roboRIO by default ships with blank passwords, and anonymous FTP is enabled.

For example, without trying actually trying it, I'm 100% sure that a robot could enable itself without the FMS directing it to do so. Some unscrupulous team could definitely (in theory) enable itself before autonomous mode started, for example. But, given that humans are refereeing the competition, it seems likely that a cheat in that manner would get caught.

As far as security on the field, I believe the thing keeping teams on separate networks from each other is mostly enforced at the router level. Most cheating that could happen here would probably be noticed by someone somewhere, and be difficult to get away with.

With that said, if you have a concern, I would recommend contacting one of the NI people on this forum as a first stop, or find Kevin O Connor's email at FIRST.

Take a look at the manual, T5.

Re: Responsible disclosure practices
 

That would only apply to exploits of the wireless network itself, though.

What if someone loaded arbitrary firmware on the RoboRIO, for example? (Version numbers or even hashes can be spoofed if you're running arbitrary code, so how would the FMS know?)

Re: Responsible disclosure practices
 

Thanks! I knew performing exploits was against the rules, but the linked form is exactly what I was looking for

For anyone else who comes looking for it, here's the link
http://www.usfirst.org/roboticsprogr...urity-web-form

Re: Responsible disclosure practices
 

Who cares, honestly? The primary reason for required versions/etc is generally to fix safety or bugs in the underlying code that your robot software interacts with. If a team wanted to tinker with things like firmware, it's hard to imagine what competitive advantage you would gain from doing so.

Given that FIRST does not restrict roboRIO software in any way (other than disabling motors in particular modes), and that you can put coprocessors on board, it's hard to imagine why one would bother with such a thing.

Re: Responsible disclosure practices
 

R55 also applies in this situation, particularly point (a)

Remember that the FMS talks only to the DS, which in turn controls the robot. The DS and the robot are inside the same security boundary, so code on those two would only be a vulnerability to the extent that they impacted the operation of the FMS, other robots, or other driver stations. What Raymond Chen says about the airtight hatchway applies here as well.

Re: Responsible disclosure practices
 

Ari,
The best procedure to make a report is to contact FRC engineering. If you want to be discreet, report it to me, I will forward your message to HQ.

I know that several industry professionals are involved in FMS security issues. I worked with some of these people at the Einstein weekend a few years ago. These are the top guys at Qualcom, Linksys, D-Link, Cisco, etc. I know that they gave an list of security items and recommended procedures to FRC at that time. Please remember that the intrusion did not take over the field control, it redirected traffic flow. The break was caused by a firmware upgrade in the FMS wireless router when used with a particular D-Link radio series and only when an attempt to connect occurred.

Re: Responsible disclosure practices
 

The standard practice for white-hat hacking is to report it to the designer discreetly, and if they don't do anything about it after a year or so, then publish on it. Don't demonstrate at an event or anything. Write up a white paper and publish it. Otherwise there is no pressure to actually fix what's broken, and if you found out about it, you can assume someone nefarious knows about it too.

Re: Responsible disclosure practices
 

Really? You can't think of anything? I don't want to list stuff explicitly, but this doesn't take a whole lot of imagination.

Re: Responsible disclosure practices
 

The only thing that I can think of would be enabling yourself prematurely, or keeping yourself enabled after the match is over. However, either of these would be pretty easy for someone to spot if you gave yourself more than half a second. And, as I pointed out above, you don't need to modify firmware (and it's much less risky!) to accomplish either of these.

Re: Responsible disclosure practices
 

Half of a second is an eternity in this game. Even a quarter second would be a ridiculously large advantage.

I'm not sure why messing with the driver station would be easier. Wouldn't the team who wanted to do this then have to conceal the modified communication to the robot?

Re: Responsible disclosure practices
 

Given the few amount of robots that even *move* in autonomous mode this year, I think if you're playing at a level where that amount of time matters, it would be a waste of time to cheat here.

I wouldn't send the packets from the driver station, I'd send them from the robot itself over localhost using a raw socket to spoof the source -- remember, no authentication/encryption is done anywhere. Worst case scenario, you have to make a kernel driver to do it, but I doubt that's necessary. All of this is easier and "safer" than messing with the firmware which we don't have the source for, and would be really easy to hide.

Re: Responsible disclosure practices
 

I agree that for a majority of teams starting a match slightly early wouldn't matter. However, that doesn't mean that there isn't a huge advantage. For example, suppose that one team at an event was allowed ignore the weight limit. If the team competed with a 150 lb robot it would be unfair regardless of how that team did on the field.

I would hope that the teams who would be capable of this would all think better of it, but I bet multiple teams per division at championships would have an unbeatable can-burgler if the FMS started them 1/4 second early every time. And I bet one of them would win. On the other hand, everything's on camera and the movements of most can-burgler mechanisms are not subtle.

Re: Responsible disclosure practices
 

Right, totally forgot about the can burglers. That's somewhere that 1/4 second could definitely make a difference if you're facing another can burgler.