https://bugs.documentfoundation.org/show_bug.cgi?id=174040
Bug ID: 174040
Summary: FILEOPEN DOCX: Agile-encrypted file using AES-256 with
SHA-1 is imported as plain text garbage, no password
prompt
Product: LibreOffice
Version: 26.8.1.1 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: filters and storage
Assignee: [email protected]
Reporter: [email protected]
Blocks: 108914
Created attachment 209171
--> https://bugs.documentfoundation.org/attachment.cgi?id=209171&action=edit
PDF produced by 26.8.1.1 from bug53475-password-is-pass.docx: 106 pages of
garbage
Description:
An Agile-encrypted .docx whose key data uses AES-256 with SHA-1 is not
recognised as encrypted. LibreOffice never asks for the password and imports
the encrypted container as plain text. The result is 106 pages of random
characters, and the load reports success. Supplying the correct password
changes nothing.
Cause: AgileEngine::readEncryptionInfo() (oox/source/crypto/AgileEngine.cxx,
around line 573) accepts only four cipher/hash pairs: AES-128 with SHA-1,
AES-128 with SHA-384, AES-192 with SHA-384, and AES-256 with SHA-512.
[MS-OFFCRYPTO] 2.3.4.10 allows other combinations, for example SHA-256, which
is not accepted with any key size. Office can be configured to write such
files, and other tools write them too (the test file below comes from Apache
POI's test suite). For any other pair readEncryptionInfo() returns false, and
type detection then falls through to the plain text filter instead of failing.
Two requests:
(a) accept AES-128/192/256 with SHA-1, SHA-256, SHA-384 and SHA-512;
(b) when a file carries encryption info that cannot be handled, fail with an
error rather than importing it as text.
Note for whoever widens the list: key and IV derivation copy keyBits/8 bytes
straight out of the hash (std::copy(hash.begin(), hash.begin() + keySize, ...)
at lines 280, 302, 500 and 886). With SHA-1 (20 bytes) and a 192 or 256 bit
key, that reads past the end of the hash. [MS-OFFCRYPTO] 2.3.4.11 says to pad a
short hash with 0x36 bytes. This is not reachable today, because those pairs
are rejected first.
The code is unchanged on master as of 2026-10-15 (commit 6e8329f204dd).
Steps to Reproduce:
1. Download bug53475-password-is-pass.docx from Apache POI's test data
(password: pass):
https://github.com/apache/poi/raw/REL_5_4_1/test-data/document/bug53475-password-is-pass.docx
sha256 c182f7825ae588fe1c28497588d1bded635a5bef7eb7370fd1c589233a6471d5
2. Load it and export to PDF.
Actual Results:
No password request. The load succeeds and the document is 106 pages of random
characters (PDF attached). The output is identical with and without the correct
password.
Expected Results:
LibreOffice asks for the password and opens the document. At minimum, loading
fails with an error saying the encryption is not supported. Encrypted bytes
should never be imported as text.
Reproducible: Always
Additional Info:
Observed through LibreOfficeKit (documentLoad, then saveAs pdf) on macOS arm64,
built from the unmodified 26.8.1.1 tag. Detection is shared code, so the
desktop app should behave the same.
Control: LibreOffice's own test file Encrypted_MSO2013_abc.docx (AES-256 with
SHA-512) asks for the password and opens correctly in the same setup.
Related: bug 166241 added AES-192 with SHA-384 as one more accepted pair; this
asks for the full matrix. Bug 148576 (Calc, Agile-encrypted XLSX that does not
open) may involve the same code.
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=108914
[Bug 108914] [META] Password protected file bugs and enhancements
--
You are receiving this mail because:
You are the assignee for the bug.
