5 ms·

Their advisory is well-written and explains the problem well. The example code they use: if access_level != "user" { // Check if admin opens up a whole can

Their advisory is well-written and explains the problem well. The example code they use: if access_level != "user" { // Check if admin opens up a whole can of worms though. You don't need cunning invisible control codes to break that line, you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit. Even better, this would be a completely deniable attack ("oops, I must have accidentally pressed alt-R while typing that letter" excuse) - whereas explaining away why you checked in some magical RTL/LTR encodings and hacked up a comment is impossible. Plus, it would render well in far more apps, terminals, command line programs, etc etc

_3u10 5y ago
This stuff has always been there consider this code: if (uid = NULL) { // Check if root And if you’re using clang: if ((uid = NULL)) { // Check if root I'd venture that this is far more dangerous than unicode in strings... or how about: strcpy() or #include anything with a #DEFINE
- deleted 5y ago
  [deleted]
- fstrthnscnd 5y ago
  > if (uid = NULL) { // Check if root That's not the same class of error, since here a programmer can see the issue by simple inspection. > or #include anything with a #DEFINE This one perhaps is closer to the mark, although not based on unicode.
  - _3u10 5y ago
    To me it's the same class of error which is convincing humans and other automated tests that your code is OK when it isn't. I dealt with a bug that only appeared in release builds, and never in debug. The offending code looked roughly like this: if (blah) #ifdef DEBUG baz(); #endif bar(); The systemic problem was it was a project created by interns, and they'd review each others code. By the time the bug got to me the interns had left and a Sr Dev had spent a day looking for the bug. It took me an hour to find it. In isolation its easy to see but in the mess of all the other code, you really have to look for these things.
    - fstrthnscnd 5y ago
      Well, if you generalize the statement enough, indeed it's the same class of issue. In the situation you described: * you have a fairly easy way to detect the problem * the interns still have plausible deniability as to whether they intended to leave a defect or not The discussed problem with unicode is clearly meant to be used as an exploit, its likelihood of occurring by accident seems very close to zero.
- capitainenemo 5y ago
  Rust doesn't allow assignment in conditionals. https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/content/porting_from_cpp/assignments_in_conditionals.html https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/con...
  - _3u10 5y ago
    It does, in fact the article you posted, shows you exactly when rust allows assignment in conditionals. As long as you're initializing a variable, it's allowed, if you're not initializing you'll have to use a block expression.
    - capitainenemo 5y ago
      Should have just used this sentence - which also directly covers parent's case. "Rust does not allow assignment within simple expressions so they will fail to compile. This is done to prevent subtle errors with = being used instead of ==." Better?
- josephcsible 5y ago
  Those are all detectable by a programmer's eyes. Unicode attacks are not.
ace112 5y ago
Ooh, or you could just put in the cyrillic 'а' and even have it look like it's legit :)
codesections 5y ago
> you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit. The post mentions that exploit (and Rust's already existing defense) in the appendix. Here are the details, as explained in a previous post: > The compiler will warn about potentially confusing situations involving different scripts. For example, using identifiers that look very similar will result in a warning. warning: identifier pair considered confusable between `ｓ` and `s` https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html
- joosters 5y ago
  The compiler will warn about potentially confusing situations involving different scripts. For example, using identifiers that look very similar will result in a warning. Unfortunately, I've little experience of rust, so I don't have experience of that warning. It would certainly help catch a one-liner exploit, but wouldn't it be excessively noisy for code written in non-english languages?
  - wongarsu 5y ago
    It only warns if there actually are two identifiers that look similar. Even if it's not malicious it's still confusing and is worth renaming. But if you want to, turning off specific warnings for a file or block of code is really simple in rust, just add "#[allow(confusable_idents)]"
  - estebank 5y ago
    The Unicode homoglyph lint will only trigger if there are multiple identifiers that can look the same, it's not a blanket warning on anything that isn't ASCII. It's close to what browsers do with domain names. And you can always allow lints.
- lol768 5y ago
  Am I missing something here? The spacing around these homoglyph is almost always noticeably wider than it should be such that I don't understand how you could ever miss it in any half-decent code review. if access_level != "user" { // Check if admin if access_level != "uｓer" { // Check if admin Come on, that looks obviously off.

_3u10 5y ago

This stuff has always been there consider this code: if (uid = NULL) { // Check if root And if you’re using clang: if ((uid = NULL)) { // Check if root I'd venture that this is far more dangerous than unicode in strings... or how about: strcpy() or #include anything with a #DEFINE

deleted 5y ago
[deleted]
fstrthnscnd 5y ago
> if (uid = NULL) { // Check if root That's not the same class of error, since here a programmer can see the issue by simple inspection. > or #include anything with a #DEFINE This one perhaps is closer to the mark, although not based on unicode.
- _3u10 5y ago
  To me it's the same class of error which is convincing humans and other automated tests that your code is OK when it isn't. I dealt with a bug that only appeared in release builds, and never in debug. The offending code looked roughly like this: if (blah) #ifdef DEBUG baz(); #endif bar(); The systemic problem was it was a project created by interns, and they'd review each others code. By the time the bug got to me the interns had left and a Sr Dev had spent a day looking for the bug. It took me an hour to find it. In isolation its easy to see but in the mess of all the other code, you really have to look for these things.
  - fstrthnscnd 5y ago
    Well, if you generalize the statement enough, indeed it's the same class of issue. In the situation you described: * you have a fairly easy way to detect the problem * the interns still have plausible deniability as to whether they intended to leave a defect or not The discussed problem with unicode is clearly meant to be used as an exploit, its likelihood of occurring by accident seems very close to zero.
capitainenemo 5y ago
Rust doesn't allow assignment in conditionals. https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/content/porting_from_cpp/assignments_in_conditionals.html https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/con...
- _3u10 5y ago
  It does, in fact the article you posted, shows you exactly when rust allows assignment in conditionals. As long as you're initializing a variable, it's allowed, if you're not initializing you'll have to use a block expression.
  - capitainenemo 5y ago
    Should have just used this sentence - which also directly covers parent's case. "Rust does not allow assignment within simple expressions so they will fail to compile. This is done to prevent subtle errors with = being used instead of ==." Better?
josephcsible 5y ago
Those are all detectable by a programmer's eyes. Unicode attacks are not.

ace112 5y ago

Ooh, or you could just put in the cyrillic 'а' and even have it look like it's legit :)

codesections 5y ago

> you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit. The post mentions that exploit (and Rust's already existing defense) in the appendix. Here are the details, as explained in a previous post: > The compiler will warn about potentially confusing situations involving different scripts. For example, using identifiers that look very similar will result in a warning. warning: identifier pair considered confusable between `ｓ` and `s` https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html https://blog.rust-lang.org/2021/06/17/Rust-1.53.0.html

joosters 5y ago
The compiler will warn about potentially confusing situations involving different scripts. For example, using identifiers that look very similar will result in a warning. Unfortunately, I've little experience of rust, so I don't have experience of that warning. It would certainly help catch a one-liner exploit, but wouldn't it be excessively noisy for code written in non-english languages?
- wongarsu 5y ago
  It only warns if there actually are two identifiers that look similar. Even if it's not malicious it's still confusing and is worth renaming. But if you want to, turning off specific warnings for a file or block of code is really simple in rust, just add "#[allow(confusable_idents)]"
- estebank 5y ago
  The Unicode homoglyph lint will only trigger if there are multiple identifiers that can look the same, it's not a blanket warning on anything that isn't ASCII. It's close to what browsers do with domain names. And you can always allow lints.
lol768 5y ago
Am I missing something here? The spacing around these homoglyph is almost always noticeably wider than it should be such that I don't understand how you could ever miss it in any half-decent code review. if access_level != "user" { // Check if admin if access_level != "uｓer" { // Check if admin Come on, that looks obviously off.