Detecting Malicious Unicode

29 TangerineDream 7 5/16/2025, 7:15:55 AM daniel.haxx.se ↗

Comments (7)

rurban · 6h ago
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.
crtasm · 1h ago
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.

graemep · 13h ago
Surely the fact that the change is in a domain name (and the diff shows this) is a red flag?
bombcar · 12h ago
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.
fsflover · 13h ago
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-...
poincaredisk · 11h ago
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.

fsflover · 9h ago
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.