Re: [Slackbuilds-users] MD5 hash sums

[Konrad J Hambrick]

All --

IMO ( and ITO of other SBo Customers ), The MD5SUM= field in the .info file
is to verify that the DOWNLOAD= files that you downloaded the same files
that the Maintainer downloaded.

Nothing more than that.

It is not for security -- the SBo Maintainer cannot guarantee that the
source files are secure -- that is the Upstream Developer's duty.

IOW, What Habs said.

-- kjh

On Fri, Aug 24, 2018 at 6:03 AM,  wrote:

> However, you absolutely cannot assume that because the MD5 sum matches
>> that the file is in any way "safe" or was not tampered with /before/ the
>> maintainer got to it.
>>
>
> Can I assume that because MD5 sum matches that the file was not tampered
> after the maintainer got it? I believe this was the original scope of the
> thread in the first place.
>
> Quoting https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability
>
> In April 2009, a preimage attack against MD5 was published that breaks
>> MD5's preimage resistance. This attack is only theoretical, ...
>>
>
> It was theoretical in 2009. The question is whether or not it was made
> practical in the past nine years? There are two possible outcomes. One: it
> was made practical and is not yet published. Two: it is still theoretical.
> Do you really want to wait until it becomes practical *and* published?
>
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Μιχάλης Μιχαλούδης]

24 Αυγ 2018, 2:03 μμ, ο χρήστης «t...@airmail.cc» έγραψε:
>  Do you really want to wait until it becomes practical *and* published?

There is no ending to security measures. You stop to take measures when they’re 
is no threat, not possibility of threat.

1. Crackers are not stupid to waste time to tamper source code to match the 
same  md5sum, it’s way too much complicated. And it’s very easy to notice. It’s 
easier for them to write a virus for autorun usb flash’s for other kind of 
users, not for slackers.

2. If the original coder can’t understand the difference in code after the 
tampering (I suppose  will be huge) whatever measure is useless.

(Excuse my English)
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[thyr]

However, you absolutely cannot assume that because the MD5 sum matches 
that the file is in any way "safe" or was not tampered with /before/ 
the maintainer got to it.


Can I assume that because MD5 sum matches that the file was not tampered 
after the maintainer got it? I believe this was the original scope of 
the thread in the first place.


Quoting https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability

In April 2009, a preimage attack against MD5 was published that breaks 
MD5's preimage resistance. This attack is only theoretical, ...


It was theoretical in 2009. The question is whether or not it was made 
practical in the past nine years? There are two possible outcomes. One: 
it was made practical and is not yet published. Two: it is still 
theoretical. Do you really want to wait until it becomes practical *and* 
published?

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Habs]

On Thu, 23 Aug 2018, Erik Hanson wrote:

On 8/23/18 5:59 PM, t...@airmail.cc wrote:


So, one can verify the authenticity of the SlackBuild script, but the
authenticity of the source tarball itself used by the aforementioned
script is uncertain? If that's the case then why would one bother with
verifying authenticity at all? (Something authentic) x (Something that
may or may not be authentic) == (Something that may or may not be
authentic), right?


It's been mentioned in this thread enough times that MD5 has not fallen
to the attack you think it has, so I won't repeat that talking point,
but I will try and clarify something..

The checksums are not there to verify authenticity. Everyone seems to be
putting far too much stock in the MD5 sums in the .info files. I can't
stress this enough: they're not there for security.

You could almost think of it as a version number. If the file you
download matches the MD5 sum provided, then you know it's the same file
the maintainer used, and the same file the SlackBuild was tested against
by a SlackBuilds.org admin. This helps to ensure the SlackBuild will
work as intended, creating a valid package.

What the MD5 sum can, and does do on a regular basis, is raise a red
flag when it mismatches. Possibly the source has gone missing, or been
replaced by upstream without a change to the file name. These things
happen often enough that it's important we have a checksum, and that
people use it rather than complain that a SlackBuild is broken.

However, you absolutely cannot assume that because the MD5 sum matches
that the file is in any way "safe" or was not tampered with /before/ the
maintainer got to it. Auditing or policing upstream sources is far
beyond the scope of this project. We could use the strongest hashing
algorithm available, but telling people it's a mark of authenticity
would be nothing but theater.


--
Erik




It seems clear enough to me and has done since it was explained to me a
while back.

Effectively, if the maintainer unfortunately has used an 'unsafe' source, 
created its checksum for that source and then uploaded the build package, 
then all the checksum is doing when use it, is validating it was that 
original unsafe source (assuming it hasn't again been altered); or more 
preferably and likely the 'safe' source - as said, there is nothing SBo 
can do about unsafe sources and updating to better checksums etc won't 
help that it seems to me.


I think the current approach is 'safe enough' once one accepts the above
to prove nothing was tampered with when we get it - or at least will let
us know.

I stand to be corrected, however.

Habs

--- Sent using Alpine/Pine, a text based MUA ---
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Erik Hanson]

On 8/23/18 5:59 PM, t...@airmail.cc wrote:

> So, one can verify the authenticity of the SlackBuild script, but the
> authenticity of the source tarball itself used by the aforementioned
> script is uncertain? If that's the case then why would one bother with
> verifying authenticity at all? (Something authentic) x (Something that
> may or may not be authentic) == (Something that may or may not be
> authentic), right?

It's been mentioned in this thread enough times that MD5 has not fallen
to the attack you think it has, so I won't repeat that talking point,
but I will try and clarify something..

The checksums are not there to verify authenticity. Everyone seems to be
putting far too much stock in the MD5 sums in the .info files. I can't
stress this enough: they're not there for security.

You could almost think of it as a version number. If the file you
download matches the MD5 sum provided, then you know it's the same file
the maintainer used, and the same file the SlackBuild was tested against
by a SlackBuilds.org admin. This helps to ensure the SlackBuild will
work as intended, creating a valid package.

What the MD5 sum can, and does do on a regular basis, is raise a red
flag when it mismatches. Possibly the source has gone missing, or been
replaced by upstream without a change to the file name. These things
happen often enough that it's important we have a checksum, and that
people use it rather than complain that a SlackBuild is broken.

However, you absolutely cannot assume that because the MD5 sum matches
that the file is in any way "safe" or was not tampered with /before/ the
maintainer got to it. Auditing or policing upstream sources is far
beyond the scope of this project. We could use the strongest hashing
algorithm available, but telling people it's a mark of authenticity
would be nothing but theater.


-- 
Erik



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Richard Ellis via SlackBuilds-users]

On Fri, Aug 24, 2018 at 01:59:59AM +0300, t...@airmail.cc wrote:
> >What are all of those .asc files in the repository?
> >
> >Those files are GPG signatures. They can be used to verify that the
> >SlackBuild script tarball is exactly the one that we placed on the site.
> 
> So, one can verify the authenticity of the SlackBuild script, 

The .asc files protect the entire slackbuild package.  They verify
that the entire *.tar.gz file has not been modified since the SBo
admins posted the *.tar.gz file to the site.

> but the authenticity of the source tarball itself used by the
> aforementioned script is uncertain?

No.  The MD5 sum being discussed in *inside* the SBo *.tar.gz file in
the *.info file contained therein.  The *.asc file authenticating the
*.tar.gz SBo package allows you (assuming you check the GPG
signature) to determine that the *.tar.gz was not modified, which by
extension means the *.info inside was also not modified since the
package was posted.

Now you know that the *.info was not modified (due to the GPG *.asc
file).  If the *.info file was not modified, then the MD5 sum inside
was also not modified and represents exactly what the maintainer
placed inside the *.info file when they created it.

So with a MD5 sum that you know to have been unmodified (due to
checking the *.asc on the whole bundle) you can verify that the
package source you download from the download link matches the
unmodified MD5 sum in the *.info file.  If they match, you have
verified that the downloaded source package you received is identical
to that which was used by the SBo package maintainer when they
created the SBo *.info file.

The reason this works is that to break this (substitute a different
download package for the origional download package) the attacker has
to perform a second pre-image attack, which remains computationaly
infeasable today even for MD5.

> If that's the case then why would one bother with verifying
> authenticity at all?  (Something authentic) x (Something that may
> or may not be authentic) == (Something that may or may not be
> authentic), right?

The authenticity verification is so you can be sure someone did not
substitute a different copy of myapp.tar.gz from the copy used by the
SBo maintainer when they created the buildscript and *.info file.  An
attacker might try to insert "evil virus" into the download package,
hoping someone would download it in the future and without checking
the hashes compile it up, install it, and now the attacker has a
victim.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Brenton Earl]

On Fri, 2018-08-24 at 01:59 +0300, t...@airmail.cc wrote:
> > > > Each SlackBuild archive is signed by the SBo devs, so any
> > > > modifications on the server (or in-between) would fail
> > > > subsequent
> > > > verification. In that case it's the GPG signature that you
> > > > trust to
> > > > verify the .info file contents (and all the rest of the
> > > > SlackBuild
> > > > stuff), not the MD5 sum or whatever else is inside it.
> > > 
> > > Sorry, the question I had in mind was about MD5 sums inside it.
> > > Seems
> > > kind of strange that SlackBuild archive is protected by GPG
> > > signature,
> > > but the actual source tarball is not signed and is protected by
> > > (obsolete) MD5 checksum. Aren't this situation an opportunity to
> > > MITM
> > > the source tarball itself, since some DOWNLOAD links are
> > > provided 
> > > trough
> > > plain HTTP?
> > 
> > Sources are not protected by us. We do not provide the MD5 sum as
> > any
> > sort of security measure, it shouldn't be treated as one. We have
> > no
> > agency over upstream sources, and we purposefully do not host them,
> > so
> > we cannot provide any signature or sum that could be considered a
> > token
> > of security.
> 
> Thanks for the clarification. I'm still struggling getting the grasp
> of 
> it's effect though..
> 
> Quoting the FAQ from https://slackbuilds.org/faq/#asc
> 
> > What are all of those .asc files in the repository?
> > 
> > Those files are GPG signatures. They can be used to verify that
> > the 
> > SlackBuild script tarball is exactly the one that we placed on the 
> > site.
> 
> So, one can verify the authenticity of the SlackBuild script, but
> the 
> authenticity of the source tarball itself used by the aforementioned 
> script is uncertain? If that's the case then why would one bother
> with 
> verifying authenticity at all? (Something authentic) x (Something
> that 
> may or may not be authentic) == (Something that may or may not be 
> authentic), right?

The maintainer is supposed to take the GPG signature, MD5 or SHA check
sum from the upstream developer and use it to authenticate the source
prior to uploading a new/updated SlackBuild.  It is the maintainer's
job to verify the source before putting their own check sum into the
.info file.

-- 
Brenton Earl 

signature.asc
Description: This is a digitally signed message part
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[thyr]

Each SlackBuild archive is signed by the SBo devs, so any
modifications on the server (or in-between) would fail subsequent
verification. In that case it's the GPG signature that you trust to
verify the .info file contents (and all the rest of the SlackBuild
stuff), not the MD5 sum or whatever else is inside it.


Sorry, the question I had in mind was about MD5 sums inside it. Seems
kind of strange that SlackBuild archive is protected by GPG signature,
but the actual source tarball is not signed and is protected by
(obsolete) MD5 checksum. Aren't this situation an opportunity to MITM
the source tarball itself, since some DOWNLOAD links are provided 
trough

plain HTTP?


Sources are not protected by us. We do not provide the MD5 sum as any
sort of security measure, it shouldn't be treated as one. We have no
agency over upstream sources, and we purposefully do not host them, so
we cannot provide any signature or sum that could be considered a token
of security.


Thanks for the clarification. I'm still struggling getting the grasp of 
it's effect though..


Quoting the FAQ from https://slackbuilds.org/faq/#asc


What are all of those .asc files in the repository?

Those files are GPG signatures. They can be used to verify that the 
SlackBuild script tarball is exactly the one that we placed on the 
site.


So, one can verify the authenticity of the SlackBuild script, but the 
authenticity of the source tarball itself used by the aforementioned 
script is uncertain? If that's the case then why would one bother with 
verifying authenticity at all? (Something authentic) x (Something that 
may or may not be authentic) == (Something that may or may not be 
authentic), right?

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Gabriel Diaz]

Hello,

I think this is not a big deal, changing to another hash function should be 
easy enough.

But I also think slackbuilds should stay away of the security discussion. 
Providing a secure distribution channel is in the hands of the code owner only. 
If the source is already weak there is no encryption in the world to protect 
you.

And even though I just mirrored sbosrcarch, I would say slackbuilds should stay 
away from being a third party code distributor.

Anyway I think there is nothing wrong adding SHA1 in the info file, tools can 
ignore or check it as they like. Just don't make it a requirement.

saludos,
gabi






‐‐‐ Original Message ‐‐‐
On August 23, 2018 12:58 PM, Richard Ellis via SlackBuilds-users 
 wrote:

> On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote:
> 

> > On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy li...@osh.id.au wrote:
> > 

> > > For an attacker to change the upstream source archive without
> > > changing the MD5 requires a 2nd preimage attack, which as far as
> > > I understand is not computationally feasible at present. This is
> > > different to a much simpler collision attack, where the attacker
> > > generates two new archives with new (and matching) MD5s.
> > 

> > The download files do not necessarily have to be tar archives, and
> > in some cases (generally those with multiple download files and
> > therefore multiple checksums), individual files can be included for
> > download. Intentional PDF collisions have been around for ages
> > (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a
> > SlackBuild includes some documentation as a download link, and the
> > upstream server has since been compromised, a user could definitely
> > be stuck with a malicious file even if the SlackBuild maintainer
> > did everything right and verified upstream signatures.
> 

> The reason the slackbuild MD5's do not fall victim to the "pdf
> collision" attack is a subtle distinction between what crytographers
> define as a "collision" attack vs. a second pre-image attack.
> 

> The pdf attack you describe above is a "collision" attack. A
> collision attack is defined by cryptographers as "find any two files,
> A and B, which produce the same hash" [1]. That was how the PDF
> attack worked, it was just constrained to "the A and B files need to
> be valid PDF files". But, a collision attack does not allow an
> attacker (MITM, etc.) to simply substitute the upstream file with a
> new file that matches the same hash as the origional file.
> 

> In order for an attacker to substitute a different upstream file for
> the origional file, the attacker has to find a new file that matches
> the MD5 hash of the existing file. This attack is what
> cryptographers define as a "second pre-image" attack. And it means
> "given a file G, find another file C which has an identical hash"
> [2]. This is the attack that a MITM ISP or a cracker breaking in to
> an upstream repository has to perform to substitute a different file
> that matches the MD5 in the SBO.
> 

> The reason is that the SBO files contain an MD5 sum of a known file G
> (the origional). And the SBO file is then protected by a GPG
> signature. If a user verifies that the downloaded SBO and GPG
> signature are valid, then the user knows that the SBO has not been
> altered. Therefore the user knows the MD5 sum within the SBO has
> also not been altered (by a MITM or other attack).
> 

> Therefore, in order for the downloaded file (tar ball, zip, pdf,
> whatever) to be altered, but still match the MD5 sum in the SBO, a
> second pre-image attack is requred. This is because the valid MD5
> sum in the SBO is now the sum of a single given file G, and the MITM
> has to find a new file C which hashes to the same MD5 of the given
> file G.
> 

> MD5 has not (yet) been shown to be vulnerable to this attack (second
> pre-image) in any feasable timeframe [3][4]. Yes, a day is going to
> arrive sometime in the future where it will likely fall to a second
> pre-image attack, so upgrading to a stronger hash function is also a
> good idea. But the MD5's are not (yet) a security risk.
> 

> > It is probably more difficult to generate tarballs
> > with collisions but I'm guessing it isn't quite as difficult as we're
> > pretending it is, and it's irrelevant since unzipped files can be passed as
> > download links.
> 

> Cryptographers don't care about what the stream of bytes represent.
> The attack types are defined over the set of "all possible byte
> combinations of inputs to the hash function".
> 

> > Simply put, this is bad security. Anyone who disagrees doesn't understand
> > the problem.
> 

> Well, anyone who confuses collision attacks (which have been shown
> against MD5) with second pre-image attacks (which is what the GPG
> protected MD5 hashes in the SBO force an attacker to achieve) is also
> not fully up to speed on the meaning of the different attacks and the
> security properties they provide and falls 

Re: [Slackbuilds-users] MD5 hash sums

[Richard Ellis via SlackBuilds-users]

On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote:
> On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy  wrote:
> 
> > For an attacker to change the upstream source archive without
> > changing the MD5 requires a 2nd preimage attack, which as far as
> > I understand is not computationally feasible at present.  This is
> > different to a much simpler collision attack, where the attacker
> > generates two _new_ archives with new (and matching) MD5s.
> >
> 
> The download files do not necessarily have to be tar archives, and
> in some cases (generally those with multiple download files and
> therefore multiple checksums), individual files can be included for
> download.  Intentional PDF collisions have been around for ages
> (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a
> SlackBuild includes some documentation as a download link, and the
> upstream server has since been compromised, a user could definitely
> be stuck with a malicious file even if the SlackBuild maintainer
> did everything right and verified upstream signatures.

The reason the slackbuild MD5's do not fall victim to the "pdf
collision" attack is a subtle distinction between what crytographers
define as a "collision" attack vs. a second pre-image attack.

The pdf attack you describe above is a "collision" attack.  A
collision attack is defined by cryptographers as "find any two files,
A and B, which produce the same hash" [1].  That was how the PDF
attack worked, it was just constrained to "the A and B files need to
be valid PDF files".  But, a collision attack does not allow an
attacker (MITM, etc.) to simply substitute the upstream file with a
new file that matches the same hash as the origional file.

In order for an attacker to substitute a different upstream file for
the origional file, the attacker has to find a new file that matches
the MD5 hash of the existing file.  This attack is what
cryptographers define as a "second pre-image" attack.  And it means
"given a file G, find another file C which has an identical hash"
[2].  This is the attack that a MITM ISP or a cracker breaking in to
an upstream repository has to perform to substitute a different file
that matches the MD5 in the SBO.

The reason is that the SBO files contain an MD5 sum of a known file G
(the origional).  And the SBO file is then protected by a GPG
signature.  If a user verifies that the downloaded SBO and GPG
signature are valid, then the user knows that the SBO has not been
altered.  Therefore the user knows the MD5 sum within the SBO has
also not been altered (by a MITM or other attack).

Therefore, in order for the downloaded file (tar ball, zip, pdf,
whatever) to be altered, but still match the MD5 sum in the SBO, a
second pre-image attack is requred.  This is because the valid MD5
sum in the SBO is now the sum of a single given file G, and the MITM
has to find a new file C which hashes to the same MD5 of the given
file G.

MD5 has not (yet) been shown to be vulnerable to this attack (second
pre-image) in any feasable timeframe [3][4].  Yes, a day is going to
arrive sometime in the future where it will likely fall to a second
pre-image attack, so upgrading to a stronger hash function is also a
good idea.  But the MD5's are not (yet) a security risk.

> It is probably more difficult to generate tarballs
> with collisions but I'm guessing it isn't quite as difficult as we're
> pretending it is, and it's irrelevant since unzipped files can be passed as
> download links.

Cryptographers don't care about what the stream of bytes represent. 
The attack types are defined over the set of "all possible byte
combinations of inputs to the hash function".

> Simply put, this is bad security. Anyone who disagrees doesn't understand
> the problem.

Well, anyone who confuses collision attacks (which have been shown
against MD5) with second pre-image attacks (which is what the GPG
protected MD5 hashes in the SBO force an attacker to achieve) is also
not fully up to speed on the meaning of the different attacks and the
security properties they provide and falls into the trap of
"criticis[ing] MD5 and SHA1 for the wrong reasons" [4].

> Can't we just add an optional sha256sum in the .info file and
> maintainers can gradually add these checksums to their SlackBuilds,
> targeting some point in the future that these fields will be required (and
> possibly the md5s retired)?

Upgrading to sha256 is not a bad idea, but the MD5's do not yet
present a "the sky is falling" risk given the way they are verified
via the GPG signature protecting the SBO file.

[1] https://en.wikipedia.org/wiki/Collision_attack
[2] https://en.wikipedia.org/wiki/Preimage_attack
[3] http://www.cs.cmu.edu/~perspectives/md5.html (paragraph beginning
"To understand the implications" up through the paragraph ending
"Perspectives requires only second preimage resistance of MD5")

[4] https://en.wikibooks.org/wiki/Cryptography/Breaking_Hash_Algorithms
  "The MD5 and SHA-1 hash functions, in 

Re: [Slackbuilds-users] MD5 hash sums

[David O'Shaughnessy]

On 08/23/2018 03:45 PM, T3 slider wrote:
> The download files do not necessarily have to be tar archives, and in
> some cases (generally those with multiple download files and therefore
> multiple checksums), individual files can be included for download.
> Intentional PDF collisions have been around for ages
> (see https://www.mscs.dal.ca/~selinger/md5collision/
>  ), so if a
> SlackBuild includes some documentation as a download link, and the
> upstream server has since been compromised, a user could definitely be
> stuck with a malicious file even if the SlackBuild maintainer did
> everything right and verified upstream signatures. It is probably more
> difficult to generate tarballs with collisions but I'm guessing it isn't
> quite as difficult as we're pretending it is, and it's irrelevant since
> unzipped files can be passed as download links.

I don't see how this works if each individual download (either archive
or single uncompressed file) has its own MD5. My understanding of
collisions is that one can easily create two differing files with
matching MD5 sums (so the original innocuous file A plus a malicious new
file B), but that this necessarily creates a new (shared) MD5 sum. If
the target MD5 is given beforehand (i.e., the one(s) in the info file),
then a preimage attack is required which is impractical.

> 
> Simply put, this is bad security. Anyone who disagrees doesn't
> understand the problem. Can't we just add an optional sha256sum in the
> .info file and maintainers can gradually add these checksums to their
> SlackBuilds, targeting some point in the future that these fields will
> be required (and possibly the md5s retired)?

An optional sha256sum field seems reasonable to me.

--
Dave
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[T3 slider]

On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy  wrote:

> For an
> attacker to change the upstream source archive without changing the MD5
> requires a 2nd preimage attack, which as far as I understand is not
> computationally feasible at present. This is different to a much simpler
> collision attack, where the attacker generates two _new_ archives with
> new (and matching) MD5s.
>

The download files do not necessarily have to be tar archives, and in some
cases (generally those with multiple download files and therefore multiple
checksums), individual files can be included for download. Intentional PDF
collisions have been around for ages (see
https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a SlackBuild
includes some documentation as a download link, and the upstream server has
since been compromised, a user could definitely be stuck with a malicious
file even if the SlackBuild maintainer did everything right and verified
upstream signatures. It is probably more difficult to generate tarballs
with collisions but I'm guessing it isn't quite as difficult as we're
pretending it is, and it's irrelevant since unzipped files can be passed as
download links.

Simply put, this is bad security. Anyone who disagrees doesn't understand
the problem. Can't we just add an optional sha256sum in the .info file and
maintainers can gradually add these checksums to their SlackBuilds,
targeting some point in the future that these fields will be required (and
possibly the md5s retired)?

-T3slider

>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[David O'Shaughnessy]

On 08/23/2018 12:55 AM, t...@airmail.cc wrote:
> Sorry, the question I had in mind was about MD5 sums inside it. Seems
> kind of strange that SlackBuild archive is protected by GPG signature,
> but the actual source tarball is not signed and is protected by
> (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM
> the source tarball itself, since some DOWNLOAD links are provided trough
> plain HTTP?

Let's say the user has a SlackBuild + .info file, both of which have
been signed by the SBo dev team and are authentic (thus including the
MD5). The assumption here is that the maintainer actually checks
signatures upon downloading (and that upstream devs even sign in the
first place), so the stuff in the .info is "safe".

Now the user goes to download the source listed in .info, and unbeknown
to them it has been maliciously tampered with (either on the server or
MITM, so either TLS or not, it doesn't matter). The MD5 of that altered
archive will not match the authentic MD5 found in the .info file. For an
attacker to change the upstream source archive without changing the MD5
requires a 2nd preimage attack, which as far as I understand is not
computationally feasible at present. This is different to a much simpler
collision attack, where the attacker generates two _new_ archives with
new (and matching) MD5s.

So, as long as SlackBuild maintainers are actually verifying the
signatures on source archives and not blindly trusting checksums (of any
variety) published on upstream websites, then using MD5 in this way
seems OK. That said, I do think that it would be safer practice to just
use a stronger hash function anyway (https://blake2.net/ ?), as things
can change suddenly (who knows what's around the corner).

--
Dave
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Erik Hanson]

On 8/22/18 9:55 AM, t...@airmail.cc wrote:
>> Each SlackBuild archive is signed by the SBo devs, so any
>> modifications on the server (or in-between) would fail subsequent
>> verification. In that case it's the GPG signature that you trust to
>> verify the .info file contents (and all the rest of the SlackBuild
>> stuff), not the MD5 sum or whatever else is inside it.
> 
> Sorry, the question I had in mind was about MD5 sums inside it. Seems
> kind of strange that SlackBuild archive is protected by GPG signature,
> but the actual source tarball is not signed and is protected by
> (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM
> the source tarball itself, since some DOWNLOAD links are provided trough
> plain HTTP?

Sources are not protected by us. We do not provide the MD5 sum as any
sort of security measure, it shouldn't be treated as one. We have no
agency over upstream sources, and we purposefully do not host them, so
we cannot provide any signature or sum that could be considered a token
of security.


-- 
Erik



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Tim Dickson via SlackBuilds-users]

On 22/08/2018 15:55, t...@airmail.cc wrote:
Each SlackBuild archive is signed by the SBo devs, so any 
modifications on the server (or in-between) would fail subsequent 
verification. In that case it's the GPG signature that you trust to 
verify the .info file contents (and all the rest of the SlackBuild 
stuff), not the MD5 sum or whatever else is inside it.


Sorry, the question I had in mind was about MD5 sums inside it. Seems 
kind of strange that SlackBuild archive is protected by GPG signature, 
but the actual source tarball is not signed and is protected by 
(obsolete) MD5 checksum. Aren't this situation an opportunity to MITM 
the source tarball itself, since some DOWNLOAD links are provided 
trough plain HTTP?
unless you are running over public wifi or internet cafe, a MITM attack 
on a source gz is less likely than someone breaking in to your 
hoise/business and planting malware on your pc/laptop. It would mean 
your ISP was compromised, in  which case you have bigger issues to worry 
about than sourcde code frome some sites being changed on the fly.


When you bear in mind that source code is usually compressed, it is not 
so easy to change bits while keeping the md5 sum the same and also not 
causing the archive to be un-openable because of the changes.- the 
changes would break the checksums inside the gz file format.


GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha):

SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which 
generates larger hashes (224, 256, 384, or 512 bits). Right now, 
these are the strongest hashes in GnuPG.


vs

MD5 is a 128-bit cryptographic hash function invented by Ron Rivest 
(the ‘R’ of ‘RSA’) in the early 1990s. For many years it was one of 
the standard algorithms of the field, but is now completely obsolete. 
For that reason, MD5 is not supported by GnuPG.


Wouldn't it be better to use, say, SHA512 instead?
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/



___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[thyr]

Each SlackBuild archive is signed by the SBo devs, so any modifications 
on the server (or in-between) would fail subsequent verification. In 
that case it's the GPG signature that you trust to verify the .info 
file contents (and all the rest of the SlackBuild stuff), not the MD5 
sum or whatever else is inside it.


Sorry, the question I had in mind was about MD5 sums inside it. Seems 
kind of strange that SlackBuild archive is protected by GPG signature, 
but the actual source tarball is not signed and is protected by 
(obsolete) MD5 checksum. Aren't this situation an opportunity to MITM 
the source tarball itself, since some DOWNLOAD links are provided trough 
plain HTTP?


GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha):

SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which 
generates larger hashes (224, 256, 384, or 512 bits). Right now, these 
are the strongest hashes in GnuPG.


vs

MD5 is a 128-bit cryptographic hash function invented by Ron Rivest 
(the ‘R’ of ‘RSA’) in the early 1990s. For many years it was one of the 
standard algorithms of the field, but is now completely obsolete. For 
that reason, MD5 is not supported by GnuPG.


Wouldn't it be better to use, say, SHA512 instead?
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[David O'Shaughnessy]

On 08/21/2018 09:32 PM, t...@airmail.cc wrote:
> Hello.
> 
> I have a question about DOWNLOAD and MD5SUM variables in the
> .info files.
> 
> As this page https://www.gnupg.org/faq/weak-digest-algos.html states:
> 
>> It is better to entirely avoid the MD5 algorithm and don't put any
>> value in signatures based on MD5.
> 
> Would that be a valid concern for the .info files?
> 
> A lot of DOWNLOAD links are plain http ones and thus are suspectible to
> MITM tinkering on the ISP side...

Each SlackBuild archive is signed by the SBo devs, so any modifications
on the server (or in-between) would fail subsequent verification. In
that case it's the GPG signature that you trust to verify the .info file
contents (and all the rest of the SlackBuild stuff), not the MD5 sum or
whatever else is inside it.

--
Dave
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] MD5 hash sums

[thyr]

Hello.

I have a question about DOWNLOAD and MD5SUM variables in the 
.info files.


As this page https://www.gnupg.org/faq/weak-digest-algos.html states:

It is better to entirely avoid the MD5 algorithm and don't put any 
value in signatures based on MD5.


Would that be a valid concern for the .info files?

A lot of DOWNLOAD links are plain http ones and thus are suspectible to 
MITM tinkering on the ISP side...

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/