| |||||||||||||
Cryptographic weakness on Debian systemsCryptographic weakness on Debian systemsPosted May 14, 2008 8:56 UTC (Wed) by tialaramex (subscriber, #21167)In reply to: Cryptographic weakness on Debian systems by Ross Parent article: Cryptographic weakness on Debian systems
I'm really not sure than an uninitialised (note, it is properly allocated so there's no chance
of a segfault or similar, it has just not been initialised by the C program) buffer has this
effect in the C standard.
How would the standard distinguish this case from the case where the buffer simply doesn't
belong to the C program ? If my C program looks at the MMIO registers of a PCI card, it
certainly isn't permissible for me to just arbitrarily zero them so that I'm sure they're
initialised...
There is a big difference between behaviour which is implementation defined (and your
implementation should document its behavior) such as the bit patterns of floating point
numbers, and behaviour which the C standard says is altogether undefined and thus you might
reformat your hard disk or start World War III. Clearly
{ char x[40]; x[105] = 'q'; }
is in the latter category, but I'd really want to see chapter and verse quoted before I
believed that the same applies to
{ char m, x[40]; m = x[20]; }
which is the situation we're looking at in OpenSSL.
(Log in to post comments)
Cryptographic weakness on Debian systems Posted May 14, 2008 10:50 UTC (Wed) by nix (subscriber, #2304) [Link] `If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate' combines with a definition of undefined behaviour which includes behaviour `upon use of... indeterminately valued objects'. It's pretty clearly undefined.
Cryptographic weakness on Debian systems Posted May 14, 2008 13:17 UTC (Wed) by endecotp (guest, #36428) [Link] Note the "has automatic storage duration" bit in nix's quote. This is why e.g. reading your mmap()'d PCI device registers is not undefined.
Cryptographic weakness on Debian systems Posted May 14, 2008 22:50 UTC (Wed) by dvdeug (subscriber, #10998) [Link]
> I'd really want to see chapter and verse quoted before I believed that the same applies to
> { char m, x[40]; m = x[20]; }
On real hardware, without any compiler optimizations, both
{float m, x[40]; m = x[20];}
and
{char *m, (*x)[40]; m = x[20];}
can cause the program to crash, as the mere copy of an invalid float or invalid pointer can
generate fatal errors.
Cryptographic weakness on Debian systems Posted May 15, 2008 6:06 UTC (Thu) by lysse (guest, #3190) [Link] A float I can buy, if the FPU trips over an invalid bit pattern - but an invalid pointer? Educate me, please - cite an instance!
Cryptographic weakness on Debian systems Posted May 15, 2008 21:38 UTC (Thu) by Ross (subscriber, #4065) [Link] Not all memory spaces are flat, so some pointer values as stored in memory might not be loadable into the registers that implement them. (Due to segmentation, typed memory, etc.) Obviously that doesn't apply to most of the systems in use today (with the exception of function pointers).
Cryptographic weakness on Debian systems Posted May 19, 2008 4:38 UTC (Mon) by donwaugaman (subscriber, #4214) [Link] On a segmented architecture, load an invalid descriptor into a segment register. Boom! Not on all architectures, of course - I think the 386 family would be safe with this until you tried to access the segment - but some machines would generate an exception on the load.
Cryptographic weakness on Debian systems Posted May 15, 2008 2:28 UTC (Thu) by Ross (subscriber, #4065) [Link]
I didn't mean that it wasn't properly allocated.
The program is reading data returned by malloc().
Not only can you not trust it to have any specific value (or to be "random"), but it invokes
undefined behavior just like reading an uninitialized local variable. The only stuff which is
exempt from this is global data (static), or data guaranteed to be initialized by your
environment before your program starts.
> is in the latter category, but I'd really want to see chapter and verse quoted before I
believed that the same applies to
> { char m, x[40]; m = x[20]; }
> which is the situation we're looking at in OpenSSL.
I thought we were talking about malloc()ed memory...
char *x = malloc(20);
printf("%c\n", x[10]); /* undefined behavior */
If it's a global struct or array, then it should contain all zero bytes -- not uninitialized
at all.
I don't have a copy of the standard, but check in the list of actions which invoke undefined
behavior, in the library section. A draft I have contains:
"- The value of the object allocated by the malloc function is used"
-Ross
|
|||||||||||||