9 ms·

There is absolutely a mess of little oversights like this in every non-trivial software project (I just fixed one not 30 minutes ago). The effects are sometimes

There is absolutely a mess of little oversights like this in every non-trivial software project (I just fixed one not 30 minutes ago). The effects are sometimes very serious, as in this case. Cyber-warfare is scary precisely because of this. There is nothing we can do about it IMO, though things like SELinux/AppArmor and even good filesystem-level permissions help a little bit.

andrewchambers 11y ago
In this particular case, the advice to avoid it is more simple. When designing test cases choose the extreme values, no text, too much text, etc.
deleted 11y ago
[deleted]
Taek 11y ago
There is something you can do about it, but it's expensive and different from what you are used to. Safer languages is a good place to start. Input validation can be made to be machine-verified, and anit-patterns can be learned and avoided. Static analysis tools can raise red and yellow flags. Finally, frameworks are being built for handling security critical things like account validation, crypto key handling, an related tasks that are important to get right. As the space continues to evolve, things like this will become less common, and someone who is aware of the trade and is diligent will be less likely to make mistakes.
- LoSboccacc 11y ago
  > anit-patterns can be learned a spell checker didn't save you from a typo. not nitpicking, just using this example to illustrate a point: for an app to be secure, developers have to be 100% of the time on ball, while an attacker just has to be lucky once. the weight is so much in favor of attacker than only few of the biggest can afford to pay for a competitive level of security, it being a race: security is effective not when perfect, but when it costs more to attack a site than what you'd gain of it.
  - mdpopescu 11y ago
    Or even when the gain/cost ratio for attacking YOUR site is greater than the one for other sites. (You don't have to outrun the bear, you have to outrun the other people.)
  - ethbro 11y ago
    > a spell checker didn't save you from a typo Believe this is where parent's preference for high-quality, easy-to-use libraries handling common security operations comes from. It's a lot easier to make a typo (or logical mistake) in 250 lines of your own code than in (hopefully) <250 lines of a library invocation. Honestly, library functionality like this in any given language should be thought of as an analog to infrastructure spending. We're finally seeing reinvestment from end-users and value capturers (Facebook, Google, MS, etc) back down the chain to the OSS projects they depend on. Language guiders (and in some cases the support businesses who are attached to languages) should be equally serious about this. If your language doesn't have high-quality, easy-to-use libraries to mitigate attack surfaces, that's a fundamental weakness in your language eco-system... (Aka the "Perl+CPAN is better than a lot of more advanced languages, because code" argument)
- georgerobinson 11y ago
  > Safer languages is a good place to start. Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. > Input validation can be made to be machine-verified Likewise, can you elaborate on this? How does the machine know what type of input this is? If input is tagged by the developer, what's to stop the developer from forgetting to tag the input correctly?
  - icebraining 11y ago
    Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. In some languages, you can define a string type that only contains strings of one or more characters. And then you'd need to "convert" a regular string into one of those by using some function that forced you to handle the strlen(str) == 0 case. I believe you can define that in Idris, for example.
  - shkkmo 11y ago
    except for strlen(str) != 0 doesn't really do much to fix the issue. At best all it does is mean you have to guess the first character. If you are comparing byte by byte the correct code is: valid = true; for(i = 0; i < strlen(user_token); i++) { if(strlen(token) < i || user_token[i] != token[i]) valid = false; } if(strlen(token) != strlen(user_token)) valid = false; return valid;
    - delinka 11y ago
      Let's make it somewhat more readable: int token_length = strlen(token); int input_length = strlen(input); int match_count = 0; // for constant-time comparison... // Just get this out of the way now; no need to dawdle // (because the length of a token is generally known) if (token_length != input_length) { return false; } // No need to worry about mismatched buffer lengths at this point for(int i=0; i<token_length; i++) { if (token[i] == input[i]) { match_count++; } } // if the same number of characters match, voila! return (match_count == token_length); It takes far too long to understand the intent and verify the correctness of lines like: if(strlen(token) < i || user_token[i] != token[i]) valid = false;
weavie 11y ago
This is precisely the sort of error that Fuzz testing should have uncovered.
- baby 11y ago
  When you have such a huge application (steam) how can you afford to Fuzz everything? Also to setup fuzzing for every parts of your applications
InclinedPlane 11y ago
There's plenty that can be done about it, but it imposes a cost that most software shops don't want to pay today, despite the enormous costs of these breaches. Formal code reviews. Longer pipelines between checkin and deployment. Penetration testing during pre-release. Better QA, both manual and automated. Better security policies in general. And so on. Making a change to security related code should trigger a process that represents and avalanche of attention. There should be a shit-ton of scrutiny on any such change. The fact that something this simple wasn't caught is indicative not that "nothing can be done" but rather that most security related code today is handled in an amateurish way by teams who barely care about the consequences of their actions.

andrewchambers 11y ago

In this particular case, the advice to avoid it is more simple. When designing test cases choose the extreme values, no text, too much text, etc.

deleted 11y ago

[deleted]

Taek 11y ago

There is something you can do about it, but it's expensive and different from what you are used to. Safer languages is a good place to start. Input validation can be made to be machine-verified, and anit-patterns can be learned and avoided. Static analysis tools can raise red and yellow flags. Finally, frameworks are being built for handling security critical things like account validation, crypto key handling, an related tasks that are important to get right. As the space continues to evolve, things like this will become less common, and someone who is aware of the trade and is diligent will be less likely to make mistakes.

LoSboccacc 11y ago
> anit-patterns can be learned a spell checker didn't save you from a typo. not nitpicking, just using this example to illustrate a point: for an app to be secure, developers have to be 100% of the time on ball, while an attacker just has to be lucky once. the weight is so much in favor of attacker than only few of the biggest can afford to pay for a competitive level of security, it being a race: security is effective not when perfect, but when it costs more to attack a site than what you'd gain of it.
- mdpopescu 11y ago
  Or even when the gain/cost ratio for attacking YOUR site is greater than the one for other sites. (You don't have to outrun the bear, you have to outrun the other people.)
- ethbro 11y ago
  > a spell checker didn't save you from a typo Believe this is where parent's preference for high-quality, easy-to-use libraries handling common security operations comes from. It's a lot easier to make a typo (or logical mistake) in 250 lines of your own code than in (hopefully) <250 lines of a library invocation. Honestly, library functionality like this in any given language should be thought of as an analog to infrastructure spending. We're finally seeing reinvestment from end-users and value capturers (Facebook, Google, MS, etc) back down the chain to the OSS projects they depend on. Language guiders (and in some cases the support businesses who are attached to languages) should be equally serious about this. If your language doesn't have high-quality, easy-to-use libraries to mitigate attack surfaces, that's a fundamental weakness in your language eco-system... (Aka the "Perl+CPAN is better than a lot of more advanced languages, because code" argument)
georgerobinson 11y ago
> Safer languages is a good place to start. Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. > Input validation can be made to be machine-verified Likewise, can you elaborate on this? How does the machine know what type of input this is? If input is tagged by the developer, what's to stop the developer from forgetting to tag the input correctly?
- icebraining 11y ago
  Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. In some languages, you can define a string type that only contains strings of one or more characters. And then you'd need to "convert" a regular string into one of those by using some function that forced you to handle the strlen(str) == 0 case. I believe you can define that in Idris, for example.
- shkkmo 11y ago
  except for strlen(str) != 0 doesn't really do much to fix the issue. At best all it does is mean you have to guess the first character. If you are comparing byte by byte the correct code is: valid = true; for(i = 0; i < strlen(user_token); i++) { if(strlen(token) < i || user_token[i] != token[i]) valid = false; } if(strlen(token) != strlen(user_token)) valid = false; return valid;
  - delinka 11y ago
    Let's make it somewhat more readable: int token_length = strlen(token); int input_length = strlen(input); int match_count = 0; // for constant-time comparison... // Just get this out of the way now; no need to dawdle // (because the length of a token is generally known) if (token_length != input_length) { return false; } // No need to worry about mismatched buffer lengths at this point for(int i=0; i<token_length; i++) { if (token[i] == input[i]) { match_count++; } } // if the same number of characters match, voila! return (match_count == token_length); It takes far too long to understand the intent and verify the correctness of lines like: if(strlen(token) < i || user_token[i] != token[i]) valid = false;

weavie 11y ago

This is precisely the sort of error that Fuzz testing should have uncovered.

baby 11y ago
When you have such a huge application (steam) how can you afford to Fuzz everything? Also to setup fuzzing for every parts of your applications

InclinedPlane 11y ago

There's plenty that can be done about it, but it imposes a cost that most software shops don't want to pay today, despite the enormous costs of these breaches. Formal code reviews. Longer pipelines between checkin and deployment. Penetration testing during pre-release. Better QA, both manual and automated. Better security policies in general. And so on. Making a change to security related code should trigger a process that represents and avalanche of attention. There should be a shit-ton of scrutiny on any such change. The fact that something this simple wasn't caught is indicative not that "nothing can be done" but rather that most security related code today is handled in an amateurish way by teams who barely care about the consequences of their actions.