Glassworm is back: A new wave of invisible Unicode attacks hits repositories
1–10 of 201 posts
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#2Why didn't some make av rule to find stuff like this, they are just plain text files
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#3Small discussion yesterday (9+9 points, 9+4 comments) https://news.ycombinator.com/item?id=47374479 https://news.ycombinator.com/item?id=47385244
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#4Why didn't some make av rule to find stuff like this, they are just plain text files
Yeah it would have been nice to end with "and here's a five-line shell script to check if your project is likely affected". But to their credit, they do have an open-source tool [1], I'm just not willing to install a big blob of JavaScript to look for vulns in my other big blobs of JavaScript
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#5[dead]
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#6Why didn't some make av rule to find stuff like this, they are just plain text files
The rule must be very simple: any occurrence of `eval()` should be a BIG RED FLAG. It should be handled like a live bomb, which it is.
Then, any appearance of unprintable characters should also be flagged. There are rather few legitimate uses of some zero-width characters, like ZWJ in emoji composition. Ideally all such characters should be inserted as \xNNNN escape sequences, and not literal characters.
Simple lint rules would suffice for that, with zero AI involvement.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#7The `eval` alone should be enough of a red flag
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#8IMO while the bar is high to say "it's the responsibility of the repository operator itself to guard against a certain class of attack" - I think this qualifies. The same way GitHub provides Secret Scanning [0], it should alert upon spans of zero-width characters that are not used in a linguistically standard way (don't need an LLM for this, just n-tuples).
Sure, third-party services like the OP can provide bots that can scan. But if you create an ecosystem in which PRs can be submitted by threat actors, part of your commitment to the community should be to provide visibility into attacks that cannot be seen by the naked eye, and make that protection the norm rather than the exception.
[0] https://docs.github.com/en/get-started/learning-about-github...
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#9The `eval` alone should be enough of a red flag
No it’s not.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#10Why didn't some make av rule to find stuff like this, they are just plain text files
The rule must be very simple: any occurrence of `eval()` should be a BIG RED FLAG. It should be handled like a live bomb, which it is. Then, any appearance of unprintable characters should also be flagged. There are rather few legitimate uses of some zero-width characters, like ZWJ in emoji composition. Ideally all such characters should be inserted as \xNNNN escape sequences, and not literal characters. Simple lint…
In our repos, we have some basic stuff like ruff that runs, and that includes a hard error on any Unicode characters. We mostly did this after some un-fun times when byte order marks somehow ended up in a file and it made something fail.
I have considered allowing a short list that does not include emojis, joining characters, and so on - basically just currency symbols, accent marks, and everything else you'd find in CP-1521 but never got around to it.