12

I understand that it is possible for a code to be crafted for a given hardware/firmware to inject a virus that would not be removed by a wipe of the hard disk. Video card, and BIOS are examples of a possible destination for this type of badware to be stored.

But does the Raspberry Pi possess this possible vulnerability? Assuming that there was no physical tampering, is it safe to assume that when the SD card is replaced, the device is clean?

There’s no BIOS per se, but we do support booting bare metal code...

There's no RTC. There is hardly anything except the basics. On the other hand, there is included a GPU/video capability.

So this question comes to my mind, and I wonder if anyone has the answer.

AviD
  • 72,138
  • 22
  • 136
  • 218
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • I think there are no known attacks yet, but that obviously does not make it impossible. – Lucas Kauffman Aug 08 '12 at 18:29
  • @Lucas, That is right, but I was just submitting the possibility that this simple hardware may not have been built with write capability for the various firmwares. If there are no write circuits, then in theory there would be no attack vector in that area. – 700 Software Aug 08 '12 at 19:46

4 Answers4

17

The BCM2835 application processor that we use has no persistent storage on board, so an attack of the sort you describe isn't possible. The zero-stage bootloader is stored in real, honest-to-god ROM on the chip, and so can't be overwritten.

Eben Upton
  • 171
  • 1
  • 2
15

In principle, you could modify the SoC (System on Chip)'s firmware (e.g., the simple bootloader that initially tells the chip to read the SD card to get the real firmware image to boot up) by uploading new malicious firmware which would persist after replacing the SD card.

However, I am not sure if the Raspberry Pi's SoC firmware is (easily) modifiable. I believe it is pre-programmed from factory and may not be rewritable; though a sophisticated attacker could always replace the chip with one maliciously factory-programmed.

There is firmware on the SOC that you will not be able to touch. It is pre-programed from the factory. And yes it is required to boot, and this is why the first partition has to be FAT because this is how the firmware is designed. You only need a FAT partition big enough to hold a bootloader of some type.

Also from http://elinux.org/RPi_Software:

The boards do not include NAND or NOR storage - everything is on the SD card, which has a FAT32 partition with GPU firmware and a kernel image, and an EXT2 partition with the rootfs.

We're not currently using a bootloader - we actually boot via the GPU, which contains a proprietary RISC core (wacky architecture). The GPU mounts the SD card, loads GPU firmware and brings up display/video/3d, loads a kernel image, resets the SD card host and starts the ARM. You could replace the kernel image with a bootloader image, and that would work fine.

Implying that there is some simple code in the SoC that on boot mounts the SD card and reads the firmware, that in principle, could be replaced with malicious code. Though this may require physically replacing the chip with something created in a chip factory that initially loaded malicious code.

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • Thanks for what you have posted. That is the gray and blurry part, is that I was hoping to find out whether physical contact would be required to pull off this attack... – 700 Software Aug 08 '12 at 19:44
  • 3
    I'm almost sure that the bootrom (the first stage bootloader) is in mask ROM but I can't find the reference now. If this is indeed the case then it is electrically not possible to modify it. – resistor Aug 09 '12 at 00:58
  • 1
    As mentioned in the comments on Eben's 2012 answer below, this changed on the Raspberry Pi 4 and it now "has an SPI-attached EEPROM (4MBits/512KB), which contains code to boot up the system and replaces bootcode.bin previously found in the boot partition of the SD card." — [source](https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md) – natevw May 11 '21 at 22:03
2

I can't answer specifically to the Raspberry PI but I will refer to this article. According to that it is possible to write malicious code that wouldn't be cleaned via "typical" procedures.

Due to the efforts of programmers that have contributed to those projects, Rakshasa works on 230 different models of motherboard..

Digital fire
  • 3,126
  • 5
  • 31
  • 44
  • 2
    Interesting. I will point out it says Rakshasa *"replaces a computer's BIOS"* (On Raspberry Pi, there is no BIOS), *"but can also infect the PCI firmware of other peripheral devices like network cards or CD-ROMs"* (On the Pi there is a network unit, and there could be other USB attached peripherals like mouse/keyboard/camera, etc). – 700 Software Aug 08 '12 at 19:16
  • 1
    Rakshasa is specific to PCs, as far as I know. The same concept would apply to an ARM platform, but something like Rakshasa requires significant platform-specific development. The real question is here is what reflashable firmware is present on the Pi. – Gilles 'SO- stop being evil' Sep 17 '12 at 16:09
1

IIRC, the Pi only has 2 chips; one for cpu/memory/video, one for USB and LAN. If neither of these support writing, then that's pretty much the end of it.

However, it's worth pointing out that there isn't a single hardware configuration for the Pi -- different iterations have used different suppliers and models for these chips. So theoretically the answer could depend on which revision you get. You'd have to check the datasheet for your specific chip.

Here's a list of revisions for this hardware with the assoicated model numbers for the two chips:

RaspberryPi Boards

tylerl
  • 82,225
  • 25
  • 148
  • 226