Secure coding and formatted input

This is a discussion on Secure coding and formatted input within the C++ Programming forums, part of the General Programming Boards category; Memloop posted a link to an article on secure coding in C that recommended that one "use strtol() or a ...

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

    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    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,660
    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,660
    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,660
    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,189
    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
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  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
    21,597
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21