Howard Brazee writes:
One of the tough choices programmers come up with is when a 30 year
old program that has been modified every year - should be replaced.
This type of decision becomes more difficult with people who design
operating systems and systems that interface with other systems.
in much of the 90s, the biggest (internet) related threats were from buffer
overflow exploits ... mostly related to c language programming conventions.
lots of posts on this topic
http://www.garlic.com/~lynn/subintegrity.html#overflow
implementations done in other languages suffered much fewer (or none) overflow
exploits. I know of none in the original mainframe tcp/ip done in pascal/vs ...
i had done the enhancement to support rfc 1044 ... base thruput (on 3090) was
something like 44kbytes/sec aggregate thruput ... some tuning at cray research
between 4341-clone and cray, the rfc 1044 support was getting 1mbyte/sec ...
misc. past posts
http://www.garlic.com/~lynn/subnetwork.thm#1044
similarly, it has been claimed that there were no known buffer overflow
exploits in Multics (implemented in PLI) ... some past posts.
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the
Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the
Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the
Multics Security Evaluation
for some drift, multics was on the 5th floor ... and the science center was on
the 4th floor
http://www.garlic.com/~lynn/subtopic.html#545tech
which brought you virtual machines, the internal network (from which came
bitnet/earn), gml precursor to sgml, html, xml, etc), and loads of other online
and interactive tools.
around the turn of the century ... because of the introduction of automatic
scripting ... the exploits started to shift to half overflows and half
automatic scripting (i.e. files or email arriving from the network would
include script code that would be automatically executed).
I had tried to categorize information from various exploit databases
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
... looking to enhance my merged security taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glossnote
however, the descriptions were quite free form and I complained that they could
be quite difficult to categorize. since then there have been some announcements
that they would be adding more structure to exploit database entries to aid
categorization
later a more extensive exploit study ... including various human factor
characteristics came up with 1/3rd overloads, 1/3rd automatic scripting and 1/3
social engineering. social engineering includes phishing, convincing people to
divulge information, convinging people to execute programs arriving over the
network, etc.
some of the suggestions for transition to dumb devices ... isn't so much whether they are
dumb or not ... it is whether they support loading and execution of foreign (and
potentially extremely hostile) code. turns out that vast majority of devices that have
been classified as "dumb" are providing features for loading and execution of
foreign code (of one sort or another).
this is a problem we had to deal with on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
a couple decades ago ... and a flavor of it showed up on bitnet/earn
http://www.garlic.com/~lynn/subnetwork.html#bitnet
even before showing up on the internet ... ref ...
http://www.garlic.com/~lynn/2005b.html#20 Buffer overruns
one of the other issues with "smart" vis-a-vis "dumb" devices connected to the
internet ... is one of the most prevalent platforms dates back to something that was designed to
operate in totally unconnected environment ... and as such had no defenses and countermeasures.
some number of applications even grew up taking advantage of being able to assume complete control
of the machine (like games). later ... adding internet connectivity to the same platform created
quite a bit of a problem a) platform that was designed to have no defenses and countermeasures, b)
large set of applications that took advantage of the platform not having defenses and
countermeasures and c) connected to an extremely hostile network environment which requires
significant defenses and countermeasures.
recently there has been some work on using virtualization in attempt to address
the diametrically opposing requirements ... no defenses and countermeasures at
the same time requiring very extensive defenses and countermeasures.
other posts in this thread:
http://www.garlic.com/~lynn/2007b.html#6 Special characters in passwords was
Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was
Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was
Re: RACF - Password rules
for (lots of) other drift ... i designed the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
for "something you have" authentication ... from 3-factor authentication
paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor
its secret is never divulged and its authentication information always changes ... so there is nothing to skim/evesdrop for replay attacks. it isn't prone to the standard phishing attacks ...
since the secret is never divulged ... even the owner doesn't know the secret (and therefor
can't divulge it). It also has absolutely no provision for external loading/executing any
sort of foreign code. It uses public key ... so the same public key can be registered in
lots of different security domains w/o exposure to cross-domain attacks (like you have
with shared-secret "something you know" paradigms).
it was done somewhat in conjunction with work by the x9a10 financial standard
working group, which in the mid-90s had been given the requirement to preserve
the integrity of the financial infrastructure for all retail payments ...
resulting in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
one of the issues that was becoming prevalent in the mid-90s was skimming of static authentication information and transactions where just knowing the account number was sufficient. combination of x9.59 and aads eliminated static authentication information and also eliminated transactions where account number by itself was no longer sufficient. when account number by itself is no longer sufficient for (fraudulent) transactions ... much of the risk is eliminated from the majority of the recent data breaches and security breaches (being able to obtain records/logs of old transactions and replay the account number in new fraudulent transactions).
misc. recent posts
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high
priority for 2007
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high
priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high
priority for 2007
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high
priority for 2007
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high
priority for 2007
aads chip strawman also had work on how to make the same token acceptable to
lots of different institutions (i.e. not the same kind of token ... but the
same token belonging to a person) as an authentication mechanism. Current
infrastructure tends to have institutions providing each person, individual
tokens. I've claimed that if this was consistently followed ... a person would
have nearly as much difficulty dealing with large scores of tokens as they
currently have trying to deal with large scores of passwords. some past posts
about trying to move from a institution-centric paradigm to a person-centric
paradigm ... misc. past posts discussion institution-centric paradigm vis-a-vis
person-centric paradigm:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or
average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open
Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard
processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet
security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil
or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil
or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil
or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really
important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO
18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to
attacks lauched using stolen passwords?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
