<HTML ><HEAD ><TITLE >PC ARCHITECTURE</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" HREF="t1.html"><LINK REL="UP" TITLE="Security, 1 July 1997" HREF="a784.html"><LINK REL="PREVIOUS" TITLE="SCOPE OF THIS TEXT" HREF="x792.html"><LINK REL="NEXT" TITLE="PASSWORDS PROTECTED BOOT-PROMS" HREF="x806.html"></HEAD ><BODY CLASS="sect1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" ></TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="x792.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" >C. Security, 1 July 1997</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="x806.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="sect1" ><H1 CLASS="sect1" ><A NAME="AEN795" ></A >PC ARCHITECTURE</H1 ><P > 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. </P ><P > 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. </P ><P > 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. </P ><P > If the PC offers exchangeable mass storage devices (floppy, ZIP drive, CD-ROM, ...), the system must be configured to never boot from these devices. </P ><P > 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. </P ><P > 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. </P ><P > 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). </P ><P > 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, ... </P ><P > 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). </P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="x792.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="t1.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="x806.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >SCOPE OF THIS TEXT</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="a784.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >PASSWORDS PROTECTED BOOT-PROMS</TD ></TR ></TABLE ></DIV ></BODY ></HTML >
