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.

Re: Responsible disclosure practices
 

I'm not certain whether the original question was more about securing your device from external entry, or about teams looking for an advantage. But either way, the link given by Joe would work. It is also a good place to send safety concerns.

Just to comment a bit on the topics...
Not really true. Locking a door doesn't prevent someone from breaking in, but it does deter. Putting a bomb shelter door on a house with windows doesn't make it safe. It just makes it really hard to enter and leave the house.

There are many ways to cheat in FRC, but there are also many deterrents. I don't think cheating takes place in FRC very often, and I don't think it would be as easy as presented.

I ask that you not speculate or scheme online because information that you discover but are above using as a cheat may be just what someone else is looking for. That is why the link exists. Do your part to show how a community should deal with security.

A few more thoughts...
Robots that gain weight, grow a new limb, or move when they shouldn't can be reinspected.
Students who impale an opposing robot with a pool noodle may be checked for performance enhancing compounds.
Robots that don't obey the laws of physics will be checked for alien technology and magic.

And yes, we think about it.
Greg McKaskle

Re: Responsible disclosure practices
 

You can't see the "magic check" on the RI checklist, because (obviously) it's not visible to team members and mentors, only to robot inspectors.

Getting an edge through cheating can be tempting, and it's easy to only think about the upside -- the glory of winning. Those feeling tempted should also imagine the incredible shame that would be brought upon their friends and teammates should their actions be discovered. Think about an article on Frank's Blog describing the situation in detail, and the 200 post thread that would ensue on CD. Think about the likelihood that your name would be associated with the cheating. Picture what it would be like to tell your parents about it. Imagine explaining to employers your involvement, or failing a background check for your new job due to "trustworthiness" issues.

Re: Responsible disclosure practices
 

Exactly. When I said the control system, I was specifically referring to the DS -> Robot communications not being authenticated/encrypted. The FMS/etc is a separate matter that I have zero knowledge of. Given that the game is judged by humans watching every move a robot does, it doesn't make sense to bother with encryption/authentication at that point (see the reference to Raymond's airtight hatchway that MrRoboSteve mentioned). Anyone performing an attack as I mentioned previously would almost certainly be noticed.

If I had thought there was a risk of someone cheating using the method I mentioned, then I would have sent an email to FIRST long ago, and wouldn't have mentioned it in a public forum. But the risk is minimal, the gain is minimal except in very subtle circumstances, and the downside from it is too great as MrRoboSteve mentions.

I'm not convinced that speculating in a public forum on the ways one could cheat is necessarily a bad thing either. The more ways that are publicly known, the more they will be watched for, and the harder it will be to actually do any of them -- which is a good thing.

I suspect if people intentionally cheat in FIRST, they almost certainly do it via some mechanical cheating mechanism or violation of materials rules. I stand by my assertion that cheating via software that only affects your robot in a non-mechanical way is mostly useless. [Edit: with the exception of methods that provide human input to autonomous mode, but even then, mostly useless in this year's game]

Re: Responsible disclosure practices
 

Even this is tough. There are a bunch of people with a good view of you if you try to do this, including the referee who is standing at the end of the white line.

Re: Responsible disclosure practices
 

One problem with enabling your robot early is you don't know when the game is going to start. If you have a reliable way of predict that, then you are slumming & probably should be doing something other than FRC. :]

Everything is over managed switches so should be difficult to directly interfere with another robot. Although certain combinations of robots play havoc with the FMS system. Keep in mind network traffic is monitored. Consequences for being found out is likely to be severe for the team & individual.

Re: Responsible disclosure practices
 

Agreed. And given there aren't any dynamic elements this year, there's not significant benefit either.