Thread: Secure coding and formatted input

  1. #1
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413

    Secure coding and formatted input

    Memloop posted a link to an article on secure coding in C that recommended that one "use strtol() or a related function to convert a string token to an integer". Reading the C++ version of that article, I see that formatted input with operator>> is criticised as it "has undefined behavior if the value of the result of this operation cannot be represented as an integer". Is this true?

    Empirical evidence with the MinGW port of g++ 3.4.5 and MSVC9 show that formatted input with operator>> is able to detect overflow when reading to an integer variable, but such evidence is insufficient when contemplating undefined behaviour.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    Quote Originally Posted by ISO/IEC 14882:2003(E)
    22.2.2.1.2 num_get virtual functions
    ...
    11
    Stage 3: The result of stage 2 processing can be one of
    — A sequence of chars has been accumulated in stage 2 that is converted (according to the rules of scanf) to a value of the type of val. This value is stored in val and ios_base::goodbit is stored in err.
    — The sequence of chars accumulated in stage 2 would have caused scanf to report an input failure. ios_base::failbit is assigned to err.
    Seems to me the article is wrong.

    gg

  3. #3
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    Well, it seems to be based on this: https://www.securecoding.cert.org/co...ossible+inputs

    Quote Originally Posted by ISO/IEC 9899:1999 (E)
    7.19.6.2 The fscanf function
    ...
    10
    Except in the case of a % specifier, the input item (or, in the case of a %n directive, the count of input characters) is converted to a type appropriate to the conversion specifier. If the input item is not a matching sequence, the execution of the directive fails: this condition is a matching failure. Unless assignment suppression was indicated by a *, the result of the conversion is placed in the object pointed to by the first argument following the format argument that has not already received a conversion result. If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
    gg

  4. #4
    Registered User
    Join Date
    Mar 2009
    Posts
    399
    Still, I don't see anything about how the >> operator handles overflows.

  5. #5
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    It handles it "according to the rules of scanf".

    The rules for scanf (in C99 at least) say: "... if the result of the conversion cannot be represented in the object, the behavior is undefined."

    gg

  6. #6
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    It seems to me they are claiming to have invented a wheel named 'always perform error handling', which is nothing new. I think in any case where this code would break, the rest of the program would have to be exceptionally sloppy to begin with, but thats just my 2¢

  7. #7
    Registered User
    Join Date
    Mar 2009
    Posts
    399
    That's what I thought. I guess that means you can't use C++ streams when dealing with numeric input ...

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by abachler
    I think in any case where this code would break, the rest of the program would have to be exceptionally sloppy to begin with, but thats just my 2¢
    That is what they admit as well: "While it is rare for a violation of this recommendation to result in a security vulnerability, it can easily result in lost or misinterpreted data." However, it seems to me that the "lost or misinterpreted data" is likely to be the result of either a user input mistake or malicious input, upon which just documenting the program behaviour in such cases would mean that it no longer constitutes "lost or misinterpreted data".

    Quote Originally Posted by Memloop
    I guess that means you can't use C++ streams when dealing with numeric input ...
    No, it just means that you cannot use formatted input with C++ streams for handling numeric input if you do not want to risk undefined behaviour. It seems to me that the undefined behaviour does not make sense: both implementations that I tested have behaviour that makes sense, and perhaps it is a bug in the Standard(s) to fail to standardise in favour of that.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed