[Cryptography] Other obvious issues being ignored?

[Peter Gutmann]

John-Mark Gurney <jmg at funkthat.com> writes:

>The problem is the C standard and has nothing to do w/ the C compilers.  The
>standard allows the compilers to do these optimizations, so they are
>perfectly legal and correct.

The problem is squarely with the compiler writers.  The C standard is (of
necessity, although in some cases it's really just unnecessary pedantry)
written in a rather generic manner.  One example is around undefined behaviour
(UB), where UB is an open-ended escape hatch under which anything is
permitted.  For example a compiler that, if it thought an integer overflow was
possible in a certain case, reformatted your hard drive, is fully C standards-
compliant (UB has been triggered, and the C standard doesn't specify what will
happen next).  gcc takes this approach.  That is, it doesn't reformat your
hard drive because the braindamage is so obvious that people would complain,
what it does is produce executable code that's nothing like what the source
code indicates.  MSVC takes the common-sense approach and leaves your code
intact (apparently icc does too, but I haven't been able to check that).  Both
compilers are fully compliant with the C standard, but one of them is so
dangerous that I can't believe it's being used for things like safety-critical
systems.

>Until the C standard adopts something to address these issues, it just isn't
>possible to write secure code in C today.

You can fix it in two ways, either the C standard or the compiler.  MSVC
doesn't have these issues (it doesn't break your code, or at least not as
freely as gcc does), it has a safe zeroise function SecureZeroMemory()
/RtlSecureZeroMemory(), and it has an entire family of _s range-check
replacements for the traditional C unsafe ops (that's getting more into the
libraries than the compiler, but again on the gcc side it's something that the
glibc maintainer has resisted adding even for the simple strlcpy() function,
and Posix has rejected them as well).

Peter.