A new critical issue was discovered in the character definitions of the Unicode Specification through 14.0.
Does it only affect code compiled from sources with disallowed unicode characters?
RHEL describes that it is relevant only to GCC.
Is it only C or CPP files?
What if a disallowed unicode character appears in HTML or CSS files?
"CVE" 2021-42694 does not affect code at all. It affects the systems human beings use to review code and proposed code changes - that is, fancy text editors/IDEs, GitHub pull request and code review workflows, etc. This is a consequence of blindly applying UTR #9 to the entire body of code/patch as a single context, rather than "resolving embedding levels" in an application-specific (in this context, programming-language-specific) manner so that embedding/override controls are not allowed to exert formatting influence across different contexts (comment blocks, quoted strings, etc.) or just not honoring embedding/override control characters at all.
The critical issue is certainly not in the character definitions of the Unicode Specification through 14.0. In fact the Unicode committee provides adequate methods to fix such attacks, at least the homoglpygh and spoofing attacks on identifiers. There is TR31, TR36 and esp. TR39 which provide the recommendations. This is published since 2000, and almost nobody is following those security recommendations.
The problem is that identifiers are not identifiable. This happens in code, but also in objects files, because those do have an ABI and API, e.g. headers, FFI, linker access, tools missing checks.
The main problem is with all the language committees and implementors who were fast to implement unicode support for identifiers without any security measures. The only safe languages are the ones which refused (zig and J), and the ones which did follow TR39: Java, cperl and Rust. All 100 others are vulnerable by design. And now even gcc-10 provides these insecurities. I compiled an overview over the various language and compiler insecurities at https://github.com/rurban/libu8ident/blob/master/c11.md
For a fixed version of the C23++ std. However, when I did this for perl5 in 2016, they didn't care, so only my fork cperl is secure. Rust did listen around that time and provided proper unicode security.
Anyway, now I have a C library which can be used to implement it, and a linter to check against. I'm also experimenting with an improved readelf -L -Ul checker to find existing unicode security issues in libraries. readelf was pretty broken displaying utf-8. This needs to be improved further to display unicode problems better. Such as on github recently. See my github for the readelf patches.
BTW: Another cynical fix would be to rename identifier to symbol in the language specs. Because symbols need not to be identifiable. They are just the same binary junk as filenames. Of course filesystems and login systems (databases, such as ldap and passwd) need to be fixed also.
