Security and Usability Issues of Clear Signed Checksum Files

Project Discussion
,
1

The Fedora Project currently provides cleartext signatures to verify the ISO files. I recommend the Fedora Project additionally provide detached signatures due to the security issues with cleartext signatures.

From the GnuPG manual.

Note: When verifying a cleartext signature, gpg verifies only what makes up the
cleartext signed data and not any extra data outside of the cleartext signature
or the header lines directly following the dash marker line. The option --output
may be used to write out the actual signed data, but there are other pitfalls
with this format as well. It is suggested to avoid cleartext signatures in favor
of detached signatures.

As a result, an attack or malicious mirror could insert arbitrary data outside of the header lines without causing the signature verification to fail. For example, a file containing the following data would verify successfully with the Fedora 40 GPG key.

# INSERTED!!! INCORRECT HASH!!!
SHA256 (Fedora-Workstation-Live-x86_64-40-1.14.iso) = dd1faca950d1a8c3d169adf2df4c3644ebb62f8aac04c401f2393e521395d444


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Fedora-Workstation-Live-osb-40-1.14.x86_64.iso: 2623733760 bytes
SHA256 (Fedora-Workstation-Live-osb-40-1.14.x86_64.iso) = 8d3cb4d99f27eb932064915bc9ad34a7529d5d073a390896152a8a899518573f
# Fedora-Workstation-Live-x86_64-40-1.14.iso: 2295853056 bytes
SHA256 (Fedora-Workstation-Live-x86_64-40-1.14.iso) = dd1faca950d1a8c3d169adf2df4c3644ebb62f8aac04c401f2393e521395d613
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEEV35rvhXhT7oRF0KBydwfqFbecwFAmYisFcACgkQBydwfqFb
ecxHAhAAuyBb34jmvnR7GTfHfkUjh2s+oyn47Ytj7mhhNSwvg63utYdYbqQs2htS
oplomvcO0lt0vBeHjXGLUL4PeGhPWO/4As9hM7QjdqdRGUiZLYdVv44qzmApesWm
QU+tl9b76cf/QzUOcGSlGrhYWKZ+sZ/Ke9G81WQOlThcwUcVHVDwwJtsHShpsa8e
0WefRZiR3+qRxLxuzBtN7K7lXTBXzAqF4rTPZeBHSQ6oiLnKc8dARMxucov20MQx
MDQfmXXz7zNWilKjucurEuQxYGUkzl08kAHEZbeF4sgkaEqnWerovj7hdgyhW4Fx
Riw7t7B2Y2rMpJmRsH9loGATmB2g+4TyLDcOr8uQvLMTj3ytUw1GD+yPsxv4z2ik
Lx9MPllA+GGaMMUKfUThHLlZMvBOXYymbOlKZVHX/78I+G6t5efmn77v6R2SwgW3
V43/QNJld3+J6V68sk3g3KFpGbrvPoEzYYMXOTzy5gHGB3ppuvdDldgzFKwi2Dsy
LIlORoGpBsLSi6SUGPXw3i/UG04lnna3nX5I0sZMWV2kVbTziI9vit8nichcAXQs
qG2yuINwFxVxC7Gf76n0OIjy5dyapaJfCHWerGFy5cFQbuAv5JvfvBocLm3a58hh
Xfc5x/jQjnRPYBg9o2dA1kEwmoA76yR9apSoqNQtACdnVMMhzrA=
=HgqN
-----END PGP SIGNATURE-----

A naive user may incorrectly assume the entire file has been successfully verified and may erroneously trust the arbitrarily inserted data. Users should visually inspect their checksum files to ensure no arbitrary data has been inserted outside of the header lines or they should extract the signed data using the --output option.

GnuPG cleartext signatures have also suffered from vulnerabilities in the past. CVE-2006-049 is explained in detail on the GnuPG mailing list.

Signature verification of non-detached signatures may give a positive
result but when extracting the signed data, this data may be prepended
or appended with extra data not covered by the signature. Thus it is
possible for an attacker to take any signed message and inject extra
arbitrary data.

Detached signatures (a separate signature file) are not affected.

All versions of gnupg prior to 1.4.2.2 are affected.

Scripts and applications using gpg to verify the integrity of data are
affected. This includes applications using the GPGME library[2].

The GnuPG version 1.9.x is not affected unless the currently
deprecated gpg part has been enabled.

The cleartext signature format was fraught with issues in the past and has poor usability in the present. It is more secure and usable to provide a detached signature for the ISO files.

As an example, signature verification would proceed as follows.

gpp --verify Fedora-Workstation-Live-x86_64-40-1.14.iso.sig Fedora-Workstation-Live-x86_64-40-1.14.iso

Thank you all for reading my post.

Doby Mick

4 Likes
2

Added engineering

3

I agree with the idea of ​​detached signatures as it sounds reasonable.

But your example is a bit confusing since it implies to sign the images directly, while the current practice is to sign the checksum file.

Could you clarify the change proposal?

4

What is the confusing part? My proposal is to create a GnuPG detached signature over the ISO files. Therefore, there is no need for a checksum file.

The ISO file.

Fedora-Workstation-Live-x86_64-40-1.14.iso

The detached signature computed over the ISO file.

Fedora-Workstation-Live-x86_64-40-1.14.iso.sig
5

Abandoning checksums is more than just a change from cleartext to detached signature format.

I suspect the current practice for signing only the checksum file must have some reasons behind it.

6

The reason is that signing is a very slow process, which applies to more or less any asymmetric cryptography (public key/private key → asymmetric = encryption and decryption are two different keys) operation. This is why it is normal to create a checksum with a cryptographically-secure hash algorithm (symmetric cryptography) and then just sign that one. This makes a big difference, especially as the symmetric stuff can be done often by hardware - and in any case much more efficient. This is why it is not usual in cryptography to apply signature algorithms to files but their checksum.

This is also embedded and intended in OpenPGP in general - it does the same when it is used for encryption: it only encrypts the 128/256 bit key for symmetric cryptography (e.g., AES) with asymmetric cryptography , and then uses this key to encrypt the data that is to be encrypted by symmetric means (such as AES).

If the checksum is created with a well-reviewed cryptographically secure hash, the security does not suffer (actually, the hashes, such as SHA2, are less the things that cause cryptographers to worry, as long as the choice of algorithm is good - but we have standards for that. The asymmetric crypto of today is more something that needs consideration).

Signing whole files is not an option, but that does not mean that detaching the signature is none. With the idea of Doby Mich in mind, it would be then:

  1. create ISO file
  2. create checksum of the ISO file
  3. create detached signature computed from the ISO file’s hash

But I am not sure if the above points contain actually a vulnerability.

First, any attack makes only sense if the resulting ISO file still works without the ISO file system being broken. So if there is a way to get any arbitrary data contained, it is still not easy to cause a malicious ISO. However, any change/addition of bits that ain’t intended is not acceptable from a cryptography point of view. So that mitigates the practical aspects of the problem a little, but it is still worth to get into this.

I have not yet worked myself into cleartext signatures as implemented in GnuPG. So off the cuff, I cannot say anything for sure about that. Nevertheless, it is intended in many cases that file names can change, as checksum are mostly generated only from the content of the file. This is not an issue - we do not need to fear file names. I do not fully get if that is the issue you mean @dobymick ? (I haven’t worked with the output of GnuPG for years, so it is not clear to me from what exactly the two different hashes have been generated from and what caused the differences - I can only see both have different file names in this output). Some elaboration would be nice that does not dependent on GnuPG output. Also, with regards to outputs: do the two files also hash to different file names if you hash these files through sha256sum <filename> of your command line? That one ignores file names.

I do not fully get where the arbitrary code you mean can be added without the GnuPG becoming aware of it.

Also, let’s forget about vulnerabilities and such that are as of 2006. A lot has changed since then.

In any case, thanks Doby Mick for raising this issue: it is worth to have a look. The more people have a look with different perspectives, the more likely it is that we find any issue before any attacker does :classic_smiley:

1 Like
7

In my original post I have an example a checksum file with some information outside of the headers lines.

# INSERTED!!! INCORRECT HASH!!!
SHA256 (Fedora-Workstation-Live-x86_64-40-1.14.iso) = dd1faca950d1a8c3d169adf2df4c3644ebb62f8aac04c401f2393e521395d444


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Fedora-Workstation-Live-osb-40-1.14.x86_64.iso: 2623733760 bytes
SHA256 (Fedora-Workstation-Live-osb-40-1.14.x86_64.iso) = 8d3cb4d99f27eb932064915bc9ad34a7529d5d073a390896152a8a899518573f
# Fedora-Workstation-Live-x86_64-40-1.14.iso: 2295853056 bytes
SHA256 (Fedora-Workstation-Live-x86_64-40-1.14.iso) = dd1faca950d1a8c3d169adf2df4c3644ebb62f8aac04c401f2393e521395d613
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEEV35rvhXhT7oRF0KBydwfqFbecwFAmYisFcACgkQBydwfqFb
ecxHAhAAuyBb34jmvnR7GTfHfkUjh2s+oyn47Ytj7mhhNSwvg63utYdYbqQs2htS
oplomvcO0lt0vBeHjXGLUL4PeGhPWO/4As9hM7QjdqdRGUiZLYdVv44qzmApesWm
QU+tl9b76cf/QzUOcGSlGrhYWKZ+sZ/Ke9G81WQOlThcwUcVHVDwwJtsHShpsa8e
0WefRZiR3+qRxLxuzBtN7K7lXTBXzAqF4rTPZeBHSQ6oiLnKc8dARMxucov20MQx
MDQfmXXz7zNWilKjucurEuQxYGUkzl08kAHEZbeF4sgkaEqnWerovj7hdgyhW4Fx
Riw7t7B2Y2rMpJmRsH9loGATmB2g+4TyLDcOr8uQvLMTj3ytUw1GD+yPsxv4z2ik
Lx9MPllA+GGaMMUKfUThHLlZMvBOXYymbOlKZVHX/78I+G6t5efmn77v6R2SwgW3
V43/QNJld3+J6V68sk3g3KFpGbrvPoEzYYMXOTzy5gHGB3ppuvdDldgzFKwi2Dsy
LIlORoGpBsLSi6SUGPXw3i/UG04lnna3nX5I0sZMWV2kVbTziI9vit8nichcAXQs
qG2yuINwFxVxC7Gf76n0OIjy5dyapaJfCHWerGFy5cFQbuAv5JvfvBocLm3a58hh
Xfc5x/jQjnRPYBg9o2dA1kEwmoA76yR9apSoqNQtACdnVMMhzrA=
=HgqN
-----END PGP SIGNATURE-----

Please verify this for yourself. It will successfully pass verification with the Fedora 40 GPG key.

8

This would be ideal. Debian, Ubuntu, and Linux Mint follow this format.

9

I think I get now what you mean. You just changed the checksum file manually and added that stuff to the top, you didn’t actually change an ISO file or so. Well, what you add to the top will be ignored. It doesn’t hurt. This is why the verification is successful. The below one in the header is relevant. This one has to fit. In terms of arbitrary code, keep in mind that nothing in this file will be executed anyway.

In such a file many ISO files can be contained that ain’t relevant, and that cannot be verified at the very moment as not all files that are contained are always available. The tool will only use what is relevant (and contained in the header).

I agree that the way with external signatures is nicer and more comprehensible to users. But itself, I do not see a security issue here.

I have to say that I did not know about this behavior. It is indeed interesting, and one can say that this is something that should cause some warning to make aware that this is not intended (its more to educate people because it is no good practice to write in such files), but I do not see a security issue. Anyway, the behavior in such changes should be changed upstream at GnuPG, not here.

10

Please read my second post when you have the time.

TLDR:
We can only trust the signed data area of the clear signed checksum file. However, when running sha256sum --check on the clear signed checksum file, it will read every line in that file, not just the lines in the signed data area.

PS:
Not really a bug with GnuPG, just a limitation of the cleartext signature format.

11

Let me re-formulate: Take the ISO file and its CHECKSUM file. Change the ISO’s content so that it really hashes to a different output. Now put the corrupted hash output in the CHECKSUM file. You have now manipulated the CHECKSUM file and the ISO file.

Now try to verify if the correct gpg file verifies this ISO file as identical to the one Fedora has signed.

12

Are we talking about the same thing? What gpg file are we talking about? The gpg signature is embedded into the checksum file, its a cleartext signature file.

It depends on where you insert the corrupted hash output. Outside of the header lines, verification is fine. Otherwise, it will throw an error.

13

All the attacker needs to do is tamper with the ISO file, and change its filename.

Insert the corrupted hash of the tampered ISO file outside of the header lines of the checksum file.

gpg verification of the checksum file will pass.
sha256sum --check will read the corrupted hash and check the hash of the tampered ISO.

14

You might visit Fedora Workstation | The Fedora Project and click on the verification button of the issue. It contains something that elaborates the issue I mean.

However, if you assume that the victim already gets all signatures and such (in short, gets everything) from the attacker, well, then there is no security at all. I guess the suggestion here should start with getting Fedora from our website and ensure that the HTTPS is verified by your browser :classic_smiley:

Supplement:

screenshot
screenshot1640Ă—1152 400 KB

→ You would have found that if you follow advise, the corruption would have been identified. But earlier than you maybe thought :classic_smiley:

15

We get checksum files and ISO files from mirrors. We get GPG signing keys directly from the fedora project server.

It is well within expectation that a mirror could be malicious. That is why we use GPG. As long as you can ensure that the GPG signing key is legitimate, it doesn’t matter where we get our checksum files or ISO files from.

16

My last comment for today:

If you get everything from an attacker, no cryptography can protect you. You have to use a secure browser with well/current certificates: If you then go to our website, with HTTPS & automatic verification of the certificate of the website through your browser, you will securely and reliably end up on our website without manipulations on getfedora.org, and if you follow advise, you will get indeed the ISO file and the CHECKSUM file from a mirror, but if you follow the advise, it would be identified if the mirror is malicious. See the screenshot above: the checksum file is verified, and as sha256 is a cryptographically secure hash, we can assume that an attacker will not be able to get any other ISO file that hashes to the same output with SHA256 (because sha256 is cryptographically secure: collision, preimage and 2nd preimage resistant as of today) → so, I mean the SHA256 output that is contained in the CHECKSUM file, whereas the CHECKSUM file was verified. Therefore, if the CHECKSUM file is not manipulated (which it is not if you verified its integrity through our gpg file, as advised), we can assume the ISO is not manipulated as well.

That said, I agree that from a social perspective (so if we do not restrict us to technical dimensions), the way this is implemented is a mess, and users are likely to not do any verification and just take what the mirrors present. This implementation does not consider average human behavior. However, one can say that the connection is established secure to the mirrors, and the mirrors are afaik all well-reputated entities, which mitigates this issue a little. Nevertheless, its not an optimal solution, and I would not add a “socio-technical secure” sticker to it :wink: But from a purely technical/cryptographic point of view, it is possible to get the ISO without manipulations (as long as modern crypto is as secure as we assume).

17

I entirely agree with the last paragraph. Like you said, from a purely technical standpoint we can guarantee the end user will receive a legitimate Fedora Linux ISO.

The purpose of my post was to illustrate the usability concerns of GnuPG and how they could affect security.

I do not understand why the Fedora Project could not use a simpler or more intuitive means verifying their ISO images. OpenBSD Foundation wrote Signify to validate their releases. The developer of libsodium, a cryptographic library, wrote minisign. Both those tools are extremely simple, with small code bases and use modern EC cryptography.

1 Like
18

Actually we have Fedora Media Writer as a recommended method to prepare the installation media with built-in verification:

1 Like
19

Good point. I just checked, and it seems that the Media Writer on our website seems to be provided through ourselves, without mirrors. However, people see the media writer and ISOs, and on one hand, people take what they are used to (which is what most sites use for such things = ISO), and on the other hand, encouraging people to execute third party code code on their system to get something done that every system of today can do itself (such as using ISOs in the respective manner) is not a good practice on itself: several people might avoid it if they are able to use ISOs. So this will include beginners and also experienced users to avoid the Media Writer: sometimes for intuitive reasons (and any website/person about getting Linux systems that tell how to get one would focus ISO), sometimes to avoid installing stuff when its not necessary.

So yeah, it can mitigate the issue, but it still lacks consideration of the social elements. And I also don’t like to install code when its not necessary.

Now that I get your point @dobymick (I think this time I got what you meant ; ) , I agree that there is room for improvements. Your solution with the detached signatures would indeed be a better one for the use case because it at does not contain the possibility that a malicious/manipulated/captured mirror could even capture the verification (which adds trust to the malicious file). But it would add something many users are not used to, and many will not even know how to make use of it, and do not use it thus at all. Many just want to verify integrity if they know the mirror or so: the average CHECKSUM is a good practice to have and should not be fully replaced by signatures. Sometimes, its just about integrity :wink: Effectively, this is a standard.

My preference would be to to provide the CHECKSUMs already on our side: get the checksums from our server rather than a mirror (they are smaller than the media writer anyway, and we already provide that one ourselves - so it cannot be about traffic). Alternatively, put the CHECKSUMS already in the button that wants to verify the CHECKSUM file (the button leads to the screenshot I provided above), whereas I would keep the possibility to verify the CHECKSUM file as well, for those who got it from any mirror, but maybe this could be a button within the button to limit information presented to the user: so focus the screenshot page to the CHECKSUMs (there could be a line for any Fedora variant so that people do not need to maintain separate pages for each variant), and add link within to lead to the current screenshot with gpg verification of the CHECKSUM file for those who want that. I think for most users this would be easiest.

Plus lobbying for adding a detached signature file to the mirrors. But we have to stick with signing checksums (although I assume the process you suggest does not really sign the file but does create a checksum automatically and then sign and verify that one - I don’t think GnuPG would do direct file signatures). I am not sure if everything can be implemented immediately, so that might be a step by step thing.

What do you think about it?

We have to also keep in mind maintenance of that stuff. And on the other hand, mirrors have to provide checksum files as some do not go through us (sometimes its really just about checksums :wink: ). But in that case they trust their mirror anyway, which is always the choice of the user. Of course if a signature file is added, this would mitigate the issue again on their side, and that would be better than current approach, but average users won’t use it. But the signature files on themselves cause a hint to users.

We have to keep in mind that as of today, the major security here comes from HTTPS in such situations because it ensures you really end up with the respective domain (and ensures integrity/auth in between) and I think our mirrors are trustworthy HTTPS domains (I admit, I do not know off the cuff how/when they end up in the mirror list, so feel free to challenge my argument here). What we do talk here atm is primarily avoiding single points of failure, which means that malicious code could not be verified if any mirror is captured.

By the way, you mentioned other distros, do they only offer signature files? Or do they also add checksum files? I expect the latter.

20

It is of upmost importance that the end user will receive an authentic Fedora Linux ISO.

I believe it is worth the effort for the user to learn how to use GnuPG and to understand asymmetric cryptography. We should not sacrifice security for convenience.

Trusting mirror servers is a bad idea because it needlessly enlarges the circle of trust. HTTPS only guarantees transport security and it has no final say over the authenticity of a Fedora Linux ISO.

I cannot change your mind if you think it is okay to trust mirrors and that HTTPS and the CA model is enough to guarantee the end user will receive an authentic Fedora Linux ISO. In my opinion the circle of trust is simply too large to be safe.

The OpenBSD Foundation has a much more rational perspective on digitally signing their releases. Even though the Fedora Project uses GnuPG to digitally sign their releases, I do not believe it is used in a safe or rational manner.

Postscript:
I highly recommend you read the link above. Ted Unangst describes these issues and solutions more eloquently then I ever could.

1 Like