re: fw_update verify firmware?

2020-05-15 Thread Герман Содатов


>    This has nothing to do with OpenBSD.
 
If OpenBSD would have a switch to disable usage of all BLOBs provided by OBSD 
at once on an user desire.
Does OpenBSD have any other BLOBs except firmwares which can be 
deleted/renamed/moved?
>     Please read your own statement. You aren't qualified to assert your
     opinion in this group, humble or not.

He does not assert, but rather trying to find a truth which is very difficult 
in a security area because
most agencies trying to hide such info and even often promote intentional 
misleading false on this topic.

>   It's not our job to turn you into a security expert.
 
Nobody's trying to force you to share knowledge, it is on your own will, up to 
you.
If someone else would ask that questions would you take it easier?
>   If you value the work that OpenBSD does to protect your security, use it. 
> If you don't, use something else.

As it is obvious from a discussion he still evaluating OpenBSD, that is the 
reason of his many questions.

>    Please. We aren't here to win you over.
 
Actually it does not matter for him win you him or not, he just wants to make a 
good choice, though it seems there is no other variants for him except paid 
grsec + his time spent on hardening the whole installation with grsec.
Btw, an idea of hardening processes by their own declaration like unveil, 
pledge, etc. looks very nice.
>Some of us are kinda tired of your flood of queries asking for yet another 
>opinion on often and widely discussed topics.
It is very hard times now when shameless corporations attack single persons, 
thanks for understanding, he is his line of defense.

>     ...and you won't find much modern hardware that it works on.

He does NOT need much hardware also he does NOT need modern hardware and he 
does NOT need a shiny superfast desktop.
Very slow secure OS on a very slow ancient hardware which can protect him is 
many many times better than any modern super expensive server if it would be 
even a free gift.

>     Oh, btw...if I recall properly, a lot of CPU security fixes are     
> distributed as firmware microcode updates that have to be loaded by the      
> OS. So... being inappropriately paranoid about firmware could      compromise 
> your security.
 
Especially if new backdoors (e.g. for rooting CPUs) are added in new microcode 
versions?
He does not trust any modern X86 CPUs with a firmware update or not. May be 
using a full software emulator can improve security? Say if running a very slow 
full software emulation of a rare CPU like Motorolla or MIPS on Librebooted X86 
CPU host like Core2 QUAD 9500 or something like it, would it be more secure 
inside a emulated MIPS guest to run OpenBSD than on a bare metal X86?
 


Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Aaron Mason  wrote:

> On Fri, May 15, 2020 at 3:39 AM Nick Holland
>  wrote:
> >
> > On 2020-05-14 11:08, i...@aulix.com wrote:
> >
> > I actually had Adaptec give me a firmware update with a time bomb in
> > it, and didn't bother to tell me that after X days, it would brick my
> > adapter and prevent me from updating/downdating it.  If it had been
> > stored in RAM, I might have been able to recover it, but since it was
> > flashed into EEPROM and prevented the machine from booting, the card
> > had to be replaced...and my customer had an outage.
> 
> Apropos of nothing, that saga is worth reading in full:
> 
> Episode 4: A New Flaw - http://marc.info/?l=openbsd-misc=125783114503531=2
> Episode 5: The Firmware Strikes Back:
> http://marc.info/?l=openbsd-misc=126775051500581=2
> Episode 6: Return of the Vendor:
> http://marc.info/?l=openbsd-misc=128779369427908=2

NO.

it is completely UNRELATED to the subject which is about fw_update

fw_update does NOT update controller firmware on that device.




Re: fw_update verify firmware?

2020-05-14 Thread Aaron Mason
On Fri, May 15, 2020 at 3:39 AM Nick Holland
 wrote:
>
> On 2020-05-14 11:08, i...@aulix.com wrote:
>
> I actually had Adaptec give me a firmware update with a time bomb in
> it, and didn't bother to tell me that after X days, it would brick my
> adapter and prevent me from updating/downdating it.  If it had been
> stored in RAM, I might have been able to recover it, but since it was
> flashed into EEPROM and prevented the machine from booting, the card
> had to be replaced...and my customer had an outage.

Apropos of nothing, that saga is worth reading in full:

Episode 4: A New Flaw - http://marc.info/?l=openbsd-misc=125783114503531=2
Episode 5: The Firmware Strikes Back:
http://marc.info/?l=openbsd-misc=126775051500581=2
Episode 6: Return of the Vendor:
http://marc.info/?l=openbsd-misc=128779369427908=2

-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse



Re: fw_update verify firmware?

2020-05-14 Thread Marc Espie
On Thu, May 14, 2020 at 04:25:11AM +, Mogens Jensen wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?

Others pointed out that firmwares are signed.

For a while now, fw_update AND pkg_add have defaulted to requiring
signed packages. If you try to install or even peek at something
unsigned with pkg_info, they error out.

You have to explicitly ask for unsigned data to bypass the check.



Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Nick Holland  wrote:

> On 2020-05-14 11:08, i...@aulix.com wrote:
> >> If that binary code was on a ROM, would it be less malicious?
> > 
> > Cannot more recent and up to date binary code be more malicious than
> > old one in the ROM?
> 
> This has nothing to do with OpenBSD.  That can be true for any kind of
> code update, whether it exists in RAM on a device that's loaded by the
> OS at boot time, EEPROM that can be reprogrammed by software, or a
> chip that has to be physically swapped out.
> 
> I actually had Adaptec give me a firmware update with a time bomb in
> it, and didn't bother to tell me that after X days, it would brick my
> adapter and prevent me from updating/downdating it.  If it had been
> stored in RAM, I might have been able to recover it, but since it was
> flashed into EEPROM and prevented the machine from booting, the card
> had to be replaced...and my customer had an outage.

That is completely unrelated to the signed-firmwares which OpenBSD
distributes.

And we don't have a firmware for Adaptec raid controllers.

These kinds of off-topic additions to stupid conversations don't
help to unstupid the conversations.



Re: fw_update verify firmware?

2020-05-14 Thread Nick Holland
On 2020-05-14 11:08, i...@aulix.com wrote:
>> If that binary code was on a ROM, would it be less malicious?
> 
> Cannot more recent and up to date binary code be more malicious than
> old one in the ROM?

This has nothing to do with OpenBSD.  That can be true for any kind of
code update, whether it exists in RAM on a device that's loaded by the
OS at boot time, EEPROM that can be reprogrammed by software, or a
chip that has to be physically swapped out.

I actually had Adaptec give me a firmware update with a time bomb in
it, and didn't bother to tell me that after X days, it would brick my
adapter and prevent me from updating/downdating it.  If it had been
stored in RAM, I might have been able to recover it, but since it was
flashed into EEPROM and prevented the machine from booting, the card
had to be replaced...and my customer had an outage.
> Please take into account, I am a very noob in security area and it is
> just my IMHO.

Please read your own statement.  You aren't qualified to assert your
opinion in this group, humble or not.  It's not our job to turn you
into a security expert.  If you value the work that OpenBSD does to
protect your security, use it.  If you don't, use something else.
Please.  We aren't here to win you over.  Some of us are kinda tired
of your flood of queries asking for yet another opinion on often and
widely discussed topics.

> Anyway there was another distro like LibertyBSD which was an OpenBSD
> without some already seldom blobs like firmwares. And another OpenBSD
> fork is declared to be going to appear: Hyperbola (it is Linux based
> yet for now), completely pure from BLOBs too.

...and you won't find much modern hardware that it works on.  You can
achieve your goal (including the "not working on your hardware"
feature) with OpenBSD by just removing the contents of the
/etc/firmware directory.  If the firmware isn't needed on your machine.
it's not loaded.  Concern about firmware binaries is not incorrect, but
it is horribly missing a lot of points about how modern computers work.
It's kinda like putting six bullets in a revolver, and obsessing about
the third one.  Yes, sure...that third one may blow a hole in your head
or protect you from the rabid wolf, but the other five could do very
much the same.  And in most cases, you have far bigger security
concerns than malicious firmware.  Here's a free security lesson: If I
want to take control of your machine, I'll use the easiest route; that
won't be malicious firmware.

Oh, btw...if I recall properly, a lot of CPU security fixes are
distributed as firmware microcode updates that have to be loaded by the
OS.  So... being inappropriately paranoid about firmware could
compromise your security.  

Nick.



Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
i...@aulix.com wrote:

> > If that binary code was on a ROM, would it be less malicious?
> 
> Cannot more recent and up to date binary code be more malicious than old one 
> in the ROM?

Our firmwares do not replace code on ROM, since the hardware in question
HAS NO ROM.



Re: fw_update verify firmware?

2020-05-14 Thread info
> If that binary code was on a ROM, would it be less malicious?

Cannot more recent and up to date binary code be more malicious than old one in 
the ROM?
Just because backdoor development is progressing as time goes and old backdoors 
may be less dangerous  compared to modern ones?

> If the binary code is malicious, don't buy the hardware it is
> associated with. 

Often there is no other choice except taking the oldest hardware we can afford 
to find.

Please take into account, I am a very noob in security area and it is just my 
IMHO.

Anyway there was another distro like LibertyBSD which was an OpenBSD without 
some already seldom blobs like firmwares.
And another OpenBSD fork is declared to be going to appear: Hyperbola (it is 
Linux based yet for now), completely pure from BLOBs too.



Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Janne Johansson  wrote:

> Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen <
> mogens-jen...@protonmail.com>:
> 
> > Normally I would just assume that fetched files are verified, but maybe
> > in the case with fw_update, the rationale is that firmware files are
> > binary blobs so we can't know if they are malicious anyway, therefore
> > no reason to bother with verification.
> >
> 
> It would be sad to mixup the fact that something is signed with a sort of
> guarantee that it is without faults or without malice.
> The signature proves it didn't change in transport since it was published,
> nothing more.

There is nothing malicious about the firmware blobs.

It is the binary code for the cpus on the hardware.

If that binary code was on a ROM, would it be less malicious?

If the binary code is malicious, don't buy the hardware it is
associated with.  The code is not what makes it malicious.

That line of thought is complete bullshit.



Re: fw_update verify firmware?

2020-05-14 Thread Stuart Henderson
On 2020-05-14, Mogens Jensen  wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?
>
> There is a SHA256.sig in the remote firmware directory, but no
> indication from fw_update, even with verbose output, if this is
> actually used.

SHA256.sig is not used here. The firmware files are in the standard
package format: a specially constructed tar.gz with an embedded
signature in the gzip comment. See pkg_sign(8) for more information.

> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they are malicious anyway, therefore
> no reason to bother with verification.

As with any other package that can install files and execute commands
on your system, malicious firmware packagss would be a big problem.
The signature checking is important.

> As firmware is fetched over plain HTTP, I guess that in case of no
> verification it would in theory make the system vulnerable to a MITM
> attack, but I'm no expert.

It's vulnerable to a "serve stale content" attack, i.e. sticking to an
older version with vulnerabilities when a fixed version is available.
But someone who can do that can also just block access to the update
servers having the same end result. These can probably be mitigated
by adding firmware packages to the table of vulnerable package
versions in the "quirks" package in the main package set (though
if that is also held back, it relies on the user to notice via the
displayed timestamp, I don't hold out much hope for this really being
noticed. We could make this more visible by having the quirks packages
"expire" but this has problems too, especially for architectures which
take a long time to build packages, or which don't have binary packages
for -stable).

As the firmware servers are independent and run by different people
under one domain name they can't really share a private key, making it
awkward to obtain certificates. Not impossible, we know how to do it
using DNS-01 and copying CSRs amd certificates around, but I'm not
really seeing enough benefits from running https on them to make it
worthwhile.




fw_update verify firmware?

2020-05-14 Thread Mogens Jensen
I was just trying out the fw_update program on OpenBSD 6.5, deleting/
installing all the firmware and was wondering if fw_update will verify
the files before installing?

There is a SHA256.sig in the remote firmware directory, but no
indication from fw_update, even with verbose output, if this is
actually used.

After looking at the source and manpage of fw_update, it was still not
clear to me if files are checked against SHA256.sig. For syspatch, it's
easy to tell from both source, manpage and program output.

Normally I would just assume that fetched files are verified, but maybe
in the case with fw_update, the rationale is that firmware files are
binary blobs so we can't know if they are malicious anyway, therefore
no reason to bother with verification.

As firmware is fetched over plain HTTP, I guess that in case of no
verification it would in theory make the system vulnerable to a MITM
attack, but I'm no expert.


Regards,
Mogens Jensen



Re: fw_update verify firmware?

2020-05-14 Thread Janne Johansson
Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen <
mogens-jen...@protonmail.com>:

> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they are malicious anyway, therefore
> no reason to bother with verification.
>

It would be sad to mixup the fact that something is signed with a sort of
guarantee that it is without faults or without malice.
The signature proves it didn't change in transport since it was published,
nothing more.

-- 
May the most significant bit of your life be positive.


Re: fw_update verify firmware?

2020-05-13 Thread Theo de Raadt
The firmwares are packages, and are signed with the
/etc/signify/openbsd-XX-fs.pub key.

There is no risk.


Mogens Jensen  wrote:

> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?
> 
> There is a SHA256.sig in the remote firmware directory, but no
> indication from fw_update, even with verbose output, if this is
> actually used.
> 
> After looking at the source and manpage of fw_update, it was still not
> clear to me if files are checked against SHA256.sig. For syspatch, it's
> easy to tell from both source, manpage and program output.
> 
> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they are malicious anyway, therefore
> no reason to bother with verification.
> 
> As firmware is fetched over plain HTTP, I guess that in case of no
> verification it would in theory make the system vulnerable to a MITM
> attack, but I'm no expert.
> 
> 
> Regards,
> Mogens Jensen
>