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

181–190 of 201 posts

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

#181

Post by amake »

zzo38computer wrote: post #68

I use non-Unicode mode in the terminal emulator (and text editors, etc), I use a non-Unicode locale, and will always use ASCII for most kind of source code files (mainly C) (in some cases, other character sets will be used such as PC character set, but usually it will be ASCII). Doing this will mitigate many of this when maintaining your own software. I am apparently not the only one; I have seen others suggest simil…

That’s great for you. Isn’t feasible for software development by teams that are native in a language with a non-Latin script.

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

#182

Post by vivekd »

godelski wrote: post #62
andrewflnr wrote: post #15

Earlier quoted context omitted.

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

Here's the big reason GitHub should do it: It makes the product better I know people love to talk money and costs and "value", but HN is a space for developers, not the business people. Our primary concern, as developers, is to make the product better . The business people need us to make the product better, keep the company growing, and beat out the competition. We need them to keep us from fixating on things that a…

Sure, but looking at this from a purely business perspective - I wonder how many customers would panic or jump ship rather than be grateful when notified of an attack. But I think it could work as an optional feature for paid accounts if it was marketed properly

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

#183

Post by Yokohiii »

WalterBright wrote: post #164
Yokohiii wrote: post #156

Earlier quoted context omitted.

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.

so you contradict yourself because your context window is exhausted?

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

#184

Post by estebank »

WalterBright wrote: post #144
slim wrote: post #131

Earlier quoted context omitted.

if you write كلب which is an arabic word written right to left in the middle of an english sentence, you want to preserve the order of the characters in the stream for computer processing purposes. meaning the chararacter ك must come before the ل and after the e and the space with respect to the memory layout. whereas when displayed, it must be inverted to be legible. the solution is to have an invisible character th…

Look I'm writing sdrawkcab (amazingly, I did it without using Unicode!). Layout is the job of your text formatting program. It's easy to fix a text editor to support right-to-left text entry. The switch in text direction has resulted in malicious code injection attacks, as the reversed text becomes invisible. I had to change my compiler to reject those Unicode characters for that reason. It can be used in other cases…

> Look I'm writing sdrawkcab

How would that work with Text-To-Speech output?

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

#185

Post by WalterBright »

Yokohiii wrote: post #183
WalterBright wrote: post #164

Earlier quoted context omitted.

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.

so you contradict yourself because your context window is exhausted?

Since you insist on being rude, I shall exit.

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

#186

Post by Arrowmaster »

bawolff wrote: post #81

I feel like the threat of this type of thing is really overstated. Sure the payload is invisible (although tbh im surprised it is. PUA characters usually show up as boxes with hexcodes for me), but the part where you put an "empty" string through eval isn't. If you are not reviewing your code enough to notice something as non sensical as eval() an empty string, would you really notice the non obfuscated payload eithe…

Honestly I was expecting more. There are many languages that support Unicode in variable or function names and I expected it to be used there.

It sounds like Python only allows approved Unicode characters to start a variable name but if it allowed any you could do something like `nonprintable = lambda x: insert exploit code here`. If that was hidden in what looked like a blank line between other additions would you catch it?

I'm sure there's some other language out there that has similar syntax and lax Unicode rules this could be used in.

The solution is that this and many other Unicode formatting characters should be ignored and converted to a visible indicator in all code views when you expect plain text.

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

#187

Post by zorpner »

WalterBright wrote: post #112
chongli wrote: post #109

Earlier quoted context omitted.

It's not text, it's control characters, which have always been in character sets going back to ASCII.

ASCII having a few obsolete control characters does not justify opening the floodgates.

Over 25% of the original ASCII specification is control characters.

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

#188

Post by WalterBright »

estebank wrote: post #184
WalterBright wrote: post #144

Earlier quoted context omitted.

Look I'm writing sdrawkcab (amazingly, I did it without using Unicode!). Layout is the job of your text formatting program. It's easy to fix a text editor to support right-to-left text entry. The switch in text direction has resulted in malicious code injection attacks, as the reversed text becomes invisible. I had to change my compiler to reject those Unicode characters for that reason. It can be used in other cases…

> Look I'm writing sdrawkcab How would that work with Text-To-Speech output?

Good question! Two possibilities:

1. Tell the TTS program that the text is RTOL.

2. If the TTS program can speak Arabic, it can detect RTOL Arabic text.

The only purpose for RTOL English I can think of is to insert hidden text for malicious purposes.

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

#189

Post by WalterBright »

zorpner wrote: post #187
WalterBright wrote: post #112

Earlier quoted context omitted.

ASCII having a few obsolete control characters does not justify opening the floodgates.

Over 25% of the original ASCII specification is control characters.

True. And nearly all of them are obsolete. Many were intended for control flow on an interactive terminal, which have long since passed into obsolescence. When was the last time you embedded a CTRL-C in text? The only ones that matter any more are newline and space.

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

#190

Post by nstart »

jibal wrote: post #166
nstart wrote: 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

Yup. That's correct. And I understand that. I was looking at the changes to yarn.lock that got reintroduced. I couldn't figure out what was happening. It turns out that not only was it force pushed, but GitHub also retains the old commit information even if it's been "deleted".

I still don't quite understand what GitHub is doing to allow someone to say that dependabot coauthored a spoofed commit. This isn't the commit message itself I'm talking about. It's the GitHub interface that officially recognizes this as a dependabot co authored commit. My hunch is that the malicious author squashed two commits, the original good commit to yarn.lock and a malicious change to package.json, and that somehow maintains the dependabot authorship instead of reassigning it fully to the squash-er.

Post reply on HN