https://bugs.documentfoundation.org/show_bug.cgi?id=114939
Bug ID: 114939
Summary: SHA1 code has an off by 1 bug
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Description:
in the file sal/rtl/digest.cxx in the endSHA function, there is a bug.
The line:
if (i >= (DIGEST_LBLOCK_SHA - 2))
should be
if (i > (DIGEST_LBLOCK_SHA - 2))
This bug likely is seen in ALL of the endHASH() functions since they look very
similar. What happens is if the last limb of the hash is filled with exactly
52 to 55 bytes of data, then an extra limb (64 bytes) is added into the
computation. this makes the hashes for any string that is 52 >= mod(length) <=
55
Steps to Reproduce:
1. perform an SHA1 computation against a string 52 to 55 bytes long
2. do an sha1 with the Libre code AND of the string:
1012345678901234567890123456789012345678901234567890
3. the results (hex encoded) from the Libre code are
90a461ee9cc69cedaeb25c2dc5cc62544ebd5241
4. perform same thing using standard unix tool: echo -n
1012345678901234567890123456789012345678901234567890 | sha1sum
5. The results of step 4 are 9cb1dab34448c1ea460da1f8736869c8852f212f *-
6. the results are not the same. sha1sum gives correct results while Libre
gives incorrect results. I have researched and have been able to 100% mimic
the Libre code by adding 64 additional null bytes of padding (i.e. an extra
limb to the hash computation)
7. I am almost certain all other hashes handled in the digest.cxx are similarly
buggy, but I have not tested any of them.
Actual Results:
sha1(1012345678901234567890123456789012345678901234567890)
90a461ee9cc69cedaeb25c2dc5cc62544ebd5241
Expected Results:
echo -n 1012345678901234567890123456789012345678901234567890 | sha1sum
9cb1dab34448c1ea460da1f8736869c8852f212f *-
Reproducible: Always
User Profile Reset: No
Additional Info:
NOTE, the hashes are used for password validation and possibly other things.
Since there was buggy SHA1 which produced data stored in files, then correcting
this buggy sha1 behavior may render these user files non usable! Beware!
NOTE, I did not find this using LibreOffice. I work on another OSS project
(john), and we found this issue from data files which did not meet SHA1
specification.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101
Firefox/57.0
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs