  Security
  Markus Gutschke, gutschk@math.uni-muenster.de
  1 July 1997

  Here are some security considerations relating to network booting.
  ______________________________________________________________________

  Table of Contents


  1. Introduction

  2. SCOPE OF THIS TEXT

  3. PC ARCHITECTURE

  4. PASSWORDS PROTECTED BOOT-PROMS

  5. BOOTING DOS

  6. BOOTING LINUX

  7. ETHERNET AND ITS PROTOCOLS

  8. BOOTP/TFTP

  9. NFS

  10. TELNET/RLOGIN

  11. THE X WINDOW SYSTEM

  12. CONCLUSION



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn


  This documentation has been written  and is copyrighted 1997 by Markus
  Gutschke <gutschk@math.uni-muenster.de>.  You  are free to  distribute
  this file as long  as you do  not  change its contents.   I appreciate
  comments and will consider them in  future revisions.  If you have any
  questions, comments, or suggestions, please also send carbon copies of
  your  e-mail message to  both  Ken Yap <ken_yap@users.sourceforge.net>
  and Gero Kuhlmann <gero@gkminix.han.de>.  I will  happily include  any
  of your extensions,  but I would like to  avoid the proliferation of
  different incompatible revisions  of  this document.  If these
  conditions are a problem to you, then feel free to contact me.


  22..  SSCCOOPPEE OOFF TTHHIISS TTEEXXTT


  Any computer that  is either physically  accessible or can remotely be
  contacted over  a  network is  potentially  threatened by attempts  to
  circumvent its security  measures.  The PC architecture is  especially
  insecure and  using a BOOT-Prom can  help preventing some  of the more
  obvious attacks. On the other hand,  it also enables some attacks that
  are not possible against  machines that boot  from local  mass storage
  devices (floppy,  harddisk, ...).  As  a general rule, you  can assume
  that it is impossible to    protect your system from all   conceivable
  attacks, but you can  try to minimize the  chance of an attack, try to
  minimize  the seriousness  of the damage   caused and try   to help in
  detecting   attacks  at  the  earliest   possible moment.   This  text
  discusses some of the issues involved  and tries to raise awareness of
  security problems; it cannot provide generic solutions to all of these
  problems, but  should  help you in appreciating   the need  for proper
  administration and regular security updates.


  33..  PPCC AARRCCHHIITTEECCTTUURREE


  The PC architecture was never designed with security considerations in
  mind.  Running an operating system such  as DOS or Windows, allows the
  user full  control over the hardware.  There are no effective measures
  for preventing him from modifying  data on local mass storage devices,
  reading confidential  data that is  stored locally,  installing trojan
  horses  and programs  that  intercept user  input, monitoring all data
  packets that are sent on the  local ethernet segment, sending ethernet
  packages with  faked  authorization information,  and  a whole  lot of
  other potentially dangerous actions.



  Modern operating systems  and suitable hardware  extensions make these
  attacks more  difficult, but  as long as   the user can   still launch
  arbitrary programs  that have full hardware access,  there is not much
  protection  that  can be  achieved in this  way.   Therefore, the most
  important security measures  are  those that prevent a  malicious user
  from executing programs from arbitrary external sources.



  The PC  must  be physically  protected, so  that  there is  no  way of
  replacing  the harddrive  (either  for  reading  its contents  or  for
  installing compromised software), installing   a modified system  BIOS
  (if your system  has a Flash  BIOS, then make sure  that it  is always
  write protected and that write protection actually works!), connecting
  it   to  a different  network,  removing   extra hardware  that offers
  security features, or performing some other hardware modification.



  If the PC offers exchangeable mass storage devices (floppy, ZIP drive,
  CD-ROM,  ...), the system must be  configured to never boot from these
  devices.



  This is not as easy as it might  sound.  Most motherboards come with a
  system BIOS which offers  back-doors to their password. So configuring
  the BIOS to never boot from exchangeable devices, will not prevent any
  determined hacker from   modifying  this setting.  These   generically
  accepted passwords might not be  known to your  average users, but you
  can assume that even  a poorly informed  hacker will know about  them.
  Besides, if your  system allows for  reading the contents of  the CMOS
  memory chip (e.g. by starting a suitable DOS program such the debugger
  which  ships with  DOS), then the  password  can be computed from this
  data. While you should  still make sure,  that your BIOS  has password
  protection, this is only to be considered as a mild deterrent.



  A  more useful protection  is  achieved by installing extra  firmware,
  which requires  a password before booting from  a  local device.  This
  firmware  should  be written in a  way  which prevents the system BIOS
  from   disabling   it.  This is    the default  configuration  for the
  "etherboot" BOOT-Prom, but it   might still be circumvented,   if your
  system BIOS  allows   for disabling  certain  memory  areas from being
  scanned for ROMs.   If this is the case,  then complain to your system
  vendor and replace  the machine; it is  unsuitable for being used in a
  publically  accessible   place.     Also, in   a   security  conscious
  environment, there must be no way of  escaping from the control of the
  BOOT-Prom;  this   means,     that  you    must     not enable     the
  "-DEMERGENCYDISKBOOT" option  when compiling the  "etherboot" software
  and you must  never offer an empty image  name in the image menu (c.f.
  README.VendorTags).  If you want to offer booting from a local device,
  then specify the full  device name  and  either enable  the "-DFLOPPY"
  option or  store a boot image  (as  generated by "mknbi-blkdev") under
  this name on the TFTP server.



  It might  be a  good  idea to  install non-functional bootcode  in the
  master  boot record of your harddisk  and install any locally required
  boot code  in   the boot sectors of   the  individual partitions. Both
  "etherboot" and "mknbi-blkdev" know how  to boot from partitions  such
  as  "/dev/hda1" (first primary partion)  or "/dev/hdb5" (first logical
  partion on the second harddrive).



  If you have the choice, then do not offer operating systems which come
  without   effective   password  protection   and  virtualization. This
  basically rules out all of the following: DOS, Windows, Win95, ...



  You  should  be  aware of  the  fact,  that offering  one  "dangerous"
  operating system,  makes all other    operating systems vulnerable  as
  well.  A  noteworthy example is  the availability of tools which allow
  an arbitrary DOS  user  to read and   modify the contents  of a  Linux
  harddisk  partition   (similar  tools  are  supposedly  available  for
  accessing NT partions).


  44..  PPAASSSSWWOORRDDSS PPRROOTTEECCTTEEDD BBOOOOTT--PPRROOMMSS


  Password protected BOOT-Proms are  a considerable improvement over the
  standard security measures  offered by the  PC architecture,  but they
  are still vulnerable  to a variety  of attacks. Most of  these attacks
  are related to the weaknesses of the BOOTP and TFTP protocol and these
  issues are discussed in another section of text.



  As the BOOT-Prom cannot store the passwords locally, it has to request
  them from the BOOTP/TFTP server.  The  BOOTP and TFTP protocols do not
  allow for any elaborate  challenge/response authorization scheme. Thus
  the BOOT-Prom  requests the password from  the server and subsequently
  compares it   with the password   as  input by  the user.   As packets
  transmitted on the ethernet can  easily be monitored, the server sends
  a MD5 message  digest (as invented  by Ron  Rivest/"RSA Data Security,
  Inc.")  of the actual password.  The  BOOT-Prom computes the MD5 value
  for the user   input and compares  these two values.  It is  generally
  believed that there is no way of  computing a valid  plain text from a
  known   MD5 message digest,   other    than comparing it against   all
  conceivable  input texts.   Thus, this  approach  is still  vulnerable
  against  dictionary attacks. You should   aim for using long passwords
  (although,  anything beyond 20  characters is unlikely to considerably
  improve the security of  the  password) which are   not listed in  any
  dictionary.   Make  sure that  these passwords  are memorized  and not
  available in un-encrypted form. Replace the passwords regularly and do
  not offer  more menu  entries in the   BOOTP data than are  absolutely
  neccessary.


  55..  BBOOOOTTIINNGG DDOOSS


  If you  have to offer DOS  or a related operating  system, then do not
  fool yourself into believing that you can install security software in
  one of its configuration files. All  of these mechanisms can easily be
  avoided. In many cases,  even average users can figure  out how to  do
  this.


  66..  BBOOOOTTIINNGG LLIINNUUXX


  There are a variety  of ways that   allow for booting Linux in  single
  user mode.  The  most  common  techniques involve passing   a suitable
  option  on  the kernel command line  (i.e.   "single") or crashing the
  filesystem by  power cycling the machine; this  in turn will result in
  fsck being invoked at the next system start, which will sometimes drop
  you into single user mode.



  Some Linux distributions   do  not require  a password  when  entering
  single user  mode.  While  this makes system   administration somewhat
  easier, it  is a considerable security problem.  Make  sure, that your
  system does not suffer from it.



  For other security problems with running insecure programs under Linux
  or  using poorly configured    distributions,   refer to the    Usenet
  newsgroups, security mailing lists  and  choose a distribution   whose
  manufacturer frequently releases security fixes.   It is a fallacy  to
  assume   that the unavailability of patches   implies the security and
  correctness  of  a  software  application;   as a  rule  of  thumb,  a
  manufacturer who releases more patches than  a different one, probably
  cares more about  the security of  your  system than  the latter. This
  also applies to operating systems other than Linux!


  77..  EETTHHEERRNNEETT AANNDD IITTSS PPRROOTTOOCCOOLLSS


  The ethernet is extremly  vulnerable to attacks from malicious  users.
  Anybody who can gain direct access to an  ethernet segment, can easily
  monitor all traffic  and inject forged  data.  This is very dangerous,
  because many protocols transfer  data either  un-encoded or in  easily
  decipherable form.   Also,   authorization  is  often  based   on  the
  assumption that the return address or a session id can be trusted, but
  this is no longer true if users gain unlimited access to the ethernet;
  it does not    really matter if  this  access  is achieved  by  having
  physical control over part of the  network or by running a compromised
  or inherently insecure  operating  system.  There are  various attacks
  from  machines  that  are not  directly  connected   to your  ethernet
  segment, but the majority  of them can be  prevented by installing and
  maintaining a properly configured firewall.  For more information, you
  should regularly monitor security related newsgroups and mailinglists.





  88..  BBOOOOTTPP//TTFFTTPP


  BOOTP  and TFTP offer almost   no security whatsoever. They  basically
  provide their information  to anybody who asks and  solely rely on the
  assumption that  your  network is configured to   not  make the server
  world-accessable. If you install  BOOTP gateways, then this assumption
  is  seriously violated. Also, TFTP server  are usually accessible from
  just  about everywhere.  You  can try  to dimish  the  impact  of this
  problem by blocking  BOOTP and  TFTP packes  from leaving or  entering
  your network segment,  but this  will never   be  a completely  secure
  solution.



  Thus you should always assume  that all of the  files that your  BOOTP
  and TFTP server offer  are world readable. They  must not  contain any
  sensitive data.    Also, the TFTP daemon  must   be configured to only
  allow access to selected files.   Running it in a chroot'd environment
  might be a very good idea.



  The BOOTP protocol is  vulnerable against somebody else  impersonating
  as  a  BOOTP server. While   security aware operating systems, prevent
  non-priviledged  users  from starting their   own BOOTP servers, other
  operating systems do not allow this. This means, if  any of your users
  can launch an arbitrary program  under an insecure operating system on
  an arbitrary  machine connected  to your  ethernet segment,  then they
  have full control over the BOOTP boot process.


  99..  NNFFSS


  While NFS  is  very convenient  for  installing diskless  machines, it
  provides  almost no  security.  Data  is transmitted  unencrypted  and
  authorization is solely based on the identity of IP addresses. Anybody
  who can forge ethernet packets, has full  access over any data that is
  available via  NFS.  While there  are protocol  extension that try  to
  address these shortcomings, I  am not aware  of any solution for Linux
  based   machines. This means, you   have to  assume  that all exported
  filesystems are freely read-  and  writeable. Bear  this in  mind when
  deciding which data you intend to export.


  1100..  TTEELLNNEETT//RRLLOOGGIINN


  Telnet and rlogin do not  usually  come with any effective  protection
  other than  simple password  schemes. Data  and  even the  password is
  transmitted as plain text. There are  commonly available programs that
  constantly  monitor     the   network for   packets   that    contains
  passwords. Fortunately, the security of these  protocols can be vastly
  improved  by  replacing   them   with   the Secure  Shell    protocoll
  (http://www.cs.hut.fi/ssh). Preferably,  all telnet and rlogin servers
  and clients should be removed from all machines.


  1111..  TTHHEE XX WWIINNDDOOWW SSYYSSTTEEMM


  X provides some security when run over a network, but  the scope of it
  is limited and exploits can easily be  devised. At the very least, you
  should make sure that  the xauth  protocol  is used as opposed  to the
  vastly  inferior xhost  protocol.  A better   solution is  provided by
  routing all X connections through  a  secure shell session. This  does
  not only provide  more  reliable authentication, but it  also encrypts
  all data.


  1122..  CCOONNCCLLUUSSIIOONN


  While  this text cannot  do more than  barely scratch  the surface, it
  should help you in locating some of the more vulnerable sub-systems of
  your networks and your  computers.  It does  not aim for completeness,
  but if you think that there is a topic which should be mentioned or if
  you want to update an entry, then please to contact me.





















































