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.
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?
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.
Re: Intel I210 Fiber Optic Ethernet Card Transceiver Info.
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: using aggr interface instead of trunk
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&m=156229058006706&w=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.
Intel CPU (in)security
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: Intel CPU (in)security
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.
Re: Intel CPU (in)security
> 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: 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?
> 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?
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?
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?
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 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?
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
ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view
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?
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.
