Re: Installation Media Self Integrity Check

[Jordan Geoghegan]

On 2020-08-12 21:30, Dan Peretz wrote:

Hello, the FAQ states this:
"The installXX.iso and installXX.fs images do not contain an
SHA256.sig file, so the installer will complain that it can't check
the signature of the included sets [...] This is because it would make
no sense for the installer to verify them. If someone were to make a
rogue installation image, they could certainly change the installer to
say the files were legitimate."
Although that's true for intentional modifications, it would still be
useful to have the installation medium perform a self integrity check
against accidental or natural data corruption. For example, Ubuntu
recently enabled a by-default integrity check, starting with release
20.04:
"Ubuntu now defaults to checking the integrity of the medium in use
when booting into live sessions. This can be skipped by hitting
Ctrl-C. We’ve enabled this because failed installs due to corrupt
downloads of installation media is one of the most common error
conditions that users encounter." (Source:
)
I would like to have OpenBSD include at least an unsigned SHA256 file
in the discs. The installer would then detect that the checksums are
unsigned and warn about the security implications, but it would let
the user run the check. I think it would be wise to make it check the
bsd.rd image that's actually booted when booting from the disc, and
not just the bsd.rd file set. (I get that the OpenBSD installer is
just a multipurpose "bsd.rd" RAM disk that can be found not just in
the installation discs, right?)

Thank you!



I think the whole idea is to check the ISO itself with signify before 
you even boot/write it. If you're concerned about whether the ISO was 
written to your install media correctly (or its integrity after the 
fact), then it should be pretty straightforward to check if the hashes 
match up. Once you've verified the SHA256 file from the mirrors, you 
know the hashes are valid (and if you're worried about MITM/compromised 
web hosts, the signify keys are published all over social media and 
blogs etc). Signify does its best to cope with the chicken and the egg 
problem (and everything that comes with trusting trust), but at the end 
of the day, you have to draw the line somewhere.


If you're spooked about the SHA256.sig warning, then you can install 
over the network from a mirror, but ultimately it's irrelevant. Check 
your ISO with signify and you're good to go.

Re: Installation Media Self Integrity Check

[Theo de Raadt]

Dan Peretz  wrote:

> Thank you for responding, Theo :)
> 
> On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt  wrote:
> >
> > the FAQ is wrong.
> >
> > Those images don't contain signatures because my build & sign
> > procedure does not have a way to sign something, then continue
> > building, then sign the result.
> >
> >
> > If you looked, you would see there is an unsigned SHA256 file.
> >
> 
> Yes, I opened the install ISO and I see. I also read the INSTALL.amd64
> doc. Maybe change the FAQ to something like this?
> "[...] If someone were to make a rogue installation image, they could
> certainly change the installer to say the files were legitimate.
> Regardless, an unsigned SHA256 file is used by the installation to
> detect accidental corruption in the file sets. If the distribution
> sets do not match their recorded checksums, the installation program
> will complain."

I disagree with your direction.  

You are now explaining to someone how to create invalid images,
rather than 


> > It already uses the SHA256 file to determine which files to install,
> > this is done, but a hash is not a cryptographic signature, so the warning
> > issued is accurate.
> >
> 
> Maybe also rephrase the warning by the installer to something like
> this, to make it clearer to the admin that the installer does not skip
> verification *completely*:
> "Directory does not contain SHA256.sig. Continue without verifying
> authenticity? (The sets will still be verified against accidental
> corruption with SHA256.) [no]"

I disagree.  I think it is good enough the way it is.  I don't think
People need to know all the details behind a warning.

> > Huh.  What you are asking for cannot be done.  And obviously a bogus
> > image would declare that it isn't bogus.
> >
> 
> True, but I meant that if the ISO boots a BSD.RD file, then the
> ramdisk (booted from that exact file) would verify the checksum of
> that file, from the disc. Obviously not from RAM. It's not foolproof,
> and it surely doesn't help against malicious alterations, but I think
> this is better than not doing so...

What you describe cannot be done.  You aren't thinking critically.

Re: Installation Media Self Integrity Check

[Dan Peretz]

Thank you for responding, Theo :)

On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt  wrote:
>
> the FAQ is wrong.
>
> Those images don't contain signatures because my build & sign
> procedure does not have a way to sign something, then continue
> building, then sign the result.
>
>
> If you looked, you would see there is an unsigned SHA256 file.
>

Yes, I opened the install ISO and I see. I also read the INSTALL.amd64
doc. Maybe change the FAQ to something like this?
"[...] If someone were to make a rogue installation image, they could
certainly change the installer to say the files were legitimate.
Regardless, an unsigned SHA256 file is used by the installation to
detect accidental corruption in the file sets. If the distribution
sets do not match their recorded checksums, the installation program
will complain."

>
> It already uses the SHA256 file to determine which files to install,
> this is done, but a hash is not a cryptographic signature, so the warning
> issued is accurate.
>

Maybe also rephrase the warning by the installer to something like
this, to make it clearer to the admin that the installer does not skip
verification *completely*:
"Directory does not contain SHA256.sig. Continue without verifying
authenticity? (The sets will still be verified against accidental
corruption with SHA256.) [no]"

>
> Huh.  What you are asking for cannot be done.  And obviously a bogus
> image would declare that it isn't bogus.
>

True, but I meant that if the ISO boots a BSD.RD file, then the
ramdisk (booted from that exact file) would verify the checksum of
that file, from the disc. Obviously not from RAM. It's not foolproof,
and it surely doesn't help against malicious alterations, but I think
this is better than not doing so...

Re: Installation Media Self Integrity Check

[Theo de Raadt]

Dan Peretz  wrote:

> Hello, the FAQ states this:
> "The installXX.iso and installXX.fs images do not contain an
> SHA256.sig file, so the installer will complain that it can't check
> the signature of the included sets [...] This is because it would make
> no sense for the installer to verify them. If someone were to make a
> rogue installation image, they could certainly change the installer to
> say the files were legitimate."

the FAQ is wrong.

Those images don't contain signatures because my build & sign
procedure does not have a way to sign something, then continue
building, then sign the result.

> Although that's true for intentional modifications, it would still be
> useful to have the installation medium perform a self integrity check
> against accidental or natural data corruption. For example, Ubuntu
> recently enabled a by-default integrity check, starting with release
> 20.04:
> "Ubuntu now defaults to checking the integrity of the medium in use
> when booting into live sessions. This can be skipped by hitting
> Ctrl-C. We’ve enabled this because failed installs due to corrupt
> downloads of installation media is one of the most common error
> conditions that users encounter." (Source:
> )

> I would like to have OpenBSD include at least an unsigned SHA256 file
> in the discs.

If you looked, you would see there is an unsigned SHA256 file.

> The installer would then detect that the checksums are
> unsigned and warn about the security implications, but it would let
> the user run the check.

It already uses the SHA256 file to determine which files to install,
this is done, but a hash is not a cryptographic signature, so the warning
issued is accurate.

> I think it would be wise to make it check the
> bsd.rd image that's actually booted when booting from the disc, and
> not just the bsd.rd file set. (I get that the OpenBSD installer is
> just a multipurpose "bsd.rd" RAM disk that can be found not just in
> the installation discs, right?)

Huh.  What you are asking for cannot be done.  And obviously a bogus
image would declare that it isn't bogus.

Installation Media Self Integrity Check

[Dan Peretz]

Hello, the FAQ states this:
"The installXX.iso and installXX.fs images do not contain an
SHA256.sig file, so the installer will complain that it can't check
the signature of the included sets [...] This is because it would make
no sense for the installer to verify them. If someone were to make a
rogue installation image, they could certainly change the installer to
say the files were legitimate."
Although that's true for intentional modifications, it would still be
useful to have the installation medium perform a self integrity check
against accidental or natural data corruption. For example, Ubuntu
recently enabled a by-default integrity check, starting with release
20.04:
"Ubuntu now defaults to checking the integrity of the medium in use
when booting into live sessions. This can be skipped by hitting
Ctrl-C. We’ve enabled this because failed installs due to corrupt
downloads of installation media is one of the most common error
conditions that users encounter." (Source:
)
I would like to have OpenBSD include at least an unsigned SHA256 file
in the discs. The installer would then detect that the checksums are
unsigned and warn about the security implications, but it would let
the user run the check. I think it would be wise to make it check the
bsd.rd image that's actually booted when booting from the disc, and
not just the bsd.rd file set. (I get that the OpenBSD installer is
just a multipurpose "bsd.rd" RAM disk that can be found not just in
the installation discs, right?)

Thank you!