On 04/21/2014 08:38 PM, Ronald F. Guilmette wrote: <snipping good stuff before this good stuff> > I suspect that a whole lot of folks might be either (a) red faced or else > (b) deeply concerned if a scientifically derived estimate of the number of > *remaining* (and as-yet undiscovered) bugs in that package were published. Yes indeed. I think your comment 'as-yet undiscovered' is of an aspirational character. Imagine if your job, every day, is to take all the same talent and training involved in creating all this to find exploits. A person whose mind isn't absorbed with knowing everything about one area enough to move it's art ahead, but enough about all the areas with emphasis on their interfaces and edge conditions. For example, just the right compiler quirk or processor microcode quirk with just the right OS quirk in just the right library routine, or a quirk in the firmware of any device able to generate memory read bus cycles (smart network interface chips and hardware RAID cards come to mind, and, oh my -- graphics processors.... Every time device memory is mapped into user space ... worry.). The folks that do that are good at not sharing, and using them sparingly. It's the same problem faced by any defender: the defenders have to be entirely right all the time, while the exploit finder only has to be right once. Only rigor approaching the level of math theorems applied to software security (a trace easier than 'software correctness' I expect) can offer trustworthy assurances about blocking software-only exploits. The semantics of all our current popular languages, for reasons to do with making early 8 bit processors deliver value, are silent about what happens to data that 'goes out of scope' or 'is freed', most of the time the OS just marks the memory page 'unused' without knowing whether it's of importance to wipe. A few little-used languages had 'garbage collection routines' that could have been good at wiping. But mostly our languages struggled to do the right thing with data people cared about to bother much with what happened to it when 'done'. There was no performance that could be spared to "protect against data dumpster-divers". And wow look at what happened to programming discipline, particularly application programming, when throwing another gigabyte of ram or another processor into a machine cost less than tuning a routine. Most of the time it's not worth the processor time to wipe old data as the pages are bits from an old movie data anyhow. But most of the time isn't all of the time. 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. I'll go back to lurking now! Thanks for all your efforts. H _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"