[Cryptography] trojans in the firmware

grarpamp grarpamp at gmail.com
Sat Feb 21 01:26:36 UTC 2015


These were the links I was referring to that
never made it past moderation/spam...

> Alfred Hegemeier <molybdanstahl-hh at yahoo.co.uk> saith:
> just encrypt the whole hard drive with Geli.

GELI works under your control for what you store on the
drive, and you can even enable the AES encryption feature
of the drive itself as a no cost to performance extra freebie
underneath that. However since the raw device interface is still
accessible, neither of them do anything to block firmware
updates.



> Karl Denninger <karl at denninger.net> saith:
> 1. The BIOS (which reads the boot sector) has not been compromised.
> 2. Once the drive code has been tampered with

These cases were addressed earlier...

"
Obviously. This is only meant to help protect clean
systems, or prevent subsequent malicious commands if
they happen to go through a user to firmware path that has
for some reason not yet been compromised (say through
the usual /dev to driver to hardware path).

In all cases, having the logging capability for non production
opcodes without having to postfilter them out of some
debugging stream would be nice. Obviously again caveat
parts of the system that have not been compromised.
"

> how many of these attacks are going to be loaded into your machine
> through a _*running*_ modern BSD-style system?

These for starters, then all the public hacker malware versions of
the same thing both extant and coming...

https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html
http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg
https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html
http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg
http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg
http://25zbkz3k00wn2tp5092n6di7b5k.wpengine.netdna-cdn.com/files/2015/02/Equation_group_questions_and_answers.pdf

> I suspect the answer is
> "few" and a false sense of security is worse than none at all.

Defense in depth is not a false defense, even when thrown at the few.
Given a clean system, the ability to block these opcodes would
seem defensive.


More information about the freebsd-security mailing list