13

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.

Improve this question
2
  • I think there are no known attacks yet, but that obviously does not make it impossible.
    – Lucas Kauffman
    Aug 8, 2012 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 8, 2012 at 19:46

4 Answers 4

Reset to default
16

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.

Improve this answer
3
  • 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 8, 2012 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 9, 2012 at 0: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
    – natevw
    May 11, 2021 at 22:03
18

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.

Improve this answer
3
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..

Improve this answer
2
  • 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 8, 2012 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, 2012 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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .