I wonder if this could be used for prompt injection, if you copy and paste the seemingly empty string into an LLM does it understand? Maybe the affect Unicode characters aren’t tokenized.
Glassworm is back: A new wave of invisible Unicode attacks hits repositories
41–50 of 201 posts
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#42Earlier quoted context omitted.
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
#43Earlier quoted context omitted.
The value of the technique, I suppose, is that it hides a large payload a bit better. The part you can see stinks (a bunch of magic numbers and eval), but I suppose it’s still easier to overlook than a 9000-character line of hexadecimal (if still encoded or even decoded but still encrypted) or stuff mentioning Solana and Russian timezones (I just decoded and decrypted the payload out of curiosity). But really, it sti…
Agreed on all those fronts. I'm just dismayed by all the comments suggesting that maintainers just merged PRs with this trojan, when the attack vector implies a more mundane form of credential compromise (and not, as the article implies, AI being used to sneak malicious changes past code review at scale).
Yeah, the attack vector seems to be stolen credentials. I would be much more interested in an attack which actually uses Invisible characters as the main vector.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#44Earlier quoted context omitted.
It really is. There are very few proper use-cases for eval.
For a long time the standard way of loading JSON was using eval.
And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript? Can you think of any reasons beyond performance?
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#45Earlier quoted context omitted.
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.
Arguably them being in Unicode is an accessibility issue, unless we thought to standardize GIF names, and then that already sounds a lot like Unicode.
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#46I don't have to worry about any of this.
My clawbot & other AI agents already have this figured out.
/s
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#47Earlier quoted context omitted.
> 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.
Arguably them being in Unicode is an accessibility issue, unless we thought to standardize GIF names, and then that already sounds a lot like Unicode.
How is it an accessibility issue? HTML allows things like little gif files. I've done this myself when I wrote text that contained Egyptian hieroglyphs. It works just fine!
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#48Unicode 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.
[deleted]
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#49Unicode 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.
Unicode is "designed to support the use of text in all of the world's writing systems that can be digitized" Unicode needs tab, space, form feed, and carriage return. Unicode needs U+200E LEFT-TO-RIGHT MARK and U+200F RIGHT-TO-LEFT MARK to switch between left-to-right and right-to-left languages. Unicode needs U+115F HANGUL CHOSEONG FILLER and U+1160 HANGUL JUNGSEONG FILLER to typeset Korean. Unicode needs U+200C ZER…
[flagged]
Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories
#50Unicode 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.
So we need a new standard problem due to the complexity of the last standard? Isn't unicode supposed to be a superset of ASCII, which already has control characters like new space, CR, and new lines? xD
The only ones people use any more are newline and space. A tab key is fine in your editor, but it's been more or less abandoned as a character. I haven't used a form feed character since the 1970s.