just encrypt the whole hard drive with Geli.
That's the only protection I see: everything passing through the controllers is
encrypted - unless keyloggers are installed, which you best protect against
completely firewalling the "core" system, andhaving jails to access the outer
world.
PCbsd already dumped complete auto hard drive encryption in their latest
products - the automatic full HD encr was dumped when the Snowden stuff was
revealed, I think with 10 release.So, I guess, they know why they removed it -
makes it to secure.
Which brings up an important question: how 'safe' is the encryption Geli, i.e.
how can we know that developers are not on any agencies pay list ?Does that
make sense what I am writing in your opinion ?
greetings.
From: "freebsd-security-requ...@freebsd.org"
<freebsd-security-requ...@freebsd.org>
To: freebsd-security@freebsd.org
Sent: Thursday, 19 February 2015, 13:00
Subject: freebsd-security Digest, Vol 522, Issue 1
Send freebsd-security mailing list submissions to
freebsd-security@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-security
or, via email, send a message with subject or body 'help' to
freebsd-security-requ...@freebsd.org
You can reach the person managing the list at
freebsd-security-ow...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-security digest..."
Today's Topics:
1. Re: [Cryptography] trojans in the firmware (grarpamp)
2. Re: [Cryptography] trojans in the firmware (Henry Baker)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Feb 2015 18:12:07 -0500
From: grarpamp <grarp...@gmail.com>
To: "cryptogra...@metzdowd.com" <cryptogra...@metzdowd.com>
Cc: cypherpu...@cpunks.org, freebsd-security@freebsd.org
Subject: Re: [Cryptography] trojans in the firmware
Message-ID:
<CAD2Ti29bD6f7tTq=fggqdxd43c+ztw0fowyrbcetcbmiu0b...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell <mi...@niftyegg.com> wrote:
> The critical stage is the boot ROM (BIOS) and the boot device.
> Once Linux has booted a lot is possible but too much has already taken
> place.
> A BIOS that allows booting from a Flash memory card must be trusted.
>
> Virtual machines may help or hinder.
>
> The VM is sitting where the man in the middle wants to be and if it wants
> can protect or expose
> the OSs that it hosts. A VM can protect a hard drive from being infected
> by blocking vendor
> codes that might try to update or corrupt modern disks of boot flash memory.
Afaik, all vm's today simply pass through all drive commands.
It seems a move all the BSD's and Linux could make today,
without waiting on untrustable hardware vendors to roll out signature
verification in hardware, is to simply kernel block all commands
unnecessary to actual production use of the disk. Permit only
from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on.
Thus every other command component, including firmware update,
vendor specific, and binary fuzzing, gets dropped and logged.
It could be done as a securelevel, or compiled in.
It's definitely not bulletproof, but it does force adversaries
to add that much more exploit code and effort to
get root and go around the driver interface to access
the hardware directly. Defense in depth.
Similar tactics could be applied to other areas where
firmware and vendor/fuzzable opcodes are involved...
usb, bios and cpu.
------------------------------
Message: 2
Date: Wed, 18 Feb 2015 17:57:40 -0800
From: Henry Baker <hbak...@pipeline.com>
To: grarpamp <grarp...@gmail.com>
Cc: cypherpu...@cpunks.org, freebsd-security@freebsd.org,
cryptogra...@metzdowd.com
Subject: Re: [Cryptography] trojans in the firmware
Message-ID: <e1yogna-0004bg...@elasmtp-banded.atl.sa.earthlink.net>
Content-Type: text/plain; charset="us-ascii"
At 03:12 PM 2/18/2015, grarpamp wrote:
>On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell <mi...@niftyegg.com> wrote:
>> The critical stage is the boot ROM (BIOS) and the boot device.
>> Once Linux has booted a lot is possible but too much has already taken place.
>> A BIOS that allows booting from a Flash memory card must be trusted.
>>
>> Virtual machines may help or hinder.
>>
>> The VM is sitting where the man in the middle wants to be and if it wants
>> can protect or expose
>> the OSs that it hosts. A VM can protect a hard drive from being infected by
>> blocking vendor
>> codes that might try to update or corrupt modern disks of boot flash memory.
>
>Afaik, all vm's today simply pass through all drive commands.
>
>It seems a move all the BSD's and Linux could make today,
>without waiting on untrustable hardware vendors to roll out signature
>verification in hardware, is to simply kernel block all commands
>unnecessary to actual production use of the disk. Permit only
>from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on.
>Thus every other command component, including firmware update,
>vendor specific, and binary fuzzing, gets dropped and logged.
???? If the disk drive or flash drive firmware has already
been compromised, none of this will work, because the firmware
simply waits for the appropriate "legitimate" read & write
commands, and does its thing.
BTW, what happens with "emulated" disks -- e.g., .vdi files --
in vm's ? Presumably these emulated disks have no firmware to
update, so any attempt would either be ignored or crash the
system.
------------------------------
Subject: Digest Footer
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
------------------------------
End of freebsd-security Digest, Vol 522, Issue 1
************************************************
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
