DevSecOps, Supply chain

‘Trojan Source’ potentially opens organizations to supply chain attacks

A computer screen is filled with code during a hackathon event on Feb. 1, 2014, in Miami. (Joe Raedle/Getty Images)

Researchers have discovered vulnerabilities (CVE-2021-42574, CVE-2021-42694) they dubbed “Trojan Source” that let attackers manipulate source code so that humans and compilers reviewing the code see different logic while in reality the attackers are inserting malicious code.

In a blog post, researchers from the University of Cambridge in England say this attack works against C, C++, C#, JavaScript, Java, Rust, Go, and Python — and the researchers suspect that it will work against most other modern programming languages. The researchers added that attackers looking to execute supply chain attacks could insert these invisible vulnerabilities into open source projects.

The research released Monday is the latest example of how attackers are innovating and increasing the sophistication of their approaches, said Ronen Slavin, CTO of Cycode. Slavin said these attacks are becoming more prevalent as attackers have shifted their focus from production applications to breaching and weaponizing software supply chains.

“To better protect themselves from Trojan Source software supply chain attacks, security teams should implement security and governance policies across their tooling that check for or disable the use of bidirectional Unicode variables which can render differently than they are interpreted or compiled,” Slavin said. “Very few organizations need, or even use, this feature. So turning it off ensures that security teams can properly peer review code as part of standard branch protection. Consistent governance combined with the ability to ensure integrity and provenance across the software development lifecycle can greatly reduce the likelihood of organizations experiencing software supply chain attacks.”

Jon Gaines, senior application security consultant at nVisium, said this Trojan Source bug certainly presents an interesting attack surface. Gaines said while the the University of Cambridge team conducted novel research, their proof-of-concepts are not actually malicious.

“However, in the hands of a sophisticated attacker or group that can actually weaponize it, we would definitely have a dangerous situation on our hands,” Gaines said. “This scenario demonstrates the proactive power of source code reviews and it’s a good best practice not to copy and paste code for the time being. It's always better to rewrite it yourself. Coders can also enable IDE or text editors to display Unicode. Alternatively, if they do go this route, open up the copy and pasted code within a hex editor to check it. Hopefully patches will be promptly released for most compilers, but in the interim, this would serve as an effective short-term solution.”

Jake Williams, co-founder and CTO at BreachQuest, added that the issues described Monday are definitely serious, but we should examine these in context. Williams explained that to exploit these vulnerabilities, a threat actor would need to change source code that’s subsequently compiled into binary form by a victim.

“This itself is already serious,” Williams said. “The vulnerabilities here abuse Unicode processing algorithms to make backdoors less likely to be discovered during source code review. If you're not reviewing source code for vulnerabilities and backdoors before compilation, there's no practical change to your security after the disclosure of this vulnerability. Finally, it should be noted that some alarm has been raised about Unicode processing by compilers previously. This research shows how widespread the issue actually is.”

Yaniv Bar-Dayan, co-founder and CEO at Vulcan Cyber, said the new Trojan Source code compiler vulnerability will no doubt cause problems for engineering and DevOps teams with poor cyber hygiene.

“It’s especially scary for security and DevSecOps organizations that are in the habit of reacting to exploits if there’s a chance the exploit may go undetected for some time,” Bar-Dayan said. “However, not all is lost, especially for teams that proactively understand risk posture and work to maintain and secure their full attack surface. Often the damage occurs not in the initial exploit, but in the exploit enabled by the initial exploit.”

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.