Hacker News Reader

Comment by joshuapants | Hacker News Reader

Good thing they weren't complacent and they had the drive checked. It's appalling that this came from a police department, but it could happen with any drive someone gives you, accidentally or maliciously.

What's the best way to counteract this? Only plug foreign drives into a dedicated computer, probably running Linux, so you can scan it and copy the files you need before letting them touch other machines?

View on HN

Linux isn't necessarily immune to USB malware. There are a lot of drivers for USB devices in Linux and any of them could have a bug. For example people only recently started doing fuzzing on filesystem drivers.

Absolutely. You want something ephemeral - meaning software AND hardware you can nuke. And even that isn't 100%.

What's demonstrated in this article is extremely inelegant and clumsy. Truly malicious rootkits and the like are a bit more sophisticated.

Nowadays I check any drive that's been out of my house, after my spouse brought a virus home from her workplace. A dedicated Linux box, a quick booting distro on a trusted flash drive, or even a Raspberry Pi can be used for this purpose.

I would second the Raspberry Pi, it would be more or less immune to malware that targets x86 land, even Linux based malware. Still, I'd not have it connected to the network and I would wipe the Pi's SD card afterward, just to be sure. Scripts can run on any architecture.

The Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected.

In that case, you might be better off using a MIPS based device (old router, maybe?), since ARM is gaining popularity.

From what I've heard recently, targetting ARM may be problematic because two ARM processors may not support the same features, or function the same way. Then again, maybe there's a low-end subset of ARM instructions that should work an any chip, similar to the instruction set for the i386?

The Arm specification primarily focuses on the protected mode opcodes used by applications. This is why Arm application binaries are portable across machines.

The real mode opcodes needed to bring up a kernel are a mess on Arm, with each manufacture using their own instruction set.

This explanation is garbled. The opcodes are not fundamentally different (although more are added from ARMv6 to ARMv7 e.g. the Pi 1 to Pi 2 transition), and there isn't the X86 different set of "real mode" opcodes.

What is different is the boot sequence and system register layout. On a PC you can write one bootloader that works across multiple systems because either the peripherals are at the same place or BIOS/UEFI code is provided to sort it out for you. This is not the case on ARM; uboot and devicetree are attempts to fix it.

You can feature detect at runtime. And or pick a subset. It is complicated but workable.

The Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected.

It might be possible for a malicious script that gains root access to replace the SD card firmware with something that looks clean on the Pi, but delivers malware when some conditions are met.

You can always boot from a ROM/7400 board with no writeback capability, although that's a bit of a pain to set up.

Yep, which is why I said "I would wipe the Pi's SD card afterward, just to be sure. Scripts can run on any architecture."

The SD card is not part of the RPi; there's nothing on the board itself that is writable.

Wiping the SD card using standard disk tools would not affect the SD card's firmware. SD cards are not dumb storage devices; they have built-in CPUs that handle DRM, protocol interfacing, and wear leveling, possibly among other things. That CPU has its own firmware, which might be reprogrammable by an attacker that knows the right commands to send.

Fair enough, I didn't think about that. I guess if you were using a RPi for a quarantine job like this, you would consider the SD cards as one time use devices and destroy them after use. The RPi itself shouldn't be affected though.

Raspberry Pi does make a lot of sense. It's cheap enough, small, and doesn't consume much power so it's easy to have one around for this purpose.

Since I got a couple of RPi's for fun, I've been thinking of uses for them, that would augment the security of my regular Windows PCs. I've set up a file backup method, where the RPi "pulls" files from my PC via my home network, but does not grant the PC read or write access. This is all just garden variety Linux commands, mounting the Windows share, and copying files from it. I think that my method is immune to "ransom ware" attacks. To cloak itself, the ransom-ware has to decrypt files when they are fetched, until it decides to lock you out.

Disabling AutoPlay and any other "automatically run a program when media is inserted" feature would be a good first step. Not running executable files (Windows users: unhide those file extensions!) that have no reason to be executable, and using AV software (or multiple, like those online services) to scan the files you are interested in is also a good idea.

If you're really paranoid, do everything with a separate machine.

People have put little nano atmel's in usb drive cases that have emulated a virtual keyboard. Sending ~a few strokes could open command, download, and run an executable.

Reply on news.ycombinator.com