Researchers from the University of Cambridge have identified a new attack method that abuses Unicode to stealthily inject vulnerabilities into code.
Dubbed Trojan Source, the attack impacts many of the compilers, interpreters, code editors, and code repository frontend services used by software developers. Malicious actors could leverage the method to create code that would be displayed one way in code editors, but be interpreted differently by the compiler.
While there is no evidence of Trojan Source attacks in the wild, the researchers did see similar techniques being exploited, although many were not necessarily malicious.
Industry professionals have commented on the potential impact of Trojan Source and provided recommendations for organizations and developers on improving application security.
And the feedback begins…
Vince Arneja, Chief Product Officer, GrammaTech:
“The kind of exploits identified in the recent Trojan Source research report can fool compilers because these usually don’t inspect comments or Unicode for problems. So a clever malicious actor can insert essentially invisible threats that do not appear as such to the compiler. Similarly, if a human were to inspect the same code, they also would miss it because the text editor conceals comments.
To address Trojan Source threats organizations have to wait for compiler vendors to catch up. However, even if every vendor updated their compiler and back-ported it to earlier versions in use by all customers, companies would still have to endure the pain and expense of upgrading their compiler.
For example, if a development team is 75% of the way into a project that requires IEC certification, that isn’t feasible. However, software composition analysis (SCA) inspects code after it is compiled when malicious threats are visible. That’s because SCA analyzes what the compiler actually compiles, not what shows up in a text editor. SCA was originally created to help development teams comply with software licensing requirements, because it creates a software bill of materials (SBOM). The recent Presidential Executive Order on Cybersecurity calls for the delivery of a SBOM to protect the software supply chain. SCA is emerging as a valuable tool for securing software, with Trojan Source being the latest example.”
Gary Robinson, CSO, Uleska:
“Research like this is a great way to highlight new methods attackers could use to breach software.
This concept is part of a growing area of attacks with a new angle, instead of attacking flaws or vulnerable components, they are using the way software is developed as the attack vector.
There have been other types of attacks in the last few years against the toolchain, or dependency squatting, or similar. Here they are acknowledging the common use of example code that is copy/pasted from popular websites, such as OWASP and Stack Overflow, as part of everyday developer research and implementation.
Thankfully there doesn’t seem to be a current exploitation against this vulnerability, and developing one may not be easy, which hopefully gives the industry time to detect and prevent it. The compiler vendors will be issuing updates soon, and security tools that examine code can check for these specific characters. Even sites like StackOverflow and GitHub could prevent these characters from appearing on their websites.
This reinforces the need to be vigilant, not just of your software and running systems, but also of the security of how you develop that software. When compiler vendors provide updates to mitigate these issues, it will still depend on software teams to update their compiler version to take advantage of the fixes.”
Tim Erlin, VP of Strategy, Tripwire:
“There’s an obvious challenge in patching this vulnerability across the variety of components affected. The bigger issue, however, is finding instances of it being exploited in the wild.
It’s tempting to think that the initial public disclosure is the moment when everyone finds out about the vulnerability, but history suggests that attackers, who have a vested interest in keeping it to themselves, are likely to have known about these types of conditions before public disclosure. In this case, there’s evidence that this disclosure isn’t actually the first for this type of attack.”
Jake Williams, Co-Founder and CTO, BreachQuest:
“The issues described here are definitely serious, but we should examine these in context. To exploit this, a threat actor would need to be able to change source code that is subsequently compiled into binary form by a victim. This itself is already serious. 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. The major contribution of this research is showing how widespread the issue actually is.”
Yaniv Bar-Dayan, CEO, Co-Founder, Vulcan Cyber:
“The new Trojan Source code compiler vulnerability will no doubt cause problems for engineering and DevOps teams with poor cyber hygiene. This is especially scary for security and DevSecOps organizations that are in the habit of reacting to exploits if there is a chance the exploit may go undetected for some time. However, not all is lost especially for teams who proactively understand risk posture and who 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.”
Pedro Fortuna, CTO, Jscrambler:
“Unfortunately, this is just one of hundreds of ways through which attackers can launch low-effort, high-gain supply chain attacks. It’s also a great example of why we can’t rely on using a single line of defense. Companies wanting to get serious about preventing software supply chain attacks need to adopt a defense-in-depth mindset and put in place several security layers. When we’re talking about software and web applications, this means going beyond code review and vulnerability scanning, implementing security controls at runtime that provide real-time visibility and control of every app component.”
Jon Gaines, Senior Application Security Consultant, nVisium:
“This ‘Trojan Source’ bug certainly presents an interesting attack surface. As it sits, the research by the University of Cambridge is novel, but their proof-of-concepts are not actually malicious. However, in the hands of a sophisticated attacker or group who can actually weaponize it, we would definitely have a dangerous situation on our hands.
This scenario demonstrates the proactive power of source code reviews and it would be a good best practice not to copy and paste code for the time being. It’s always better to rewrite it yourself and you can also enable your IDE or text editors to display Unicode. Alternatively, if you do go this route, open up the code you copied and pasted within a hex editor to check it. Hopefully patches will be promptly released for most compilers, but in the interim, this would be an effective short-term solution.”