\documentstyle[]{article}
\addtolength{\oddsidemargin}{-1in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1.75in}
\addtolength{\textheight}{1.75in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#7: Use of ChangeLogs to Improve Security\\\\

Changelogs and revision control have existed since the first large
programming projects were undertaken, but traditionally their use has
been restricted to the design phases of a project.  However, expanded
use of these files to cover the entire lifespan of a product can
impressively increase the security of that product.  Each change to a
product brings with it both the possibility of intentional and
accidental security breaches.  Furthermore, as in any complex system,
it is often the combination of many changes that breaks the whole.
All of these problems can be partially alleviated through the use of
changelogs and revision control systems.

As seen in the "The System Programmer Attack", any time a program is
modified, the programmer has a chance to add a new security hole to
allow himself further access.  Such holes are typically known as "back
doors", and are responsible for many famous break-ins, including the
"debug" option with sendmail that was partially responsible for the
Internet Worm's proliferation.  Although changelogs and revision
control themselves do nothing to stop programmers from inserting
dangerous changes, they greatly simplify the process of auditing
the work of each programmer.  Instead of having to reverify the entire
program each time a programmer modifies it, the auditor can simply run
a diff between the old and new versions and quickly determine where
the changes occur, and where new security holes might have been
introduced. 

Even with the best intentioned of programmers, new bugs are usually
introduced in a program every time a feature is added, and even when
other bugs are being fixed.  These unintentional bugs are frequently
very subtle, and may escape even a second auditor who reviews the
code.  However, a good changelog will make it much easier to pinpoint
the where a bug was introduced, if a new failure mode or security hole
appears when a new version is released.  Additionally, a good
description of each change in the changelog file will allow
experienced programmers to quickly overview larg batches of changes,
looking for common problems, such as those described in this reading.
Frequently the small programming tasks are assigned to junior
programmers, who are more likely to make the common errors.  With
changelogs, the experienced programmers to find these bugs without
needing to trace each line of code.

As we've seen with large systems, the complexity of the system is
far greater than the sum of the complexity of individual components.
A proper revision control system can help show the combination of
changes that brought about the problem.  For example, shadowing of a
password file and the Sun NIS are individually reasonable attempts to
increase security on a workstation.  However, trying to run both at
the same time, as many sysadmins found, created a large security hole.
Shadowing creates a shadow of the passwd file, which NIS is supposed
to use instead of the default passwd file.  However, due to poor
implementation, NIS occassionally used the original passwd file, which
no longer included passwords, allowing users to log in without typing
anything.  A system changelog showing that both products were
installed could help point out why this gaping hole was suddenly
appearing.

Revision control and changelogs on their own are not a panacea.
However, combined with a good auditing system and experienced code
reviewers, it can greatly help the security of a system.  By
preventing as many new holes from being introduced as possible, and
easing the correction of old holes, the overall security of the system
is increased.



\end{document}

   Read Appendix 6.A from "The protection of information in computer
   systems" by Saltzer and Schroeder (pages 6-34 through 6-53 of reading
   #28). Pages 6-46 through 6-53 were missing from the reader, but we
   handed them out as handout #15. See the course secretary, Neena Lyall,
   in NE43-523 if you didn't get them. Your one-page reading report
   should address the following question:

     Look carefully at protection failure case studies #4 (the system
     programmer attack), #10 (the system release trick), and #12
     (unintentional signaling with clandestine channels) of appendix 6.A.
     Choose one of these (or, choose an interesting protection failure
     you have encountered or read about on your own) and do one of the
     following:

     1. Explain which, if any, of the security design principles
     described in "The protection of information in computer systems" (on
     pages 1282-3) were violated by the system in the case study.

     2. Come up with a general security design principle of your own
     that, if applied, would have helped avoid that failure.


17: hack dec, so released programs all have implanted bug
18: multi-use password
19: fucked use of DES
20: enigma reflector
21: wrong key generator
