The problem is that on Windows 7 the password-encrypted documents are
stored unencrypted, without any error message.
This is due to defensive programming in
OStorageHelper::CreatePackageEncryptionData(), which happily continues
if creating the SHA256 hash fails, which is the one required for storing
anything newer than ODF 1.1.
Also, the poorly named ZipPackage::GetEncryptionKey() should check for
consistency, the expectation is that either there's no encryption key
(empty sequence), or the expected one is in the sequence.
Creating the SHA256 uses the crypto::NSSInitializer component, which is
in xsec_xmlsec.dll, which is linked to libxmlsec-mscng.dll, which is
linked to Win32 bcrypt.dll, which doesn't have BCryptKeyDerivation on
Windows 7; to reproduce elsewhere, rm instdir/program/libxsec_xmlsec.so
(regression from commit 26bf26272b
and (due to revert) commit bfd479abf0)
Change-Id: I0b22e20f6d4d0b1a12ed7d99fac7b5243910f9ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163708
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem in the bugdoc was the directory entries. These entries
are valid in ZIP packages (even if not common); they may be useful
to e.g. define per-directory permissions (ACLs).
In normal mode, ZipFile reads central directory; there we can read
if the entry has FAT file attributes; and then, if the entry is a
directory. Then it is OK to skip it.
In repair mode, central directory is not used, local file headers
don't contain a "directory" flag. A workaround is used, checking
if there are entries that represent directories of other entries.
Also this change fixes some places that didn't pass the recovery
flag correctly.
Change-Id: I324671841a2c4d0f279b03801d95c8f2eeb99b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162888
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... to init the Version property.
The problem is that the outer storage loaded from a wholesome ODF
encrypted document doesn't have a Version, because it doesn't (directly)
contain a document and has no "/" file-entry.
Extract the root element's package version attribute and use it.
The Storage API doesn't distinguish much between the package version and
the root document's (i.e. root folder's) version.
Change-Id: I0fd5f999e9adee674d73fc542402512d0e204897
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161897
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
1. ManifestImport should attach KeyInfo to the first file-entry, not to
a "/" entry which may not exist or may be preceded by another
file-entry which requires the KeyInfo to decrypt
(regression from commit 91f35f22f0)
2. manifest:key-size on manifest:key-derivation is unfortunately
specified to have a default value of 16, but with AES256 the actual
size is 32, and for GPG the ManifestExport forgot to export it
Change-Id: I05dd2c9e219ba7f20ba33bf0b35d47a9e3df74cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161072
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
https://www.rfc-editor.org/rfc/rfc9106.html
* add css::xml::crypto::KDFID constant group
* add "KeyDerivationFunction" to setEncryptionAlgorithms sequence
* Argon2 is used by default for wholesome ODF encryption, but
$LO_ARGON2_DISABLE can be set to use PBKDF2
* extend various structs in package
* use 3 new ODF attributes "loext:argon2-iterations" "loext:argon2-memory"
"loext:argon2-lanes" to store the arguments
* use this URL for now:
"urn:org:documentfoundation:names:experimental:office:manifest:argon2id"
* use default arguments according to second recommendation from "7.4.
Recommendations" of RFC9106; 64 MiB RAM should hopefully not be too
much even for 32 bit builds
Change-Id: I683118cc5e0706bd6544db6fb909096768ac9920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161009
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... ODF wholesome encrypted package.
There can only be "mimetype", "encrypted-package", and files in
"META-INF".
Change-Id: I5eb46ba29a1a62e25af09e189e0a075a871c71c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160718
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Old versions of LO or other consumers can't read wholesome ODF encrypted
documents anyway, so start using the correct W3C SHA256 URL (see commit
1015d35f23).
Change-Id: Id82ab2c9f605eb2084ff01a26e8186223dd46763
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160764
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... for ODF wholesome encryption.
4.3 <manifest:file-entry>
For directories, the manifest file should contain a <manifest:file-entry> element only if a directory contains a document or a sub document.
Because the "encrypted-package" is not a document but a package, we
should probably omit the file-entry for the root document.
ZipPackage::writeTempFile() always generates the root document becuase
it's needed for GPG properties, and ManifestExport filters it out.
A bit tricky to implement, because there isn't a clean distinction
between the package and the root document/storage in the package module,
in particular there's no other place than the root storage to store the
MediaType property.
Change-Id: Id7e72a64e2faa074dce80cd5fefb2fa189e2e3ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160717
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
It would work for the bugdoc in tdf#131575; but not if the wrong case
is the only problem in the package, because then there would be no
repairment mode active. An alternative could be to use case insensitive
match always, but that looks wrong.
Change-Id: Ie405d37e1dc639482bd2608e4479de5b707a07d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160761
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... completely, as currently it was generated for the first file-entry
due to too late setting of bStoreStartKeyGeneration.
Change-Id: I0cc80169deeea133bff45545fdf20fab6a6bedaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160716
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
AEAD provides the verification of the password automatically, by reading
the entire stream the tag at the end will be verified.
The existing attributes manifest:checksum-type/manifest:checksum leak
information about the plain text.
This was mitigated with the addChaffWhenEncryptedStorage() functions
(see commit f57baefbd3) but a better
solution that also works for non-XML streams is to simply omit the
attributes; authenticated encryption provides better verification
without any leak.
* "ChecksumAlgorithm" property can be set to void now to remove the
checksum
* change a bunch of members in EncryptionData, ZipPackage,
ZipPackageStream to optional
* change ZipFile::checkValidPassword() to open the stream and return it
Change-Id: Id95288d0c238c4f9940fc5a185df814e8edcbad3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160711
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
... and use it in the new experimental ODF encryption mode.
https://www.w3.org/TR/xmlenc-core1/#sec-AES-GCM
Unfortunately it turned out that NSS PK11_CipherOp() does not work with
CKM_AES_GCM because it is initialized with "context->multi = PR_FALSE"
in sftk_CryptInit(), so the one-step functions PK11_Encrypt() and
PK11_Decrypt() have to be used.
NSS 3.52 also changed a parameter struct definition - see
https://fedoraproject.org/wiki/Changes/NssGCMParams - which is not a
problem for RHEL or SUSE system NSS since those are rebased, but it
is likely a problem for less well maintained Ubuntu LTS, so use
the old struct definition which evidently still works with NSS 3.94.
NSS 3.52 also added a new PK11_AEADOp() API but it looks like this
doesn't support incremental encryption either.
Change-Id: Ibd4a672db74b65b1218926ba35ff8d2f70444c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160505
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Redo the ODF encryption by storing an ODF package and wrapping it as a
stream "encrypted-package" in another ODF package, such that there is
only one encrypted stream - this requires only one KDF computation.
* This is only enabled in Experimental mode for now.
* Avoid storing unencrypted data in the pTempFile of SfxMedium, as it
is usually created in the same directory as the target file, which
may be on a network share or similar less trusted location.
* SfxMedium::SetEncryptionDataToStorage_Impl() should just set an
error status if it fails (how can it fail anyway)
* when loading a document, SfxDocPasswordVerifier extracts an encrypted
inner package (by calling SfxMedium::TryEncryptedInnerPackage())
* SfxMedium::GetStorage() automatically decrypts an encrypted inner
storage and sets it as the SfxMedium's xStorage
* when storing a document, SfxObjectShell::SaveTo_Impl() creates
the wrapped storages
* One challenge is to keep the macro/scripting signature working; this
can only be put in the inner storage, whereas the document signature
should continue to be on the outer storage; also it must use a Zip
storage, to see the "META-INF" directory. This needs a new
SfxMedium::GetScriptingStorageToSign_Impl() and changes in
SfxMedium::SignContents_Impl().
Change-Id: Ibfee36ce3a9cd030f2aa2ce1484b6d001cba2389
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160401
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
In deep detection, first check if it's a broken ZIP package. If it is,
set the RepairPackage media descriptor property to true.
Pass the RepairPackage value to the OOXML filter detection.
Change-Id: Ic958283f3cce92ac29ce93ac330cc9e409e3eb78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159976
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There is no need to do this, as the documentation of
css.lang.XComponent::dispose at
udkapi/com/sun/star/lang/XComponent.idl
states:
After this method has been called, the object should
behave as passive as possible, thus it should ignore all calls
Otherwise, the effect of throwing here is mostly to disturb the flow of
logic in caller code, preventing other parts of teardown from proceeding
smoothly.
Change-Id: I30e6d1b35f85b727debf4405a995fdc0a4fccde6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152450
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
==2515797== Conditional jump or move depends on uninitialised value(s)
==2515797== at 0x33FAB399: ZipFile::recover() (ZipFile.cxx:1090)
==2515797== by 0x33FA4D32: ZipFile::ZipFile(rtl::Reference<comphelper::RefCountedMutex>, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>, bool, bool) (ZipFile.cxx:111)
==2515797== by 0x33FEF134: void std::_Construct<ZipFile, rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&>(ZipFile*, rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool&&, bool&) (stl_construct.h:119)
==2515797== by 0x33FED528: void std::_Optional_payload_base<ZipFile>::_M_construct<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&>(rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool&&, bool&) (optional:278)
==2515797== by 0x33FEB73B: void std::_Optional_base_impl<ZipFile, std::_Optional_base<ZipFile, false, false> >::_M_construct<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&>(rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool&&, bool&) (optional:457)
==2515797== by 0x33FE77DB: std::enable_if<is_constructible_v<ZipFile, rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&>, ZipFile&>::type std::optional<ZipFile>::emplace<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&>(rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool&&, bool&) (optional:918)
==2515797== by 0x33FD61FD: ZipPackage::initialize(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (ZipPackage.cxx:760)
==2515797== by 0x64DE1EC: cppuhelper::ServiceManager::Data::Implementation::doCreateInstanceWithArguments(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (servicemanager.cxx:732)
==2515797== by 0x64DDF19: cppuhelper::ServiceManager::Data::Implementation::createInstanceWithArguments(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (servicemanager.cxx:694)
==2515797== by 0x64E0E8F: cppuhelper::ServiceManager::createInstanceWithArgumentsAndContext(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (servicemanager.cxx:1018)
==2515797== by 0x34A3B25F: OStorage_Impl::OpenOwnPackage() (xstorage.cxx:435)
==2515797== by 0x34A3C16C: OStorage_Impl::ReadContents() (xstorage.cxx:541)
==2515797== Uninitialised value was created by a stack allocation
==2515797== at 0x33FAB02C: ZipFile::recover() (ZipFile.cxx:1034)
since:
commit abda72eeac
Date: Mon Feb 20 00:32:22 2023 +0100
tdf#82984 tdf#94915 zip64 support (import + export)
where
- aEntry.nCompressedSize = nCompressedSize;
- aEntry.nSize = nSize;
was removed before the subsequent use of aEntry.nCompressedSize/aEntry.nSize
change things (git show -w for clarity) to check bounds first just for
the range the extra fields might be in and read those, and then follow
up with the original check that the newly discovered
aEntry.nCompressedSize/aEntry.nSize are within the bounds of the overall
file
Change-Id: Iad4ce8297109b06bc5baf77df4f3e86659cbb4cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150969
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Implemented import + export for "Zip64 Extended Information Extra Field",
(in "Local file header" and "Central directory file header")
and for Data descriptor.
Focused only to be able to handle files with over 4GB uncompressed size,
in the zip archive.
The 64k filecount, and the 4GB compressed size limit is probably still present
Tried to follow pkware .ZIP File Format Specification,
Some cases were not clear to me and/or some zip compressing tool may not
perfectly follow the standard, like 'extra field' should be 28 bytes long,
but its reader now can read shorter (or longer) 'extra field'.
Replaced some 32bit codes with 64bit codes, in stream handling, in deflater.
Tested with an ods file that contained a content.xml that bigger then 4BG+
(import + export + reimport) on windows.
I think 4GB+ files import/export would be too slow fot unittest.
So, for unit test, used the small but zip64 format files,
that was attached to the bugzilla tickets
Note: It helps with Bug 128244 too (1 of the unittest tests it),
but that ods file missing manifest.xml, so LO won't be able to import it.
Change-Id: Idfeb90594388fd34ae719677f5d268ca9a484fb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147306
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Michael Stahl