Live data from Hacker News

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

aikido.dev

161–170 of 201 posts

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

#161
post #100
post #82

Earlier quoted context omitted.

I'd be surprised if there is a performance benefit of processing json with eval(). Browsers optimize the heck out of JSON.

You are arguing against the opposite of what the comment you answered to said.

Am i? "Can you think of any reasons beyond performance?" implies that the comment author thinks performance would be a valid reason.

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

#162
post #86

Earlier quoted context omitted.

I'd say that this is also true from a money-and-costs-and-value perspective. Sure, all press is good press... but any number of stakeholders would agree that "we got some mindshare by proactively protecting against an emerging threat" is higher-ROI press than "Ars did a piece on how widespread this problem is, and we're mentioned in the context of our interface making the attack hard to detect." And when the incremen…

I agree and think it's extra important when you have specialized products. Experts are more sensitive to the little things. Engineers and developers are especially sensitive. It's our job to find problems and fix them. I don't trust engineers that aren't a bit grumpy because it usually means they don't know what the problems are (just like when they don't dogfood). Though I'll also clarify that what distinguishes a g…

>Though we're also talking about an organization that couldn't merge a PR for a year that fixed a one liner. A mistake that should never have gotten through review. Seriously, who uses a while loop counter checking for equality?!? I'm still convinced they left the "bug" because it made them money

What is this in reference to? I tried to search for it but only found this comment. “Github while loop fix that was in review for a year”?

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

#163
post #95
post #17

It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call. The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.

In this instance the PR that was merged was from 6 years ago and was clear https://github.com/pedronauck/reworm/pull/28 . Looks to me like a force push overwrote the commit that now exists in history since it was done 6y later.

So who force pushed and why?

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

#164

Earlier quoted context omitted.

Infer the meaning from the context. a) it's a bullet point b) a+b means a is a variable c) apple means a means the sound "aaaah" d) ape means a means the sound "aye" e) 0xa means a means "10" f) "a" on my test paper means I did well on it g) grade "a" means I bought the good bolts h) "achtung" means it's a German "a" I didn't need 8 different Unicode characters. And so on.

Your trolling is really rock bottom. All this already works fine. Millions of times, each day. Just once a week it fails because someone messed up. Not an issue.

I showed that there is no need for semantic information about the glyphs. It's more compelling to demonstrate a need for semantic information rather than just asserting it.

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

#165
post #157

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm". The malicious code was introduced in this commit - https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6... It says coauthored by dependabot and refers to a PR opened in 2020 ( https://github.com/pedronauck/reworm/pull/28 ). That PR itself was merged in 2020 here - https://github.com/pedronauck/r…

Someone has maintainer/admin access to the repository and has force-pushed to master overwriting the git history.

Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599...

While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...

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

#166
post #157

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm". The malicious code was introduced in this commit - https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6... It says coauthored by dependabot and refers to a PR opened in 2020 ( https://github.com/pedronauck/reworm/pull/28 ). That PR itself was merged in 2020 here - https://github.com/pedronauck/r…

The malicious code was added to package.json, not yarn.lock

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

#167
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…

Vigilant mode exists, and would have flagged the malicious commit as unverified in this case. Maybe it should be the default.

https://docs.github.com/en/authentication/managing-commit-si...

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

#169

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.

Yes, and that happens.
Post reply on HN