Shifting the Odds
Shifting the Odds
Writing (More) Secure Software
Steve Bellovin
908-582-5886
smb@research.att.com
AT&T Research
Murray Hill, NJ 07974
L AT&T Steven M. Bellovin --- April 29, 1996 1

Shifting the Odds
If our software is buggy, what
does that say about its security?
---Robert H. Morris
L AT&T Steven M. Bellovin --- April 29, 1996 2

Shifting the Odds
What's the Problem?
ffl Software is buggy.
ffl Bugs in security-sensitive software are
often security holes.
ffl On the whole, the profession does not
know how to write correct code.
ffl But we can---and should---write software
that is more correct, and more secure.
L AT&T Steven M. Bellovin --- April 29, 1996 3

Shifting the Odds
Principles of Software
Engineering
ffl Simplicity is a virtue.
ffl If code is complex, you don't know if it's
right (but it probably isn't).
ffl In a complex system, isolate security-
critical modules. Make them (at least)
simple and correct.
L AT&T Steven M. Bellovin --- April 29, 1996 4

Shifting the Odds
Interface Design
ffl Modules should have a clean, clear,
precisely-defined interface.
ffl Reliance on global state is bad; it's too
hard to know what's going on at any
given time.
ffl Use of explicit parameters make input
assumptions explicit. (It also makes
multiple contexts possible, but that's not
always good.)
L AT&T Steven M. Bellovin --- April 29, 1996 5

Shifting the Odds
Transitive Trust
ffl Programs have to trust any programs
they invoke.
+ Trusted programs should not invoke any
untrustworthy programs.
ffl Similarly, they must ensure that untrusted
programs are not invoked indirectly.
L AT&T Steven M. Bellovin --- April 29, 1996 6

Shifting the Odds
Race Conditions
ffl Permission-checking cannot be separated
from access.
ffl Otherwise, the attacker can substitute a
new object for the one that was checked.
ffl Never use the access() system call for
security.
ffl It usually fails---but with race conditions,
you only have to win once.
L AT&T Steven M. Bellovin --- April 29, 1996 7

Shifting the Odds
C++ Lite
ffl Using class definitions forces interface
definition.
ffl Internal module structure hidden from the
outside.
ffl Constructors and destructors (can)
simplify storage management.
ffl Judicious use of operator definitions can
simplify code structure.
ffl But full C++ is arguably too complex to
use.
L AT&T Steven M. Bellovin --- April 29, 1996 8

Shifting the Odds
Case Study: Firewalls
ffl Firewalls are needed because most
network applications on most computers
are not trustable. That is, they may be
buggy.
ffl Firewalls work because they minimize the
amount of code that needs to be trusted.
ffl If you don't run the code, it doesn't
matter if it's buggy and insecure.
Firewalls shed code to exploit this
principle.
ffl In short, firewalls are a network response
to a software engineering problem.
L AT&T Steven M. Bellovin --- April 29, 1996 9

Shifting the Odds
Design Choices
ffl Eliminate fingerd, NFS, NIS, rlogind, etc.
ffl Restrict things like FTP.
ffl Deploy secure authentication.
L AT&T Steven M. Bellovin --- April 29, 1996 10

Shifting the Odds
Case Study: gopherd
ffl Information retrieval protocol.
ffl System sends back responses including
file type and ``selector string''.
ffl The selector string---often a file name---is
sent back to the server to request that
document.
ffl Control files are used to force special
actions, such as off-site links.
ffl But what if the user creates a bogus
selector or control file?
L AT&T Steven M. Bellovin --- April 29, 1996 11

Shifting the Odds
Implementation Choices
Option 1: Let the daemon decide what files
should be accessible from the outside.
ffl Parsing a file name is hard (though
simpler on Unix than on many other
systems).
ffl gopherd invokes other programs via the
shell; what about shell metacharacters?
ffl What about file read permissions?
Option 2: Let the system do it.
ffl Use chroot(); let the system control the
file system name space. (The basic
chroot() code is 15 years old, quite small,
and quite reliable.)
ffl No worries (from this perspective) about
metacharacters; other files (in effect)
aren't there.
ffl Rely on either chroot() or system file
modes for read permissions.
L AT&T Steven M. Bellovin --- April 29, 1996 12

Shifting the Odds
Advantages of Option 2
ffl No complex, error-prone permission-
checking code in the application.
ffl Easily accomodates different system-
level permissions (i.e., military-style
mandatory access controls).
ffl Simpler structure, more likely to be
correct.
L AT&T Steven M. Bellovin --- April 29, 1996 13

Shifting the Odds
Improving the Solution
Problem: chroot() is a privileged operation;
dare we give gopherd that much power?
Solution: Extremely early chroot() or
outboard module that sets up the
unprivileged environment before invoking
gopherd.
Problem: Shell metacharacters can still be
used to execute inappropriate commands.
Solution: Don't use the shell; it's too
powerful. Execute commands explicitly.
Problem: Shared ftp/gopher area can let
users change the gopherd structure and/or
cause execution of inappropriate
commands.
Solution: Use the system permission
mechanism so that gopherd can't access
files written by ftpd.
L AT&T Steven M. Bellovin --- April 29, 1996 14

Shifting the Odds
Case Study: ftpd
ffl Current implementation has overly-
general control structure. There is a lot
of reliance on global state variables.
ffl There are too many privileged operations
in the current code, which implies a need
for a lot of bookkeeping.
L AT&T Steven M. Bellovin --- April 29, 1996 15

Shifting the Odds
ftpcmd Main Loop
Read
command
line
Parse command and
check login state
Execute command
via parser
L AT&T Steven M. Bellovin --- April 29, 1996 16

Shifting the Odds
Login Sequence
USER command:
Clear login state
Get user profile
Check for anonymous; set flag
PASS command:
If not anonymous, check password; on
failure, clear state and exit.
Set directory, uid, from retrieved user
profile.
If anonymous, use chroot() for access
control.
Set logged-in flag.
L AT&T Steven M. Bellovin --- April 29, 1996 17

Shifting the Odds
Analysis
ffl Too much retained state: user profile,
anonymous flag, logged-in flag.
ffl Twisty control structure: too much other
code can be executed during login
sequence.
ffl chroot() --- the primary security
mechanism for anonymous FTP --- done
quite late, and depends on all that saved
state.
+ There have been at least three separate
bugs reported in the login process.
L AT&T Steven M. Bellovin --- April 29, 1996 18

Shifting the Odds
Solution
do --
read command
if (command == USER)
print error message
read next line
� while (TRUE)
if USER==ANONYMOUS
chroot()
set ANONYMOUS permissions
read and ignore PASS command
else
read PASS
get user profile
if !valid exit
set user permissions
while (!EOF) --
command processing
�
exit
Exercise: What would you change for a
firewall-only ftpd?
L AT&T Steven M. Bellovin --- April 29, 1996 19

Shifting the Odds
Fixed Solution
do --
read command
if (command == USER) break
print error message
read next line
� while (TRUE)
if USER==ANONYMOUS
chroot()
set ANONYMOUS permissions
read and ignore PASS command
else
read PASS
get user profile
if !valid exit
set user permissions
while (!EOF) --
command processing
�
exit
With so little code, the bugs are (more)
obvious.
L AT&T Steven M. Bellovin --- April 29, 1996 20

Shifting the Odds
Case Study: Remote
Execution in uucp
ffl Currently executes only a few commands,
under the uucp login.
ffl But spooled remote execution and file
transfer are useful in general.
ffl Can we add such a capability to uucp?
L AT&T Steven M. Bellovin --- April 29, 1996 21

Shifting the Odds
Choice 1 --- Let uucp do it
ffl Only root can switch to an arbitrary user
account. Should uucp run as root?
ffl Command execution is only loosely
coupled to remote machine identity; is the
coupling secure enough that it can be
trusted?
L AT&T Steven M. Bellovin --- April 29, 1996 22

Shifting the Odds
Choice 2 --- Use an
outboard privileged module
ffl Limit what has to be trusted. (N.B. uucp
is a large, complex program with a long
history of security bugs.)
ffl Use cryptographic authentication instead
of a password.
ffl Example: Koenig's asd package, layered
on top of uucp, has exactly 200 lines of
privileged code, plus 274 lines to calculate
a cryptographic checksum.
ffl Bonus: you can now use other transport
mechanisms.
L AT&T Steven M. Bellovin --- April 29, 1996 23

Shifting the Odds
How asd Words
unseal -K /etc/keys/user --- ``
instpkg --- ``
mail user
L AT&T Steven M. Bellovin --- April 29, 1996 24

Shifting the Odds
Case Study: rcp and rdist
ffl rcp and rdist use the rsh protocol.
ffl The rsh protocol, apart from its reliance
on names, requires that the client
program be on a ``privileged'' port
(whatever that is).
ffl Thus, rcp and rdist run as root.
ffl Both have a long history of security
holes: : :
L AT&T Steven M. Bellovin --- April 29, 1996 25

Shifting the Odds
Solutions
1. Don't use the protocol directly; invoke
the rsh command itself.
2. Invoke a small, trusted program that will
set up the socket and pass back an open
file descriptor (but watch out for race
conditions).
3. Use a real authentication mechanism.
L AT&T Steven M. Bellovin --- April 29, 1996 26

Shifting the Odds
Case Study: Web Security
ffl The servers are huge, complex programs
that do permission checking, parse file
names, pass state around, switch uids,
run user-written CGI scripts---and try to
manage cryptographic keys, accept
sensitive input, and manage access to
restricted content.
ffl Clients are told what to do by the server,
with choices ranging from the
benign---display this picture or simple
text---to redirections to other URLs,
Postscript pictures, and, ultimately, Java.
All the while, they must guard client keys,
user identities, and the whole machine
and network they're running on.
ffl The solution is left as an exercise for the
profession.
L AT&T Steven M. Bellovin --- April 29, 1996 27

Shifting the Odds
What Have We Done?
ffl Rely on simple primitives (chroot(),
operating system permission-checking,
etc.).
ffl Explicit separation of access control from
general complexity.
ffl Elimination of unnecessary code.
L AT&T Steven M. Bellovin --- April 29, 1996 28

Shifting the Odds
Authentication
ffl Many security problems are due to
authentication failures.
ffl Such failures are often very difficult to
detect, because the intruder appears to
be a valid user.
ffl Most authentication failures come from
bad assumptions about the environment.
L AT&T Steven M. Bellovin --- April 29, 1996 29

Shifting the Odds
Types of Authentication
Passwords An obsolete technology.
Passwords can be guessed, given away, or
collected by Trojan horses or
eavesdroppers.
Name-based Relies on the trustworthiness of
the network and on the integrity of the
address-to-name mapping system.
Biometric Requires special-purpose
hardware; gives probabilistic result;
subject to biological disruptions (does a
voiceprint work if the employee has a
cold?).
Cryptographic Generally the best
mechanism, but a great deal of care is
required.
L AT&T Steven M. Bellovin --- April 29, 1996 30

Shifting the Odds
Cryptography
ffl Cryptography can be used for privacy and
for authentication.
ffl The basic tools---conventional and
public-key cryptography, secure hash
functions, digital signatures, etc.---are
generally used as the building blocks for
cryptographic protocols such as Kerberos.
ffl But the design of these protocols is a
tricky matter; errors abound. There are
many published examples that simply
aren't secure.
ffl Among the dangers: cut-and-paste
attacks, replays, attacks on one party's
clock, multiple concurrent sessions.
L AT&T Steven M. Bellovin --- April 29, 1996 31

Shifting the Odds
Sample Protocol Failure (by
Needham and Abadi)
Message 1 A ! S : A; B
Message 2 S ! A : CA;CB
Message 3 A ! B : CA;CB; ffK ab ; Tag K \Gamma1
a
g K b
But B can resend parts of that message to C,
pretending to be A:
Message 3 0 B ! C : CA;CC; ffK ab ; Tag K \Gamma1
a
g K c
The quantity fK ab ; Tag K \Gamma1
a
is treated as a
black box.
L AT&T Steven M. Bellovin --- April 29, 1996 32

Shifting the Odds
General Rules for
Cryptography
ffl Know your enemy---how strong must the
cryptography be?
ffl Protocol failures are more dangerous,
since once found they require less
expertise to exploit.
ffl Dedicated cryptographic hardware is a
Good Thing; general-purpose computers
should not, in general, be entrusted with
secret keys.
+ But good cryptography is not a
replacement for correct software.
L AT&T Steven M. Bellovin --- April 29, 1996 33

Shifting the Odds
Assurance---How Do We
Know Our Code is Correct?
+ We never really know.
ffl Formal certification of secure systems
does address assurance; this is often
overlooked by Feature Creatures.
ffl Example: ``B2-compliant'' means a few
features were added; a B2 evaluation
requires well-structured code,
configuration management, etc.
ffl Newer security standards (i.e., the
Canadian document) make assurance
orthogonal to features.
L AT&T Steven M. Bellovin --- April 29, 1996 34

Shifting the Odds
What Should You Do?
ffl Use good software engineering practices.
ffl Analyze your assumptions.
ffl Build a connectivity matrix. Who is able
to talk to whom? Who is allowed to?
How do you enforce this?
ffl Rely on small, simple programs for
security checking.
ffl But remember that computer security
isn't everything.
L AT&T Steven M. Bellovin --- April 29, 1996 35

Shifting the Odds
HACKERS
L AT&T Steven M. Bellovin --- April 29, 1996 36