Search for: All records

As our reliance on micro autonomous vehicles in- creases, security vulnerabilities and software defects threaten the successful completion of tasks and missions. Recent work has developed end-to-end toolchains that provide trusted and resilient operation in the face of defects and attacks. These toolchains enable automatically repairing (and patching) the control software in the event of a failure. Existing techniques force the subject control software to terminate and the vehicle to be motionless, making the restart or post-repair deployment more complex and slow. The challenge remains to ensure that vehicle control software can recover from attacks and defects quickly and safely, even while the target vehicle remains in motion. This paper presents a technique for faster, simpler, and seamless hardware switchover that operates while the vehicle is in motion. The key contribution is the ability to restart the control software post-repair while the vehicle is in motion by transplanting sensor data between onboard control computers to bypass a costly portion of initialization. Although existing check- point and restore methods allow software to recover execution at a known-functional state, they are not lightweight enough to support recovery during mission execution. Instead, our approach transplants known-good sensor data from a trusted, isolated execution environment in the onboard computing hardware. Our evaluation successfully reproduces prior simulation results in hardware. Further, sensor transplantation allows for successful initialization while in motion, reduces time-to-ready by 40%, and is robust to variances in sensor readings. 

The use of third-party libraries to manage software complexity can expose open source software projects to vulnerabilities. However, project owners do not currently have a standard way to enable private disclosure of potential security vulnerabilities. This neglect may be caused in part by having no template to follow for disclosing such vulnerabilities. We analyzed 600 GitHub projects to determine how many projects contained a vulnerable dependency and whether the projects had a process in place to privately communicate security issues. We found that 385 out of 600 open source Java projects contained at least one vulnerable dependency, and only 13 of those 385 projects had a security vulnerability reporting process. That is, 96.6% of the projects with a vulnerability did not have a security notification process in place to allow for private disclosure. In determining whether the projects even had contact information publicly available, we found that 19.8% had no contact information publicly available, let alone a security vulnerability reporting process. We suggest two methods to allow for community members to privately disclose potential security vulnerabilities.