An interesting (scary) trick of an nearly undetectable exploit. Wolfgang Ettlinger:
What if a backdoor literally cannot be seen and thus evades detection even from thorough code reviews?
I’ll post the screenshot of the exploit from the post with the actual exploit circled:
If you were really looking super closely you’d probably see that, but I can see how it would be easy to miss as it would avoid any linting problems and doesn’t mess up syntax highlighting at all. Then the way this code is written, the commands are executed:
Each element in the array, the hardcoded commands as well as the user-supplied parameter, is then passed to the
execfunction. This function executes OS commands.
They consider it worthy of change:
The Cambridge team proposes restricting Bidi Unicode characters. As we have shown, homoglyph attacks and invisible characters can pose a threat as well.
So is there a eslint setting for restricting Bidi Unicode characters or to implement it in development workflows?
The ESLint comma-spacing and comma-dangle rules will catch that exploit. I just confirmed in VS Code. Both the AirBnB and Google style guides require those rules. Just another reason linting is important.
I feel like lint rules should be a standard part of every project…
For those who still lint characters manually (as I do), the following regex happens to identify the exploit. Essentially, it finds non-whitespace characters outside of ASCII, as well as a couple of pernicious whitespace characters.
[\x0B\xA0]|[^\s\x20-\x7E]So funny that VS Code 1.63.0 addressed this exact same block of code
I was so excited I didn’t even see this post was linked in the release notes. whoops.
Simple to prevent
1) set no trailing commas in the lint rules. 2) reject any input that is not of the shape you are expecting
For lint rules to catch this exploit, you would need to require trailing commas, not disallow them. The way the exploit works is that it visually looks like it’s got trailing commas when it actually doesn’t.
My eslint trims my trailing whitespace on save. So the array line would be in obvious need of attention. In a code review I would send back the first trailing comma.
Easy code review fix (even if linters are protecting whitespace), in any editor simply show whitespace characters. With open source you can’t just accept a PR viewing code only in a browser.
You should only ever allow 2 whitespace chars: space & return. So it’s easy to visually check it.
This is a very English-centric suggestion. While programmers that use other languages usually use variables and functions names in ASCII, IDEs and code editors should never block non-ASCII characters. It could block homoglyphs and invisible characters, but banning non-English characters can cause a lot of problems in non-English languages