3 ms·

It's not fair to the researchers to discount their contribution because prior knowledge of their findings exists. Publishing and evangelizing is important too.

by jart 5y ago

It's not fair to the researchers to discount their contribution because prior knowledge of their findings exists. Publishing and evangelizing is important too. There's a lot of security weaknesses that simply can't be addressed without changing the social reality, which is what the people who built that slick website did. 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.

jerf 5y ago
I think the previous knowledge is incidental. Which the essay reflects in pointing it out in a single quick section. What's really relevant is all the other stuff. 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".
- deleted 5y ago
  [deleted]
- gnufx 5y ago
  > carefully-thought out Unicode policies Like https://www.unicode.org/reports/tr39/tr39-24.html 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
  - jerf 5y ago
    Yes. 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.

by jart 5y ago

jerf 5y ago

I think the previous knowledge is incidental. Which the essay reflects in pointing it out in a single quick section. What's really relevant is all the other stuff. 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".

deleted 5y ago
[deleted]
gnufx 5y ago
> carefully-thought out Unicode policies Like https://www.unicode.org/reports/tr39/tr39-24.html 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
- jerf 5y ago
  Yes. 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.