Detecting Malicious Unicode

daniel.haxx.se

40 points·TangerineDream··7 comments

I also rerported that to github some years ago and pointed them to use a library of mine to catch such confusables, libu8ident. No reaction whatsoever. Compilers and binutils didn't care neither. They don't care about strings, but even not about names.

Some good news at the end of the post:

>Update. GitHub has told me they have raised this as a security issue internally and they are working on a fix.

Qubes OS protects from such attacks by running all software in isolated VMs and not passing the unicode symbols to the host by default, https://www.qubes-os.org/news/2024/07/13/qubes-os-4-2-2-has-...

You link says the opposite - the change was very annoying for people that use non-english languages (like me), and:

>By default, qvm-copy and similar tools will use this less restrictive service (qubes.Filecopy +allow-all-names) whenever they detect any files that would be have been blocked by the more restrictive service

Also it looks like this is just for filenames? I can't imagine filtering text like this, that would render the system useless for me.

The defense of the host (dom0) from the websites comes from not showing the UTF-8 window titles (https://www.qubes-os.org/doc/config-files/#gui-and-audio-con...). Since all you see inside VMs is isolated, you can show any text inside them safely for dom0.

It gets a bit harder with transferring files between VMs as my original link shows, but you can be protected from that too at some cost.

Surely the fact that the change is in a domain name (and the diff shows this) is a red flag?

That was an example- an attacker would slip it in an actual URL change to make it less noticeable- and a good attacker would have their domain work and redirect until the code was deployed in the wild.

Reply on news.ycombinator.com