Live data from Hacker News

Glassworm is back: A new wave of invisible Unicode attacks hits repositories

aikido.dev

21–30 of 201 posts

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#21
Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards.

Things that vanish on a printout should not be in Unicode.

Remove them from Unicode.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#22

Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.

Invisible characters are there for visible characters to be printed correctly...

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#23

Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.

greatidea,whoneedsspacesanyway

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#24
post #6
post #2

Why 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…

> There are rather few legitimate uses of some zero-width characters, like ZWJ in emoji composition.

Emojis are another abomination that should be removed from Unicode. If you want pictures, use a gif.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#25

Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.

greatidea,whoneedsspacesanyway

Spaces appear on a printout.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#26
Attacks employing invisible characters are not a new thing. Prior efforts here include terminal escape sequences, possibly hidden with CSS that if blindly copied and pasted would execute who knows what if the particular terminal allowed escape sequences to do too much (a common feature of featuritis) or the terminal had errors in its invisible character parsing code.

For data or code hiding the Acme::Bleach Perl module is an old example though by no means the oldest example of such. This is largely irrelevant given how relevant not learning from history is for most.

Invisible characters may also cause hard to debug issues, such as lpr(1) not working for a user, who turned out to have a control character hiding in their .cshrc. Such things as hex viewers and OCD levels of attention to detail are suggested.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#27

Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.

Another dum dum Unicode idea is having multiple code points with identical glyphs.

Rule of thumb: two Unicode sequences that look identical when printed should consist of the same code points.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#28
post #8

IMO 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…

Regardless of the thorny question of whether it's Github's responsibility , it sure would be a good thing for them to do ASAP.

It absolutely is. They are simply spreading malware. You can't claim to be a 'dumb pipe' when your whole reason for existence is to make something people deemed 'too complex' simple enough for others to use, then you have an immediate responsibility to not only reduce complexity but to also ensure safety. Dumbing stuff down comes with a duty of care.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#29
post #7

The `eval` alone should be enough of a red flag

No it’s not.

While there are valid use cases for eval they are so rare that it should be disabled by default and strongly discouraged as a pattern. Only in very rare cases is eval the right choice and even then it will be fraught with risk.
Post reply on HN