Could we help developers detect and prevent issues of trojan source in their projects? about trojan-source HOT 8 OPEN

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:

• maltfield#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/

from trojan-source.

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.

from trojan-source.

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

from trojan-source.

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.

from trojan-source.

@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.

from trojan-source.

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

from trojan-source.

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.

from trojan-source.

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 :) ]

from trojan-source.