February 2000
- datagram protocol design theory? (Question about multithreaded servers) Ola Fosheim Grøstad
- Library error J C Lawrence
- Semi-OT: Linux support in commercial MUDs? Ola Fosheim Grøstad
- From the Apache Referrer logs J C Lawrence
- From the Apache Referrer logs Kris Van Hees
- good muds for ai programming? Robert Zubek
- good muds for ai programming? J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling cg@ami-cg.GraySage.Edmonton.AB.CA
- Event Scheduling J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Miroslav Silovic
- Event Scheduling Jp Calderone
- Event Scheduling Ola Fosheim Grøstad
- Event Scheduling Miroslav Silovic
- Event Scheduling J C Lawrence
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- IO Speed Suggestions Christopher Kohnert
- IO Speed Suggestions J C Lawrence
- Couple of articles Koster, Raph
- Couple of articles Dr Richard A. Bartle
- OT: Soliciting advice from Canadians Alex Oren
- MUD Specific Building pages MichelleThompson
- MUD Specific Building pages J C Lawrence
- Embedding Python icecube@ihug.co.nz
- Embedding Python icecube@ihug.co.nz
- Embedding Python J C Lawrence
- Embedding Python Todd McKimmey
- Embedding Python Oliver Jowett
- Embedding Python Todd McKimmey
- ADMIN: List post rejections J C Lawrence
- distributed objects Kevin Littlejohn
- distributed objects Vijay Weasel Prabhakar
- distributed objects Brandon J. Rickman
- distributed objects J C Lawrence
- distributed objects Koster, Raph
- distributed objects Vijay Weasel Prabhakar
- distributed objects David Bennett
- distributed objects Phillip Lenhardt
- distributed objects cjones@one.net
- distributed objects F. Randall Farmer
- distributed objects Ola Fosheim Grøstad
- distributed objects Kevin Littlejohn
- distributed objects J C Lawrence
- distributed objects Gary Whitten
- distributed objects Balthazaar
- distributed objects J C Lawrence
- distributed objects Ola Fosheim Grøstad
- distributed objects Eli Stevens {Grey}
- distributed objects Jon A. Lambert
- distributed objects Charles Hughes
- distributed objects Caliban Tiresias Darklock
- distributed objects Charles Hughes
- distributed objects J C Lawrence
- distributed objects J C Lawrence
- distributed objects Charles Hughes
- distributed objects Charles Hughes
- distributed objects Laurent Bossavit
- distributed objects Kevin Littlejohn
- distributed objects markm@caplet.com
- distributed objects KevinL
- Distributed Objects Justin Rogers
- Security J C Lawrence
A wonderfully applicable Bruse Schneir quote:
http://slashdot.org/interviews/99/10/29/0832246.shtml
Especially given that game worlds and their controls, data
structures, and dependencies are inherently complex (whcih tends to
leak over into protocol and system complexity):
--<cut>--
The real problem with protocols, and the thing that is the hardest
to deal with, is all the non-cryptographic dressing around the core
protocols. This is where the real insecurities lie. Security's worst
enemy is complexity.
This might seem an odd statement, especially in the light of the
many simple systems that exhibit critical security failures. It is
true nonetheless. Simple failures are simple to avoid, and often
simple to fix. The problem in these cases is not a lack of knowledge
of how to do it right, but a refusal (or inability) to apply this
knowledge. Complexity, however, is a different beast; we do not
really know how to handle it. Complex systems exhibit more failures
as well as more complex failures. These failures are harder to fix
because the systems are more complex, and before you know it the
system has become unmanageable.
Designing any software system is always a matter of weighing and
reconciling different requirements: functionality, efficiency,
political acceptability, security, backward compatibility,
deadlines, flexibility, ease of use, and many more. The unspoken
requirement is often simplicity. If the system gets too complex, it
becomes too difficult and too expensive to make and
maintain. Because fulfilling more of the other requirements usually
involves a more complex design, many systems end up with a design
that is as complex as the designers and implementers can reasonably
handle. (Other systems end up with a design that is too complex to
handle, and the project fails accordingly.)
Virtually all software is developed using a try-and-fix
methodology. Small pieces are implemented, tested, fixed, and tested
again. Several of these small pieces are combined into a larger
module, and this module is tested, fixed, and tested again. The end
result is software that more or less functions as expected, although
we are all familiar with the high frequency of functional failures
of software systems.
This process of making fairly complex systems and implementing them
with a try-and-fix methodology has a devastating effect on
security. The central reason is that you cannot easily test for
security; security is not a functional aspect of the
system. Therefore, security bugs are not detected and fixed during
the development process in the same way that functional bugs
are. Suppose a reasonable-sized program is developed without any
testing at all during development and quality control. We feel
confident in stating that the result will be a completely useless
program; most likely it will not perform any of the desired
functions correctly. Yet this is exactly what we get from the
try-and-fix methodology with respect to security.
The only reasonable way to "test" the security of a system is to
perform security reviews on it. A security review is a manual
process; it is very expensive in terms of time and effort. And just
as functional testing cannot prove the absence of bugs, a security
review cannot show that the product is in fact secure. The more
complex the system is, the harder a security evaluation becomes. A
more complex system will have more security-related errors in the
specification, design, and implementation. We claim that the number
of errors and difficulty of the evaluation are not linear functions
of the complexity, but in fact grow much faster.
For the sake of simplicity, let us assume the system has n different
options, each with two possible choices. Then, there are about n^2
different pairs of options that could interact in unexpected ways,
and 2^n different configurations altogether. Each possible
interaction can lead to a security weakness, and the number of
possible complex interactions that involve several options is
huge. We therefore expect that the number of actual security
weaknesses grows very rapidly with increasing complexity.
The increased number of possible interactions creates more work
during the security evaluation. For a system with a moderate number
of options, checking all the two-option interactions becomes a huge
amount of work. Checking every possible configuration is effectively
impossible. Thus the difficulty of performing security evaluations
also grows very rapidly with increasing complexity. The combination
of additional (potential) weaknesses and a more difficult security
analysis unavoidably results in insecure systems.
In actual systems, the situation is not quite so bad; there are
often options that are "orthogonal" in that they have no relation or
interaction with each other. This occurs, for example, if the
options are on different layers in the communication system, and the
layers are separated by a well-defined interface that does not
"show" the options on either side. For this very reason, such a
separation of a system into relatively independent modules with
clearly defined interfaces is a hallmark of good design. Good
modularization can dramatically reduce the effective complexity of a
system without the need to eliminate important features. Options
within a single module can of course still have interactions that
need to be analyzed, so the number of options per module should be
minimized. Modularization works well when used properly, but most
actual systems still include cross-dependencies where options in
different modules do affect each other.
A more complex system loses on all fronts. It contains more
weaknesses to start with, it is much harder to analyze, and it is
much harder to implement without introducing security-critical
errors in the implementation.
This increase in the number of security weaknesses interacts
destructively with the weakest-link property of security: the
security of the overall system is limited by the security of its
weakest link. Any single weakness can destroy the security of the
entire system.
Complexity not only makes it virtually impossible to create a secure
system, it also makes the system extremely hard to manage. The
people running the actual system typically do not have a thorough
understanding of the system and the security issues
involved. Configuration options should therefore be kept to a
minimum, and the options should provide a very simple model to the
user. Complex combinations of options are very likely to be
configured erroneously, resulting in a loss of security. There are
many stories throughout history that illustrate how management of
complex systems is often the weakest link.
I repeat: security's worst enemy is complexity. The most serious
protocol problem is how to deal with complex protocols (or how to
strip them down to the bone).
--<cut>--
--
J C Lawrence Home: claw@kanga.nu
----------(*) Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=-- - commercial muds and cable TV (was code base inquiry ) Sellers, Michael
- commercial muds and cable TV (was code base inquiry ) Matthew Mihaly
- commercial muds and cable TV (was code base inq uiry ) Sellers, Michael
- commercial muds and cable TV (was code base inq uiry ) Matthew Mihaly
- business models Matthew Mihaly
- business models Daniel.Harman@barclayscapital.com
- business models Vincent Archer
- business models Dave Rickey
- a shrinking pool of players? Johan J Ingles-le Nobel
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Bryce Harrington
- a shrinking pool of players? Travis S. Casey
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? Ryan P.
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Draymoor
- a shrinking pool of players? Koster, Raph
- The Endeavour Map and MUD Applications Michael Hohensee
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications David Bennett
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Eli Stevens {Grey}
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Koster, Raph
- The Endeavour Map and MUD Applications Lo, Kam
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Joel Dillon
- The Endeavour Map and MUD Applications Justin Rogers
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist J C Lawrence
- Next gen MUD wishlist Chris Jones
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Sellers, Michael
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Codebase Ideas punitac@prodigy.net
- Codebase Ideas Bryce Harrington
- Codebase Ideas Aaron Mitchell
- OT: Money as motivator (was code base inquiry ) J C Lawrence
- OT: Money as motivator (was code base inquiry ) Matthew Mihaly
- Guide Applicant : Player Ratio Geoffrey A. MacDougall
- Guide Applicant : Player Ratio Matthew Mihaly
- MUD-Dev digest, Vol 1 #286 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #286 - 13 msgs Caliban Tiresias Darklock
- MUD-Dev digest, Vol 1 #286 - 13 msgs Koster, Raph
- voice vs. text Matthew Mihaly
- voice vs. text Justin Rogers
- voice vs. text John Bertoglio
- voice vs. text Lovecraft
- voice vs. text Lo, Kam
- voice vs. text Hans-Henrik Staerfeldt
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Justin Rogers
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Dynamic help files, was code base inquiry Richard Woolcock
- OpenSource licenses for game rules? J C Lawrence
- To all the devoted! (fwd) J C Lawrence
- Newbies Johan J Ingles-le Nobel
- MUD-Dev digest, Vol 1 #288 - 9 msgs Dr. Cat
- (fwd) Commercial-use Restrictions on Code Bases (was: help me find 100% free graphical mud) J C Lawrence
- (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...'] J C Lawrence
- Distribution Geir Harald Hansen
- player persistence Matthew Mihaly
- [Off-topic] GDC-2000 Derek Snider
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 Justin Lockshaw
- [Off-topic] GDC-2000 Christopher Allen
- [Off-topic] GDC-2000 Matthew Mihaly
- [Off-topic] GDC-2000 Joe Andrieu
- [Off-topic] GDC-2000 Kristen L. Koster
- [Off-topic] GDC-2000 Richard A. Bartle
- [Off-topic] GDC-2000 Bruce
- [Off-topic] GDC-2000 David Bennett
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] AAAI symposium (was: GDC-2000) Robert Zubek
- MSP Richard Ross
- Privateer-style mu*? Bobby Bailey
- Minimum community sizes Dan Root
- Minimum community sizes Koster, Raph
- Minimum community sizes Dan Root
- Minimum community sizes adam@treyarch.com
- Minimum community sizes Matthew Mihaly
- Minimum community sizes David Bennett
- Minimum community sizes Matthew Mihaly
- Pike codebase Daniel Podlejski
- chil@gate.net Joel Kelso