Installation file checksums (md5 not trustworthy)

Question

In the context of a colleague’s virus scanner (panda) producing what I sincerely hope is a false-positive match on the PT8 installer, I’ve just realised that the only checksums available on https://pt8.paratext.org/download/currentversion/ are MD5s.

Since it’s apparently now ‘not hard’ to append bytes onto any file that will make the end result have any desired md5 checksum, md5 is now really only any good as a way of checking if a file has downloaded correctly. I.e. unlike SHA checksums it now provides no guarantee that the file has not been maliciously tampered with.

Furthermore, as the checksum file is in the same subdirectory as the file, the checksums are not trustworthy themselves, either; it would be much safer if the checksums were somewhere else.

Can I therefore request that:

• sha checksums (as well as md5) be generated. E.g. sha1 and sha256
• the checksums go into the text on the web page, especially if that’s on a different server.
• When a new paratext installer gets released, the checksums get appended to the release announcement.

That way I’d have some reliable evidence that the windows file is what the packagers wanted people to get. Not as automatic as the linux repository of course but that’s a bit much to ask.

Answer 1

The checksums we provide are mainly to make sure you downloaded the entire file before your internet gave out.

Understanding a bit about internet security, but by no means an expert, could you explain how the files displayed on the website could get compromised without access to the server itself (in which case the attacker could change whatever they want anyways) being that they are delivered via HTTPS from a trusted/known website?

EDIT: Just noticed that the download itself is sent via HTTP, so that makes my question irrelevant. I’ll look into getting that changed. So, assuming that the download was over HTTPS, could it get compromised?

Comments

Eek, I didn’t realise they went over HTTP!

It’s called layers of defence, or defence in depth. In the event of a security breach (sadly they happen), say via a new bug in the server’s scripting engine, someone gains write-access to the download directory, then:

• making 2 different checksums (e.g SHA1 and SHA-256) means that if SHA1 is ever compromised in a similar way to MD5 (add carefully selected bytes to get your favourite MD5 checksum), then the SHA1 sum might be made to match, but the different key size, etc. would mean that the SHA-256 sum would not match.

• putting checksums into the text of the webpage means that the attacker ALSO has to get access to that too. At the very least this would need them to know the website layout, etc, so it stops being an
  automatic ‘replace install files with my malware and update any checksum files’ and becomes do all that and
  also edit the page. - more difficulty.

• Assuming the password / authentication method is different, this adds an extra challenge, and an additional chance that the attacker decides ‘that’s good enough’ and doesn’t cover their tracks.

• Putting the checksums into an email means that to be fully convincing, the attacker would also have to compromise the email account to send out an update. If they managed that too, then at the very least the developer team could scratch their heads and say ‘hey. I didn’t send that, did you?’ and so become suspicious enough to warn people ‘something bad might have happened, we’re checking.’

anon542642

Answer 2

The files should now be transferred over HTTPS. The installers are all signed (always have been) so they can not be tampered with without breaking the signing so that users get “scary” messages when attempting to install. Those two things together should make it reasonably secure to download from our site.

Comments

I’m glad the installers are digitally signed. That ought to provide a good integrity proof, indeed.

As someone who last seriously used windows when win95 was the latest and greatest, and has been in a linux-only household since about 2005, I’m not particularly aware of how this works from the windows-end-user experience.

Does windows give warnings if the file is not signed, or only if the signature is invalid?

It seems that there is a problem, in that the user in this case had a “scary message”, from her virus scanner, but it did not tell her that the signature was correct, nor did she have information that they were signed.

I think a bit of documentation on the site could have removed some worry for her. I don’t see anything on the website about the installers being signed, so ‘they always have been’ or assumptions about best practice does not provide any pointer for the new user, nor is there any reference to how someone can check the signature / how to spot a genuine one.

Having done 5 or 6 google searches I’ve found out how to check a signature from linux:

1. built-in mono tool ‘chktrust’, but that only tells me that “signature is valid and can be traced back to a trusted root” but gives me no information on who signed it.

2. ‘osslsigncode’ (available in ubunbtu repositories) which tells me it was signed by United Bible Societies Association, Swindon. Now that I like! Do windows users have access to this level of information, or has it been decided that people don’t need to know it?

---

anon542642:

Does windows give warnings if the file is not signed, or only if the signature is invalid?

If a file is not signed it will display a warning. You can check the details of the signature if wanted.