[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Re: Case ID 51560370 - Notice of ClaimedInfringement



Thierry Zoller wrote: 
Dear Jason,

J> I think that entirely depends on the format the file is distributed in.
J> You could take a zipfile and pad it in non critical areas to change the
J> MD5 without creating a substantial difference in the deliverable J> content. You could do the same with gzip or bzip formatted files. You
J> could also pad any embedded jpeg images to engineer a collision. There
J> are quite a few opportunities where this method could be used to twiddle
J> the new MD5 without materially changing the content.

Clever approach there, haven't thought about that beforehand.

Different approaches are rarely thought about beforehand. If they were explored deeply we might have found efficiencies and complications that would have been avoided. This security stuff might not even exist. We would also never make progress.


J> Software that is ~150M in size, it gets redistributed as a new file that
J> is 160M is size but has a collision with your software which is also
J> 160M in size. I imagine there would be some computational time involved
J> to find the appropriate collision but a lot less computational time than
J> finding a perfect match to the original.

If I understood your point correctly and if my knowledge about hash
algos is correct then to my believe the computational time to generate
a collision is exactly the same for the perfect match as it would be
to use an existing file to create a potenatial collision.


I've not looked into it to be honest. I am thinking aloud.

Are there cases where different bits will have a predictable and definable impact on the resulting hash? Does a null byte have a more defined impact than a non null byte? Can you use a minimal impact byte as padding and more impactful byte sequences to complete the collision?

It was once said that you could not realistically create two difference sets of data that would cause a hash collision.

It was once said that you could not exploit heap overflows and that stack overflows did not allow for control of the machine.

It was once thought that you could not use a format string to create an exploitable condition.

I see enough opportunities for motivated people to do the research and create a solution that is not computationally prohibitive. I would not be surprised if this happens in relatively short time.

To use the existence of a hash and size as justification for a legal assault against a person that appears to be providing content which is under protection of some law presents an interesting area of exploration in the courts for the right team. It was once thought that being found guilty by a jury was sufficient to put someone to death. DNA has changed that!

The only difference between theory and reality is implementation.

I think I am done with the thread on FD. Apologies to the myopic thinkers among us.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/