In message <[email protected]>, "hcoin" <[email protected]> wrote: >Perhaps we should consider adding a variable attribute like 'secure' >much like 'volatile' was added, to cause the compiler to generate code >wiping such variables when they go out of scope, force initialize them >to a known bit pattern, and only allocate those variables to pages that >are wiped on free and that can't be referenced by pointer or other means >except by a function or procedure that also has a 'secure' attribute. In response to Heartbleed, I also put forward a somewhat different idea, but one which was also focused on new compiler options that might help to insure that code for which security is critical (e.g. OpenSSL) wouldn't be getting access to data that had been free()'d and/or data which had been placed into local variables, within a particular stack frame, after the corresponding function call had returned. Unfortunately, as it was then explained to me, none of these ideas would have helped prevent Heartbleed. In the case of Heartbleed, the problem wasn't that a hunk of ``uninitialized'' memory was accessed, but rather that an attacker could cause OpenSSL to create a buffer of size `N', fill it with valid data, but then later on the attacker could get OpenSSL to send back all the data in that buffer _and_ some _additional_ (perhaps validly initialized) data locations well past the end of that buffer. There's very little that a compiler, a run-time system, or even hardware can do to prevent this sort of thing. Careful programming and an object orientation might have saved the day, but having looked at a bit of the relevant code myself, I can say with some certainty that none of the latter was immediately evident. Regards, rfg _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"