De Raadt + FBSD + OpenSSH + hole?

[hcoin]

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