4 ms·

If they copied or used code that relied on using the safe memcpy_s, instead of having to change that code to use the unsafe versions, this could just be a proxy

by dalore 7y ago

If they copied or used code that relied on using the safe memcpy_s, instead of having to change that code to use the unsafe versions, this could just be a proxy layer that lets that code run. This might be done so it's easier to keep the other code up to date if it's getting updated else where.

mikeash 7y ago
Right, but why not take thirty seconds to do the appropriate checks in the wrappers?
- acqq 7y ago
  Because it's far from being thirty seconds (as seen in the post by ploxiln here): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm The most interesting quote regarding these "safer" interfaces from the report: "The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. ... Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed."
  - mikeash 7y ago
    I don’t understand. Your link is talking about the difficulty of using these functions. But here, the functions are already being used. What’s missing is implementations of them. They chose to implement these functions without the security checks, but implementing them with the security checks is not hard.
    - userbinator 7y ago
      That whole article is basically saying that those extra checks are useless anyway in correctly written code, as otherwise it would be code that can be tested and reached: On the other hand, in code that does check for and attempts to handle errors reported by the APIs, the new error handling paths tend to be poorly tested (if at all) because the runtime-constraint violation can typically be triggered only once, the first time it is found and before it's fixed. After the flaw is removed, the handling code can no longer be tested and, as the code evolves, can become a source of defects in the program.
    - microtherion 7y ago
      It's possible that they are calling the functions, but passing incorrect length arguments so frequently that they are best ignored.
  - zrm 7y ago
    > Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed. This irked me, because along with useless junk like memcpy_s, Annex K had memset_s, which in particular (and unlike memset(3)) was guaranteed not to be optimized out by the compiler. Meanwhile Spectre has made it more important than ever for programs to clear any sensitive data out of memory as soon as it's no longer needed, so we actually need that. And it's troublesome to either have half a dozen ifdefs for all the different platform-specific functions that do the same thing, with as many possibilities to call one of them wrong, or have to pick up a dependency on a crypto library just to get e.g. sodium_memzero().
    - rurban 7y ago
      Not arguing with your useless junk attitude. Useless junk is the glibc and its FORTIFY_SOURCE "maybe we catch it or maybe not" attempt. But sodium_memzero() is not safer than memset_s. If only provides a compiler barrier, but no memory barrier. AFAIK only my safeclib memset_s is "safe", but I don't provide a clflush there. Maybe I should.
      - zrm 7y ago
        All the more reason there should be a function in the C standard that does it properly and uniformly across platforms.
- dalore 7y ago
  Because that might add a bunch of code that may or may not be useful. It might be that this is inlined everywhere and so would bump some of code to a different alignment. Perhaps it's timing critical and this saved a few calls. Perhaps they use static analysis only. Or they might have debug versions where they do use the safety checks and then for production versions it's preprocessed out. There could be plenty of different reason.
  - ptx 7y ago
    > Or they might have debug versions where they do use the safety checks and then for production versions it's preprocessed out. Why would you do that? Most attacks will probably target your production environment rather than your development environment.
    - dalore 7y ago
      One could fuzz test the debug versions to ensure it's safe. And they really need the extra performance for prod. Perhaps they are confident that is enough testing? We know it can never be 100%

by dalore 7y ago

mikeash 7y ago

Right, but why not take thirty seconds to do the appropriate checks in the wrappers?

acqq 7y ago
Because it's far from being thirty seconds (as seen in the post by ploxiln here): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm The most interesting quote regarding these "safer" interfaces from the report: "The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. ... Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed."
- mikeash 7y ago
  I don’t understand. Your link is talking about the difficulty of using these functions. But here, the functions are already being used. What’s missing is implementations of them. They chose to implement these functions without the security checks, but implementing them with the security checks is not hard.
  - userbinator 7y ago
    That whole article is basically saying that those extra checks are useless anyway in correctly written code, as otherwise it would be code that can be tested and reached: On the other hand, in code that does check for and attempts to handle errors reported by the APIs, the new error handling paths tend to be poorly tested (if at all) because the runtime-constraint violation can typically be triggered only once, the first time it is found and before it's fixed. After the flaw is removed, the handling code can no longer be tested and, as the code evolves, can become a source of defects in the program.
  - microtherion 7y ago
    It's possible that they are calling the functions, but passing incorrect length arguments so frequently that they are best ignored.
- zrm 7y ago
  > Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed. This irked me, because along with useless junk like memcpy_s, Annex K had memset_s, which in particular (and unlike memset(3)) was guaranteed not to be optimized out by the compiler. Meanwhile Spectre has made it more important than ever for programs to clear any sensitive data out of memory as soon as it's no longer needed, so we actually need that. And it's troublesome to either have half a dozen ifdefs for all the different platform-specific functions that do the same thing, with as many possibilities to call one of them wrong, or have to pick up a dependency on a crypto library just to get e.g. sodium_memzero().
  - rurban 7y ago
    Not arguing with your useless junk attitude. Useless junk is the glibc and its FORTIFY_SOURCE "maybe we catch it or maybe not" attempt. But sodium_memzero() is not safer than memset_s. If only provides a compiler barrier, but no memory barrier. AFAIK only my safeclib memset_s is "safe", but I don't provide a clflush there. Maybe I should.
    - zrm 7y ago
      All the more reason there should be a function in the C standard that does it properly and uniformly across platforms.
dalore 7y ago
Because that might add a bunch of code that may or may not be useful. It might be that this is inlined everywhere and so would bump some of code to a different alignment. Perhaps it's timing critical and this saved a few calls. Perhaps they use static analysis only. Or they might have debug versions where they do use the safety checks and then for production versions it's preprocessed out. There could be plenty of different reason.
- ptx 7y ago
  > Or they might have debug versions where they do use the safety checks and then for production versions it's preprocessed out. Why would you do that? Most attacks will probably target your production environment rather than your development environment.
  - dalore 7y ago
    One could fuzz test the debug versions to ensure it's safe. And they really need the extra performance for prod. Perhaps they are confident that is enough testing? We know it can never be 100%