Could we help developers detect and prevent issues of trojan source in their projects?

[lirantal]

Hi folks,

I wanted to begin by saying thanks for sharing your research insights and raising awareness of potential threats to open source supply chain security.

Given the fact that many folks might be drawn here to the repository (or the website) and would be seeking a way to mitigate these issues, I was wondering if you'd want to update the README here and include a list of tools that help find and fix these issues?

During the weekend, I built a package to detect bidi chars in text anti-trojan-source which is just handy for Node.js / npm folks to run instead of say a regex with grep, but more importantly, the eslint-plugin-anti-trojan-source package which proactivly help developers prevent the cases of malicious commits when they happen.

[jhollowe]

If you are using VSCode (desktop app, online, GitHub codespaces, etc.), I have used the Highlight Bad Chars extension to detect weird dashes and spaces in the past and it does show the BiDi characters. This will at least let you know if there are bad characters there.

I've also noted that GitHub is now displaying a warning when viewing BiDi trojan source attacks in the web UI.

[jhollowe]

A GitHub action would also be useful for developers to quickly add to their workflows.

[lirantal]

While the VS Code extensions are nice, and even some improvements to the default VS Code settings and on GitHub, it's just not enough and you can't force everyone to download these extensions. Instead, adding the ESLint plugin to surface such issues in the CI and break it before changes are merged is more actionable and secure than trusting that all developers adhere to specific extensions and setups.

[lirantal]

@jhollowe agree about the GitHub Action idea. That would be a super nice thing. Would you like to submit a pull request on the anti-trojan-source repo that creates one? I'll be happy to merge it in and submit to the marketplace.

[grahamgower]

Isn't there a "trusting trust" issue with such codes that attempt to identify bidi attacks?

[maltfield]

fyi, I hacked-up a simple GitHub Actions workflow that looks for Unicode characters in the changes made for a given PR

• https://github.com/maltfield/trojan-source/blob/mallory/.github/workflows/unicode_warn.yml

If any unicode characters were added in the commits comprising the PR, it adds a comment to the PR with the text

WARNING: Unicode characters found in diff!

Example PR:

• unicode detection in PR (test) maltfield/trojan-source#2

If no unicode characters were found in the diff, it adds the comment

INFO: No unicode characters found in PR's commits

EDIT: I published a small write-up about how to use this here:

• https://tech.michaelaltfield.net/2021/11/22/bidi-unicode-github-defense/

[shaneray]

I agree that extensions are not the best way to mitigate this, but it’s a good start until the IDE implements checks for this natively. I created the ShaneRay.InvisibleCharacterVisualizer Visual Studio extension awhile back that seems to catch a lot of these. Going to try and update it in the coming weeks to catch the homoglyph-function.csx cases and add support for VS 2022.

[davidmalcolm]

In terms of detection, the to-be-released GCC 12 has a new -Wbidi-chars warning for this (I helped implement it).

I wrote a blog post about the detection features here:
https://developers.redhat.com/articles/2022/01/12/prevent-trojan-source-attacks-gcc-12
which shows what GCC 12 emits for the various test cases in this repository, along with some others notes relating to the issue that others may find helpful.

Hope this is constructive [and not just shameless self-promotion :) ]