re: fw_update verify firmware?
> 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?
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&m=125783114503531&w=2 > Episode 5: The Firmware Strikes Back: > http://marc.info/?l=openbsd-misc&m=126775051500581&w=2 > Episode 6: Return of the Vendor: > http://marc.info/?l=openbsd-misc&m=128779369427908&w=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?
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&m=125783114503531&w=2 Episode 5: The Firmware Strikes Back: http://marc.info/?l=openbsd-misc&m=126775051500581&w=2 Episode 6: Return of the Vendor: http://marc.info/?l=openbsd-misc&m=128779369427908&w=2 -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: fw_update verify firmware?
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?
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?
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?
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?
> 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?
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?
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?
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?
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?
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 >
