https://bugs.documentfoundation.org/show_bug.cgi?id=114939
Michael Stahl <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
Assignee|[email protected] |[email protected]
|desktop.org |
--- Comment #16 from Michael Stahl <[email protected]> ---
This affects ODF in multiple ways:
* With non-default settings ODF 1.1 or ODF "1.2 Extended (compatibility mode)",
the ODF package encryption uses SHA1 for the start-key derivation
of PBKDF2 and SHA1/1k for the checksums of the files.
However, it's quite hard to actually create an affected document in practice:
- default version is ODF 1.2 extended
- the XML files have random comments of >= 903 uncompressed bytes added
in "makeXMLChaff()"
- the content.xml has > 1k (uncompressed) of namespace declarations
- passwords of 52 bytes are somewhat hard to remember
Probably you'd have to add a really tiny image or so to hit the bug.
* In all ODF versions, ODF package encryption PBKDF2 is implemented with SHA1,
however it is not affected because of the start-key derivation round
that generates a 20-byte or 32-byte input for PBKDF2.
* ODF "password-to-modify" extension: this is stored in settings.xml
so there isn't any interop to speak of currently; it uses PBKDF2 *without*
start-key derivation so is affected.
* Various "password" attributes that are handled centrally and with 2 different
bugs in SvPasswordHelper, which is just a train-wreck.
MS Office filters are also affected, although i haven't investigated how
exactly.
PDF export calls an affected function but apparently doesn't use the resulting
hashes, oddly enough.
There is a "master password" feature, in
Tools->Options->LibreOffice->Security->Persistently save passwords for web
connections->Master Password:
* executeMasterPasswordDialog() calls rtl_digest_PBKDF2() with a user-provided
password, so it's affected - this is stored somewhere in the user profile ...
best not to change this, there is no interop benefit
Outline of the plan to fix this nonsense:
* ODF import: try both the correct & the buggy SHA1, take first that succeeds
* ODF export, "1.2 Extended (compatibility mode)":
switch to use SHA256/AES instead of SHA1/Blowfish - releases that only read
the latter are > 5 years old.
* ODF export, 1.1: it doesn't really matter if we continue to use the broken
SHA1 or the fixed one, since the bug is so hard to trigger
* ODF export, PBKDF (for ODF 1.1 and for password-to-modify):
simply prevent 52 <= password <= 55 and reject this in the UI
(but it's still possible to create such passwords via the API)
* MSO import/export: always use correct SHA1
* Deprecate rtl_digest_*SHA*
* do not fix the bug in endSHA() so that the rtl_digest_*SHA* functions can be
used to import broken documents
* TODO what to do about SvPasswordHelper::GetHashPassword
--
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
