Media Write Protection / Crypto Devices / BadUSB - #OpenFabs #OpenHW
This is the use case for Tails. . . . [T]here are no writes to storage, unless users configure [otherwise] . . . .
Sure, but this isn't a _Tor_ issue. It's just about Tor browser, which is just (heavily) modified Firefox. And although I'm no software expert, I'm guessing that it's impossible to guarantee what some code will or won't leave behind when it crashes. Even if you tweaked the browser to never write temp files to disk, and keep everything in RAM, you couldn't guarantee that the OS won't write stuff to disk.
That is, unless there _is_ no disk, as in Tails. Even with Whonix, traces likely remain in the virtual disk.
There is never "no" disk, just a matter of which ones are plugged into the box, physically, or remotely. Only old SCSI, optical, some floppy / tape mediums had functional hardware write protect. Even burnables could conceivably have more bits burnt, or burnt down, later. USB and SD are software honor system write protect. Most people don't even know they can disable swap and keep system mounted read-only, that's basic. Uid 0 can write to all firmware and user areas on all media. Some flash chips and controllers can be soldered / cut per docs to enable write protect lines. No media lasts forever, is bug free, or bitrot proof. Kanguru does make a hardware write protect USB series. Transcend Jetflash, PQI, and others might. Some claim to offer additional protections such as signed firmware loads, etc. Any firmwares involved may or may not be protected against BadUSB... ask them how their write protect etc works... if you're brave / dumb enough to believe their non #OpenFabs , non #OpenHW marketing lies about it. Same goes for any claims about integrated AES encryption hardware, PKI sticks, crypto key modules, hardware enclaves, and all other backdoored junk you can't see, etc. Including from the likes of Intel, Apple, Trezor... Even from opensource OS that refuse to implement block storage opcode command filtering to help prevent at least some user level propagation common with shared / public systems. https://www.kanguru.com/ https://www.youtube.com/watch?v=nuruzFqMgIw https://www.youtube.com/watch?v=xcsxeJz3blI https://adamcaudill.com/2014/10/02/making-badusb-work-for-you-derbycon/ " Blaze speculates that the USB attack may in fact already be common practice for the NSA. He points to a spying device known as Cottonmouth, revealed earlier this year in the leaks of Edward Snowden. The device, which hid in a USB peripheral plug, was advertised in a collection of NSA internal documents as surreptitiously installing malware on a target’s machine. The exact mechanism for that USB attack wasn’t described. “I wouldn’t be surprised if some of the things [Nohl and Lell] discovered are what we heard about in the NSA catalogue.” The alternative is to treat USB devices like hypodermic needles. Nohl says he and Lell reached out to a Taiwanese USB device maker, whom he declines to name, and warned the company about their BadUSB research. Over a series of emails, the company [Phison] *repeatedly denied* that the attack was possible. " Remember, BadUSB porn got Bin Laden :) ... maybe. Rubber up your duckies, check hashes, backup, be insane! #OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz When will you ever learn... it's not that hard. Cc the biased and censored metzdowd list because... https://www.youtube.com/watch?v=tQQFA9YXCZ0 ;)
On 10/12/2018 11:56 PM, grarpamp wrote:
This is the use case for Tails. . . . [T]here are no writes to storage, unless users configure [otherwise] . . . .
Sure, but this isn't a _Tor_ issue. It's just about Tor browser, which is just (heavily) modified Firefox. And although I'm no software expert, I'm guessing that it's impossible to guarantee what some code will or won't leave behind when it crashes. Even if you tweaked the browser to never write temp files to disk, and keep everything in RAM, you couldn't guarantee that the OS won't write stuff to disk.
That is, unless there _is_ no disk, as in Tails. Even with Whonix, traces likely remain in the virtual disk.
There is never "no" disk, just a matter of which ones are plugged into the box, physically, or remotely.
OK, I should have said "unless there _is_ no disk, as there _can be_ in Tails". I've run Tails (and my own LiveCDs) on diskless machines. And yes, using USB for live systems is iffy. But write-once CDs are pretty safe, I think. No? <SNIP>
On 10/13/2018 08:42 AM, Mirimir wrote:
There is never "no" disk, just a matter of which ones are plugged into the box, physically, or remotely.
OK, I should have said "unless there _is_ no disk, as there _can be_ in Tails". I've run Tails (and my own LiveCDs) on diskless machines. And yes, using USB for live systems is iffy. But write-once CDs are pretty safe, I think. No?
Well heck, CDs are cheap. Write once, use once, melt once. If your trust in the Live CD vendor and the "trusted" device used to burn your stack of Live OS CDs is well founded, and the device booted into has no drive (or a power switch on the drive - a very trivial hack even with a laptop), the only things left to worry about are undocumented debugging modules on the CPU, and maybe undocumented BIOS or video chip features. If your activities present a target important enough to justify use of TS/SCI techniques against you, your activities are probably important enough to justify purchasing obsolete laptops in bulk and destroying each after one use. "Fingerprint MY hardware will ya, you bastards? HA! Take that!" Just sayin'. Everything depends largely on one's threat model. Who are your potential adversaries, what are their potential resources, and what's their cost/benefit ratio for doing what it takes to crack your system? Educated guesses here establish parameters for reasonable defensive measures also based on cost/benefit factors. Spoiler: For most of the users most of the time, precautions beyond using a Live OS on a stick don't make much sense. Always consider that the cost of using information obtained via a previously unsuspected attack vector includes a risk of exposing that vector's existence. Parallel construction covers a multitude of sins but not all of them, all of the time. :o)
On Sat, Oct 13, 2018 at 08:35:09PM -0400, Steve Kinney wrote:
On 10/13/2018 08:42 AM, Mirimir wrote:
There is never "no" disk, just a matter of which ones are plugged into the box, physically, or remotely.
OK, I should have said "unless there _is_ no disk, as there _can be_ in Tails". I've run Tails (and my own LiveCDs) on diskless machines. And yes, using USB for live systems is iffy. But write-once CDs are pretty safe, I think. No?
Well heck, CDs are cheap. Write once, use once, melt once. If your trust in the Live CD vendor and the "trusted" device used to burn your stack of Live OS CDs is well founded, and the device booted into has no drive (or a power switch on the drive - a very trivial hack even with a laptop), the only things left to worry about are undocumented debugging modules on the CPU, and maybe undocumented BIOS or video chip features.
If your activities present a target important enough to justify use of TS/SCI techniques against you, your activities are probably important enough to justify purchasing obsolete laptops in bulk and destroying each after one use. "Fingerprint MY hardware will ya, you bastards? HA! Take that!" Just sayin'.
Indeed. Chameleon HW ftw I guess - #OpenHW #OpenFabs Parameterizable everything - as in, every parameter which can be used to identify say a network device and any anomalies it might otherwise present to the world (clock skew, obvious MAC addy, any software/bios built into the network chip "hardware" and its parameters) and of course up the stack.
Everything depends largely on one's threat model. Who are your potential adversaries, what are their potential resources, and what's their cost/benefit ratio for doing what it takes to crack your system? Educated guesses here establish parameters for reasonable defensive measures also based on cost/benefit factors. Spoiler: For most of the users most of the time, precautions beyond using a Live OS on a stick don't make much sense.
Ack.
Always consider that the cost of using information obtained via a previously unsuspected attack vector includes a risk of exposing that vector's existence. Parallel construction covers a multitude of sins but not all of them, all of the time.
:o)
There is never "no" disk, just a matter of which ones are plugged into the box, physically, or remotely.
using USB
... is using an attached disk, ie: a read-write [block device], that can be trivially written to by / through the kernel driver interfaces or in the raw. Unless it has a hardware write protect that is enabled.
But write-once CDs are pretty safe, I think. No?
In customary use, probably, far more than any of the formerly mentioned non hardware write protectable devices. To be sure you'd need to use it in a old drive that has no writing capability, or a writer that had its writing physically disabled. Yet there's probably not really a thing as hardware write once optical... There's a spinning layer of stuff with a laser pointing at it, and a firmware blob deciding to tell it to fire. There's no hardware write protect for the laser enable, or the firmware, and the firmware is clearly hackable and flashable by the user, hacked, or backdoor commanded system. That's enough to burn down unburnt bits on the media causing instruction / addressing / data changes, extending capacity by raw appending or extra sessions, etc. Last thing needed is laser sync into pre existing track (possibly using servo tracks) for the burn down / append / additional sessions. Totally forget all of little about the media and laser controller there so you'd have to research what the laser servo mech uses to do something useful. Under attack, optical is probably not as "write once" as people might think, let alone as random / corruptive scribble proof. Exploiting optical would be worth a big pile of Defcon / CCC lulz for anyone who can demo a POC of it. Explore it :)
On 10/13/2018 10:50 PM, grarpamp wrote: <SNIP>
But write-once CDs are pretty safe, I think. No?
In customary use, probably, far more than any of the formerly mentioned non hardware write protectable devices.
To be sure you'd need to use it in a old drive that has no writing capability, or a writer that had its writing physically disabled.
Yeah, good point. But hey, they're probably about free on eBay.
Yet there's probably not really a thing as hardware write once optical...
Right. I'd forgotten about multisession recording on CD-R:[0] | With multisession-capable recording software, you can reuse | a partially used CD-R by creating a new session on the remaining | blank space of the disc. When you do so, however, the previous | sessions become inaccessible. Only the last session on the disc | can be read. This might be useful if you back up a small number | of files every day and you don’t need the previous day’s backups | after you have made today’s copy. You could use the same CD | several times and always have access to the most recent copies. That in itself wouldn't be very useful for a system running from the CD-R, because it would nuke itself by doing multisession recording. But ...
There's a spinning layer of stuff with a laser pointing at it, and a firmware blob deciding to tell it to fire. There's no hardware write protect for the laser enable, or the firmware, and the firmware is clearly hackable and flashable by the user, hacked, or backdoor commanded system. That's enough to burn down unburnt bits on the media causing instruction / addressing / data changes, extending capacity by raw appending or extra sessions, etc.
So yeah, stuff could probably be written. Maybe it'd help to use all disk capacity when writing, by appending random-data file(s) at the end of the write. But ...
Last thing needed is laser sync into pre existing track (possibly using servo tracks) for the burn down / append / additional sessions. Totally forget all of little about the media and laser controller there so you'd have to research what the laser servo mech uses to do something useful.
That's over my head. Maybe there are gaps in tracks, which could be used to store new data. Or maybe it's possible to write slightly off track, without hosing existing data. I have no clue.
Under attack, optical is probably not as "write once" as people might think, let alone as random / corruptive scribble proof.
Those are good points. So what? Paper tape, in a reader that can't punch holes? But seriously, using CD readers with wimpy lasers that can't alter the disks is probably best.
Exploiting optical would be worth a big pile of Defcon / CCC lulz for anyone who can demo a POC of it.
Explore it :)
:) 0) https://www.techrepublic.com/article/all-about-cd-r-and-cd-rw/
participants (4)
-
grarpamp -
Mirimir -
Steve Kinney -
Zenaan Harkness