On “Trojan Source” Attacks
research.swtch.com
research.swtch.com
// don't forget to skip formatting the hard drive format_hard_drive = false;
So, yes, the code in question deleted the user's hard drive. And by looking at the code in Visual Studio, the editor, you'd swear the code was correct.
(The real logic was not that blatantly dangerous, but it amounted to the same thing.)
Emacs autoconverts between the two line ending styles at open and close, unless you expressly tell it to do otherwise [1]. You had malicious editors using emacs. The editor wasn't the problem, the people using it were and they had to go out of their way to manage it.
1. https://www.emacswiki.org/emacs/EndOfLineTips#:~:text=(The%2....
PS - We all benefit when we give each other the benefit of the doubt, and hold off on the snark. And calling my co-workers "malicious" based on your limited understanding of the situation is not appreciated.
For example, no one cared about supply chain hacks (e.g. depending on thousands of Node packages written by strangers on the Internet) until america's nukes started getting hacked because of it. No one cared about the BGP hack until someone told everyone at DEFCON how the trust inherent to how Internet engineering operates could be exploited. It goes on.
At the moment it's academically interesting, not a "critical" vulnerability as so many people are rating it. Exploiting it is riskier than it is being presented as and less likely to work than presented. If I were trying to slip something into a code base today, this would not be the top of my list. Personally I'd be sticking to the already-existing plausibly deniable issues of things like off-by-one or subtle misspellings of string constants or variable shadowing or any number of other things.
Sure, by all means, take some steps to address this, but you can handle this as a medium or even a low priority vulnerability. It's not a panic to upgrade and panic to release half-assed, poorly-thought-out fixes. I'd rather see some carefully-thought out Unicode policies in a couple months than a hack fix now and people thinking the problem is solved. For instance, it's not hard to write code that looks at the category of characters and points out characters that don't match the category of the rest of the characters around them, highlighting homophone attacks. There's time to think this through. The priority is not "critical".
Like https://www.unicode.org/reports/tr39/tr39-24.html ?
The phrase ‘It's not difficult’ is probably rarely applicable in the context of multilingual text — notice the possible homographs!
My simple-minded approach was to take the Unicode TR's list of "confusables" and make an Emacs display table indicating all the possible non-ASCII characters that could occur in a homograph sequence, assuming mainly ASCII text. But that is simple-minded, and you don't always want it on.
»¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣ ɓuı̣ɥʇʎuɐ sı̣ pooɓ ʇɐɥM« — anon
I don't mean that a full solution is not that hard. That's AI-hard in the limit. But it's not hard to detect most of the bad things. Most of the homographs are not right next to each other in Unicode.