Vulnerabilities found in NASA’s open source software

Vulnerabilities in open source software developed and used in-house by NASA could be exploited to breach their systems, claims Leon Juranić, security researcher and founder of cybersecurity startup ThreatLeap.

The vulnerabilities

Juranić, whose AppSec credentials include founding and leading DefenseCode, is no stranger NASA: in 2009, he discovered and reported a number of serious vulnerabilities in NASA’s Common Data Format (CDF) software library, which ended up getting fixed by the developers.

His latest probing of NASA-developed open source software was limited to 4 hours of manual code analysis, but nevertheless unveiled a slew of vulnerabilities.

He discovered a stack-based buffer overflow vulnerabilities in NASA’s Portable Environment for Quick Image Processing (QuIP), then decided to look for more of them in similar tools used by the agency.

“[The] main motive and reasoning behind that was that all over different NASA’s code in GitHub repositories there is a whole bunch of NASA’s specific file formats processing, and maliciously constructed data files can easily be slipped to the victim over an email or over the web,” he explained.

He quickly found other buffer overflows stemming from use of an inherently insecure function in:

• OpenVSP (Open Vehicle Sketch Pad), a tool for creating 3D models of aircrafts for engineering analysis purposes
• RHEAS (Regional Hydrologic Extremes Assessment System) software
• OMINAS (Opensource Multi-INstrument Analysis Software)
• Refine, a 2D and 3D mesh adaptation tool
• The CFD Utility Software Library (aka CFDTOOLS), which contains numerical analysis libraries and utility applications built on them, and
• The knife library

While he also discovered a reflected cross site scripting (XSS) vulnerability and hard-coded secret values in several web applications developed by NASA, the memory corruption flaws found in the various file processing software applications stand out as particularly alarming as they could allow for remote code execution, Juranić told Help Net Security.

“I didn’t bother to prove that the discovered straightforward vanilla stack based buffer overflows can be exploited, but I didn’t find obstacles to why they wouldn’t be exploitable – the vulnerable code was reachable remotely during the parsing of particular file formats,” he said.

State-sponsored threat actors could exploit those flaws to compromise computer systems at the US space agency, as well as at other institutions (government-operated and not) that use the vulnerable software, he added.

While a successful attack hinges on target employees being tricked into downloading and opening specially crafted files, this particular hurdle is overcome by attackers every day. “And standard defensive systems like AV, EDR, IPS and IDS usually don’t pick up and protect from threats of that nature (i.e., zero-day exploits in maliciously crafted files),” he pointed out.

Juranić declined to speculate why these security vulnerabilities haven’t been caught and remediated earlier, but says there’s obviously room for improvement in NASA’s software security processes and NASA’s SRA (Software Release Authority) policy, which is not as comprehensive as it should be.

“Common security practices for Secure Software Development Life Cycle (SDLC) are a must these days in every aspect of software development, especially for government agencies and their contractors,” he opined.

Vulnerability reporting problems

“I was quite surprised by the number and severity of security vulnerabilities that I discovered in such a short time by simply grepping for ‘questionable’ stuff in the code – especially since some of these software projects are used in NASA as a part of space missions or data processing,” Juranić told us.

Some bugs are so complicated that they remain undiscovered/undisclosed for over decades in even the most popular, internet-powering software, he added, but these are of the “low hanging fruit” variety.

“I’d be quite surprised if I’m the only person on the planet interested in discovering vulnerabilities in NASA’s in-house developed and used software, since it’s available for anyone on NASA’s official GitHub account.”

He has reached out to NASA a dozen times via different email addresses to share his findings, but did not receive feedback. A phone call to NASA’s security operation center (SOC) revealed that the agency’s official policy instructs them not reply to vulnerability reports made by individuals outside of the organization.

NASA’s official software Github account (as referenced here and here) is apparently not under NASA’s bug bounty program, he also pointed out, making it complicated to report unearthed security issues via public bug bounty platforms.

We’ve reached out to NASA for comment, and we’ll update this article when we hear back from them.

Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!