Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

aikido.dev

Post reply on HN
Print view View original

31–40 of 201 posts

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

#31

Post by chrismorgan »

vitus wrote: post #19

Looks like the repo owner force-pushed a bad commit to replace an existing one. But then, why not forge it to maintain the existing timestamp + author, e.g. via `git commit --amend -C df8c18`? Innocuous PR (but do note the line about "pedronauck pushed a commit that referenced this pull request last week"): https://github.com/pedronauck/reworm/pull/28 Original commit: https://github.com/pedronauck/reworm/commit/df8c1…

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 still has to be injected after the fact. Even the most superficial code review should catch it.

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

#32

Post by hamburglar »

nine_k wrote: post #6
DropDead wrote: 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…

I think there’s debate (which I don’t want to participate in) over whether or not invisible characters have their uses in Unicode. But I hope we can all agree that invisible characters have no business in code, and banishing them is reasonable.

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

#34

Post by jeltz »

WalterBright wrote: post #27
WalterBright wrote: post #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.

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.

I don't think that would help much. There are also characters which are similar but not the same and I don't think humans can spot the differences unless they are actively looking for them which most of the time people are not. If only one of two glyphs which are similar appear in the text nobody would likely notice, expectation bias will fuck you over.

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

#35

Post by pvillano »

WalterBright wrote: post #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.

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 ZERO WIDTH NON-JOINER to encode that two characters should not be connected by a ligature.

Unicode needs U+200B ZERO WIDTH SPACE to indicate a word break opportunity without actually inserting a visible space.

Unicode needs MONGOLIAN FREE VARIATION SELECTORs to encode the traditional Mongolian alphabet.

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

#36

Post by nswango »

WalterBright wrote: post #27
WalterBright wrote: post #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.

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.

So you think that the letters in the Greek and Cyrillic alphabets which are printed identically to the Latin A should not exist?

And, for example, Greek words containing this letter should be encoded with a mix of Latin and Greek characters?

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

#38

Post by uhoh-itsmaciek »

WalterBright wrote: post #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.

>Remove them from Unicode.

Do you honestly think this is a workable solution?

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

#39

Post by vitus »

chrismorgan wrote: post #31
vitus wrote: post #19

Looks like the repo owner force-pushed a bad commit to replace an existing one. But then, why not forge it to maintain the existing timestamp + author, e.g. via `git commit --amend -C df8c18`? Innocuous PR (but do note the line about "pedronauck pushed a commit that referenced this pull request last week"): https://github.com/pedronauck/reworm/pull/28 Original commit: https://github.com/pedronauck/reworm/commit/df8c1…

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

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

#40

Post by luke-stanley »

WalterBright wrote: post #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.

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
Post reply on HN