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.




ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view

2020-05-14 Thread Глеб Рахмановский


 
Dear Gurus,
Please let me know, are there any advantages of UltraSparc IIe over Cortex A7 
AllWinner H3 for a secure communication host ignoring a factor of power 
efficiency, size and loud noise?
IMHO the only feature OpenBSD can benefit from UltraSparc is StackGhost ?
 
 


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: Intel CPU (in)security

2020-05-14 Thread info
> Inside every modern Intel CPU is a secondary CPU running an embedded
OS with direct access to nice things like all the RAM, AES
acceleration hardware, TMP etc.

So we have since Core2Duo at least following :

IntelME - can be vanished by Libreboot
Important BLOBS (even in Coreboot) for hardware like RAM initialization -  can 
be vanished by Libreboot
Backdoors in the CPU to root it by some instruction sequence
Spectre & Hyperthreading  like CPU flaws - can it be vanished by software 
emulated VM?

Yesterday on May 13 almost at the midnight my computer went to sleep without me 
asking it to.
After returning it from sleep I could not run my browser from which I posted 
here anymore, though other browsers started. A try to run it from console 
indicated some LD lib or something like that  problems. It is a ES2L board 
waiting to be reflashed to Libreboot, not sure yet to do it or not though ...

Today my keyboard is very lazy to type, it seems like some type of an 
electromagnetic suppression, but it is a relatively old hardware and non USB 
keyboard, so it still works slowly :P

I am afraid that modern boards like for Haswell have more undesirable features, 
most likely they even do not need Internet cable, WIFI is not needed either, 
though not sure how it works, may be by radio channel backdoors in the board 
and even in relatively modern HDDs or just simly over power line?



Re: Intel CPU (in)security

2020-05-14 Thread Anders Andersson
On Thu, May 14, 2020 at 1:54 PM  wrote:
>
> Please suggest what has been cleaned by moderators on the website:
>
> https://web.archive.org/web/20200514115002/https://www.reddit.com/r/openbsd/comments/gf7wip/how_secure_are_intel_cpus/fpshspb/

No.

But this link may be informative: https://libreboot.org/faq.html#intel

Inside every modern Intel CPU is a secondary CPU running an embedded
OS with direct access to nice things like all the RAM, AES
acceleration hardware, TMP etc. No one but intel (and by extension,
NSA) has access to the code running on that CPU, and it would be
trivial for it to check incoming packets for patterns that activates
for example storing crypto keys into a small embedded EEPROM that can
be read out after the police has raided your home. A firewall can't
stop this.

Fortunately, the people who could possibly order intel to do something
like this doesn't care about your pirated movies, and it would be a PR
nightmare if Intel actually used the power they have for anything less
than national security, since the risk of something leaking would be
too large.



Intel CPU (in)security

2020-05-14 Thread info
Please suggest what has been cleaned by moderators on the website:

https://web.archive.org/web/20200514115002/https://www.reddit.com/r/openbsd/comments/gf7wip/how_secure_are_intel_cpus/fpshspb/



Re: using aggr interface instead of trunk

2020-05-14 Thread mabi
Hi Iain,

‐‐‐ Original Message ‐‐‐
On Wednesday, May 13, 2020 7:55 PM, Iain R. Learmonth  wrote:

> More details are at:https://marc.info/?l=openbsd-cvs=156229058006706=2

I actually already read that one after seeing the announcement on undeadly.org 
iirc ;)

> Assuming you mean trunk, not tun, yes.

Right, thanks for spotting that, I meant trunk of course.

> I don't see mention of any aggr fixes in the 6.7 changelog, so I guess it 
> didn't have any disasters in it. Others are using it on production systems.

Nice to hear that, I will give it a shot as soon as I upgrade to 6.6 my HA CARP 
cluster of two OpenBSD firewalls. I might first try using it on one of the two 
firewalls so that I can easily switch to the other firewall in any case of 
issue.



Re: Intel I210 Fiber Optic Ethernet Card Transceiver Info.

2020-05-14 Thread Stuart Henderson
On 2020-05-13, Vertigo Altair  wrote:
> Hi,
>
>
> Sorry for late reply but I had a problem accessing this device.
>
> I’ve tried both OpenBSD 6.6 and 6.7 (amd64), nothing changed:
>
> I think you’re probably right; transceiver command is only available for
> ix(4) driver.

AFAIK the list is: ix, ixl, bnxt, myx, mcx, mvneta

BTW 10Gb NICs also support 1Gb SFPs and the diagnostics work fine (and
are often easier to get hold of than 1G fibre NICs).

# ifconfig ixl2 sff
ixl2: flags=8843 mtu 8000
lladdr f8:f2:1e:57:46:82
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseLX full-duplex,rxpause,txpause)
status: active
transceiver: SFP LC, 1310 nm, 10.0km SMF
model: FLEXOPTIX S.1312.10.D rev A
serial: F786KHV, date: 2015-01-28
voltage: 3.31 V, bias current: 21.04 mA
temp: 49.62 C (low -45.00 C, high 110.00 C)
tx: -6.35 dBm (low -10.00 dBm, high -1.00 dBm)
rx: -5.60 dBm (low -23.01 dBm, high -2.00 dBm)

> But what about ifconfig em0 media output showing only supporting
> SX/multi-mode but actually supporting LX-/single-mode too?

That's the default used by em if another media type can't be worked out,
I'm not sure if full information on this is actually available from the
NIC (at least without adding sff diagnostics to em(4) too - and that
would be done outside of the "media" mechanism).




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.