14

It seems to me that to maximise server security, one ought - in addition to the usual security measures implemented in software - to prevent the overwriting of certain parts of the server system, such that only physical access will circumvent this write-protection.

Rationale

If a remote attacker who has been successful enough to gain arbitrary code execution privileges can modify the following, then that server is significantly less secure than it would be if such an attacker could not modify them:

This is a defence in depth rationale.

Questions

My questions are as follows:

BIOS

Is it possible to write-protect BIOS chips at the hardware level, e.g. with a device having a similar form-factor to a BIOS Savior but instead possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the BIOS? (NB: The NSA's "ANT division [has] a clear preference for planting their malicious code [in] BIOS.")

CPU

Similarly, is it possible to write-protect processors at the hardware level, e.g. with a device having a similar form-factor, mutatis mutandis, to that described above for the BIOS, i.e. sitting physically between the CPU socket on the motherboard and, the CPU itself, and again possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the CPU's firmware?

Operating system storage

It is already possible to write-protect the storage medium containing the operating system installation at the hardware level by utilising a read-only optical drive for that storage (e.g. CD-ROM, DVD-ROM, etc). Other options would include write-protected USB flash drives, or forensic USB write-blockers installed between the USB port and the drive containing the OS.

Even though Live CDs are often used for testing or experimentation, this does not seem to be common practice in deployment. Perhaps this is because sysadmins would prefer not to have to gain physical access to every server for every OS update, even if it would just be a matter of replacing a DVD-ROM and rebooting; but I do not share that preference: to me, security is more important.

  • Are there any server OSes/distros designed to support this sort of configuration out of the box?
  • Are there any information resources (books, websites) dedicated to deploying and maintaining servers in this fashion?
sampablokuper
  • 1,961
  • 1
  • 19
  • 33
  • 4
    CPU microcode cannot be changed permanently; updates must be done by the BIOS or by the OS at each boot. – CL. Dec 09 '13 at 09:42
  • @CL. Can you elaborate on that (e.g. provide a link)? Thanks! – sampablokuper Dec 09 '13 at 11:53
  • 3
    [Intel Architecture](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html) Volume 3, section 9.11.6.1: "The effects of a loaded update are cleared from the processor upon a hard reset." – CL. Dec 09 '13 at 12:55
  • Some relevant discussions: [1](http://whatis.techtarget.com/definition/BIOS-attack) [2](http://www.theregister.co.uk/2011/09/14/bios_rootkit_discovered/) [3](http://www.velocityreviews.com/forums/t404399-preventing-bios-flash-reflashing-permanently.html) [4](http://threatpost.com/nist-offers-guidelines-securing-bios-082412) – sampablokuper Dec 14 '13 at 00:05
  • [5](http://security.stackexchange.com/a/7213/10198) – sampablokuper Dec 14 '13 at 00:38
  • [6](http://electronics.stackexchange.com/q/43396/2023) – sampablokuper Dec 14 '13 at 20:59
  • @sampablokuper None of those attacks you linked had to do with microcode. – forest Dec 27 '17 at 07:35
  • @forest, did I claim that they, specifically, *were* to do with microcode? If so, please point me to where I did so, and I will amend my statement if it was incorrect. Thanks. – sampablokuper Dec 27 '17 at 17:16
  • @sampablokuper I thought that's what you were saying, my bad. – forest Dec 28 '17 at 03:20
  • RISC-V does this for the register `x0` to reserve it as a source of 0. – John D Mar 04 '21 at 20:25

2 Answers2

12

Quis custodiet ipsos custodes?

Before I begin, I'd like to explain a bit about the term trust as it is used in an information security context. In infosec, trust often has the opposite meaning of what would seem logical. You want less trust. An untrusted component of a system is good, and the more untrusted components, the better. Trust means reliance. If you trust a component, you rely upon it to be honest, correctly implemented, and secure. If you do not trust a component, it means even compromise or malice will not allow it to do harm to you. In a secure computer, the Trusted Computing Base (TCB) is the sum of trusted code on any given system. The smaller the TCB, the better.

This brings us to the question, who watches the watchmen? In infosec, the highest watchmen are the TCB. The fewer there are, the safer the system. While it is impossible to completely solve this issue, one common effective solution is to implement trust in hardware, which is much harder to tamper with than software. Hardware verifies a small amount of software. This small software verifies larger software, and on and on. This is explained later in this post.

Answering your questions

Is it possible to write-protect BIOS chips at the hardware level, e.g. with a device having a similar form-factor to a BIOS Savior but instead possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the BIOS?

Some older systems required jumpers to be set in order to write to the BIOS. Now days, it's almost always in software. You would want to use a modern computer that supports BootGuard in order to mitigate this. BootGuard runs in the CPU before the BIOS even loads and verifies a digital signature in the BIOS to ensure it has not been tampered with. Boot will only resume if the signature is valid.

Similarly, is it possible to write-protect processors at the hardware level, e.g. with a device having a similar form-factor, mutatis mutandis, to that described above for the BIOS, i.e. sitting physically between the CPU socket on the motherboard and, the CPU itself, and again possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the CPU's firmware?

CPUs do not have firmware. In fact, they have no permanent storage at all. Intel even has a "statement of volatility" in many of their documents, essentially saying that a second-hand CPU will not contain any personal information or permanent changes from its previous owner. For example, from the Xeon E5 v4 datasheet, section 1.1.4 contains the following:

1.1.4   Statement of Volatility (SOV)

        The Intel® Xeon® Processor E5 v4 Product Family does not retain any
        end-user data when powered down and / or the processor is physically
        removed from the socket.

Technically, CPUs do have a small amount of permanent storage called OTP (One-Time-Programmable) fuses, but they are used for permanently changing some basic settings, such as whether or not BootGuard is active. It does not contain anything executable.

You are probably thinking of microcode. Microcode is a way that CPUs can modify the behavior of certain instructions by routing through a microcode table. This is used to fix buggy instructions or even disable them completely. However, it's not built into the CPU, and can only be loaded at runtime. Once a CPU resets, microcode is lost. There are two main ways a CPU can load microcode:

  • The BIOS, which often contains microcode from the time of manufacture.
  • Software, which downloads the latest microcode and inserts it.

Microcode is verified using a signing key known only to Intel. To insert malicious microcode, one would have to be in the position to both get you to run it, and to obtain Intel's signing key.

Are there any server OSes/distros designed to support this sort of configuration out of the box?

Tails is specifically designed to do this. It is an amnesic live system that keeps data only in memory. It uses a special type of filesystem called a union to fuse two other filesystems. Specifically, it fuses the read-only squashfs, present on a USB stick or DVD, and an in-memory tmpfs. Any changes to the union filesystem are written to tmpfs. This provides the illusion of one, large, writable filesystem, when in reality there is only one that is never-changing and another that exists only in memory.

Are there any information resources (books, websites) dedicated to deploying and maintaining servers in this fashion?

You may want to look into diskless servers. These are common in clustering and boot over the network. All data they have, unless saved over the network, is lost on reboot.

Other hardware that can be modified

The list of hardware you provided is not exhaustive. There is plenty more on a modern motherboard that can be modified, for example:

  • Both HDDs and SSDs have writable firmware powering their microcontrollers.
  • Option ROMs are present in nearly every PCI device and are executed by the BIOS.
  • GPU firmware is usually not writable over software, but it is not write-protected.

There is more, and unless you have a way to verify your boot process, trying to write-protect everything will be a cat-and-mouse game.

Measured boot

With some effort, even using software (on modern hardware) alone, you may still be able to verify the integrity of your hardware, sharply reducing the number of components you have to trust. It is even possible to do this remotely for a computer you do not have physical access to! This is called remote attestation. Usually, this is done using the TPM.

The TPM is a small hardware component (though often emulated in firmware in newer processors) which is designed to be tamper resistant and secure. It has minimal functionality, and can only do a few things. Primarily, it is used to combine the hashes of various components of the system, and they will unlock (unseal) themselves when the hashes match a known value. Various pieces of software send copies of parts of the system to the TPM to be hashed. As a result, the TPM's hashes will change if any component of the system changes. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system is untrusted.

A TPM verifies several different components of the system and stores in it PCRs. Each PCR has a different purpose, and verifies a different part of the system (taken from another post):

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all command-line arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used for SRTM

An important thing to remember is that the TPM cannot act on any detected tampering. In fact it is fundamentally not able to, being positioned on the LPC bus. All it can do is verify that the hardware is in a sane state, and refuse to unseal itself otherwise. The sealed data could include a disk encryption key (ensuring the system will not boot if the system has been tampered with), or a secret known only to you and not guessable (and thus not spoofable) by attackers, such as a string. This is how Anti-Evil Maid, or AEM from ITL works, although note that the latest version uses DRTM ("late launch"), not SRTM.

The end of this process is that you have reduced the TCB for your entire system down to the small, read-only CRTM, and the secure TPM chip itself.

Resources / pointers

Since you asked for some resources, I would look into the following things for improving improving the security (reducing the trusted computing base) of a COTS workstation:

  • Measured boot
  • Remote attestation
  • Trusted Platform Module (TPM)
  • Static Root-of-Trust for Measurement (SRTM)
  • Dynamic Root-of-Trust for Measurement (DRTM)

Some other questions that may be relevant and could help you understand this process:

TL;DR

Write protection is a game of cat-and-mouse. The only practical solution is to use measured boot.

forest
  • 64,616
  • 20
  • 206
  • 257
7

BIOS

Most memory chips I've worked with have a W or R/W pin which selects the write mode. Physically tying that one to appropriate logical level should do the trick.

Write-protected USB drives

I'm a bit suspicious about this one. I've implemented microcontroller<->SD card interface, and the "write-protect" bit is handled completely in software, so you have to trust some part of your computer to not be able to write there. I do not know if the USB flash drives are the same in this regard, but this is something to keep in mind - hardware switch might still have software protection.

domen
  • 1,040
  • 10
  • 21
  • Thanks. The link in my question is to a discussion of USB write-protection. – sampablokuper Dec 09 '13 at 11:51
  • Do you know of any resources with more information about the viability of write-protecting common BIOS chips in the way you've described? – sampablokuper Dec 09 '13 at 12:39
  • It's hard to be specific, and it's been a decade since I've dealt with BIOS chips. It depends from chip to chip. An example of what might be used: MT28F640J3. If you check the datasheet, you see it has WE# signal. The simplest way to prevent writing to this would be to just disconnect the pin from motherboard (possibly with pull-up to Vcc). – domen Dec 09 '13 at 13:11
  • And that discussion looks good. I shouldn't have said "USB drives", since USB is just one way of interfacing SD cards. "USB blockers" could be tricky, since there are multiple standard ways to transfer files to USB devices. Then there's transferal of other data, and then the all non-standard ways. – domen Dec 09 '13 at 13:16
  • Some memory chips are read out by feeding the address on one set of pins and reading data on another. Some other memory chips, however, use a "set address" command followed by a "read data at last address" command. Write-protection is more complicated with chips of the latter style than with chips of the former. – supercat Feb 02 '14 at 23:00
  • @supercat USB uses the latter style which you mentioned, and that's exactly why it's usually implemented in software. Doing it in hardware (or firmware) would require a lot more changes to the microcontroller, and would be subject to vulnerabilities. – forest Dec 07 '17 at 10:39