Re: Ancient history

"Jon A. Solworth" <solworth@cs.uic.edu> writes:
> The situation with C-related bugs is, I believe, analagous to that of
> covert channels. Covert channels were known in the public literature
> since 1973 when Butler Lampson wrote "A note on the confinement
> problem". It is believed to be known before that by certain government
> agencies. But the mapping out of the types of covert channels, the
> theoretical structure (non-interference), and determining systematic
> methods for their analysis and measurement took decades. See J. Millen
> in 1999's oakland statement "20 years of covert channel modelling and
> analysis" (A one page, largely non-technical, very humerous statement).

a post i thot i made (while on the road) may have gotten lost in some
process ... i did my normal archive process
http://www.garlic.com/~lynn/2005j.html#49 Public disclosure of discovered vulnerabilities
and it followed
http://www.garlic.com/~lynn/2005j.html#48 Public disclosure of discovered vulnerabilities

but subsequent checking ... never had it show up.

basically human administrative manual operations are subject to
mistakes, C buffers have implicit lengths that are open to human
management and mistakes. Other environments ... including purely
assembler-based infrastructure have had buffers with explicit
associated lengths and normal infrastructure operations (whether
assembler implemented or in any other language) make regular use of
the explicit length fields in their normal operations.

As a result ... there are drastically fewer buffer length exploits in
this environments (compared to c-language environments) ... even when
they involve exclusive assembler implementation. In theory, assembler
offers a huge number of additional opportunities for programmers to
shoot themselves in the foot (compared to c) ... but for environments
with explicit buffer lengths as part of the normal infrastructure ...
buffer related mistakes are drastically fewer ... even for pure
assembler programming environments.

What you do see in pure assembler programming environments is a lot of
reguster management vulnerabilities. assembler forces the programmer
to manage register contents (in much the same way that c force the
programmer to manage buffer lengths). common failures in assembler
involve registers having incorrect contents .... which can really be
manifested when the contents are suppose to be pointers. frequently
anomolous code paths are involved ... when specific code paths have
not sufficiently prepared register values for later use (under manual
programmer administrative control). for contrast ... in the c language
environment ... incorrect register value related failures are
significant fewer ... because the c language programmer is rarely
involved in manually managing register content values.

common to many environments where there is programmer administrative
manual management of buffer allocation/deallocation is the problem of
dangling pointers. this is similar, but different to the assembler
environment of incorrect management of register values. In the
dangling pointer case ... the vulnerability is programmer manual
administrative management of pointers syncronized with buffer
allocation/deallocation ... where pointers can incorrectly remain in
use after the associated storage/buffer areas has been deallocaetd.

in the typical physical world threat/response model ... when various
types of mistakes have become especially prevalent (as in the case of
c language related buffer overflow exploits) ... effective
conpensating processes are typically created ... to eliminate the
wide-spread occurance of such problems.

lots of past posts specifically related to the extensive buffer
overflow exploits in c language environments
http://www.garlic.com/~lynn/subpubkey.html#overflow

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/