Re: [Lit.] Buffer overruns
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 01/29/05
- Next message: BRG: "Re: [Lit.] Buffer overruns"
- Previous message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 29 Jan 2005 09:56:53 -0700
infobahn <infobahn@btinternet.com> writes:
> My first programming language was BASIC (on an IBM mainframe running
> an OS called MUSIC). When the mainframe powers-that-be switched to
> VM-CMS, I picked up a bit of IBM BASIC as well as VS BASIC. I also
> learned EXEC, which taught me how to draw ampersands. :-) I spent
> quite a long time messing around with EXEC, since it was
> surprisingly powerful (and I won't go into details here,
> *cough*). My next languages were 68000 assembly language and
> Pascal. Mercifully, I have forgotten both entirely. I came to C
> comparatively late, about 15 years ago, and Linux even later, about
> 5 or 6 years ago. I've had to mess around with data on
> minicomputers, mainframes, micros, STBs, and even - heaven help us -
> a Pick system. I've munged that data, for better or for worse, using
> COBOL, C, C++, Perl, Python, Databasic, dBase, Visual Basic, PHP,
> and even straight binary on occasion. That list may be
> incomplete. (I don't claim expertise in all those languages, by the
> way. Sometimes I pick up a language to do a single task, and then
> put it thankfully back in the Oblivion Closet. Python being a
> definite case in point.)
one of the issues is that both the systems environment and the
programming language can be influenced by the operational environment.
most of vm/cms (and its predecessor cp67/cms) was written in
assembler, however it was heavily influenced by hostile, adversarial
operational environment. the cp67 timesharing sysetm deployed
at the cambridge science center, 545tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
provided time-sharing services to people in corporate hdqtrs handling
the most sensitive of corporate data as well as online access to
various studnets from BU, Harvard, MIT, etc. around the boston area (i
had previously mention that there were no known security type breaches
... there were a couple of denial of service attacks that were quickly
dealt with).
cp67/cms (and later vm/cms) was also used at basis for many early
time-sharing services ... NCSS, IDC, Tymshare, etc. ... where you
could assume that there were spectrum of different corporate clients
that could easily be in competition. There was somewhat a distinction
between cp67 that went on the 4th flr and multics that went on the 5th
flr ... the range of open, commercial timesharing services that were
deployed using the 4th flr system ... as well as some number of the
other types of deployments.
Note, there were three command processors done on CMS, the original
CMS exec from the mid-60s, Cris's EXEC2 from the early '70s, and
Mike's REX from the late '70s (although released as REXX in the early
'80s).
part of the issue was being able to respond to adversarial and hostile
attacks ... like you current see in the frequent buffer overflow
attacks ... recent ref:
http://www.garlic.com/~lynn/subtopic.html#2005b.html#43 [Lit.] Buffer overruns
and creating defense-in-depth as countermeasures. slightly related
was recent post in this thread that only ran in a.f.c
http://www.garlic.com/~lynn/2005b.html#35
about the hostile i/o environment of the disk engineering lab
http://www.garlic.com/~lynn/subtopic.html#disk
and redoing the i/o subsystem so that it never failed. The problem was
that normal mvs mainframe system had something like 15 minute MTBF
when dealing with single disk testcell (although it normally ran fine
with whole disk farms for extended periods). The problem was that the
disk testcell environment was extremely hostile, a single disk
testcell generating more (and never before seen) errors in 15 minutes
than whole disk farms might generate in years.
One assertion is that C and many of the C-based platforms and
applications had quite a bit of evolution in environments that were
rarely hostile. In some cases, the platforms and applications had a
design point of an isolated and relatively congenial operational
environment ... not being exposed to things like the buffer overflow
*attacks* that are currently being documented in papers, magazine
articles, and books (and motivation for specialized hardware and
operating system support to contain the effects of the exploits and
attacks).
One possible indication is if situation goes beyond simple buffer
overflow failures and there appears to be a whole sub-culter involved
in exploits and attacks specifically related to buffer overflow
vulnerabilities (with the evidence of papers, articles, books on the
subject of buffer overflow *attacks*, as well as specialized hardware
and operating system support) ... then the situation has gone beyond
simply training better programmers.
Going back to the analogies in earlier posts ... when people start
complaining about the alarming number of traffic fatalities because of
people crossing the center line ... on old 101, on 17 going over santa
cruz mountains ... or even more recently crossing the meridian on 85
... you are facing more than simply better driver's training and
traffic enforcement ... you are talking about needing some serious
concrete traffic barriers.
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: BRG: "Re: [Lit.] Buffer overruns"
- Previous message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Reply: Anne & Lynn Wheeler: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
