Reported by Florian Streibelt. When allocating the memory used to store the eCryptfs header contents, a single, zeroed page was being allocated with get_zeroed_page(). However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is stored in the file's private_data->crypt_stat->num_header_bytes_at_front field. ecryptfs_write_metadata_to_contents() was using num_header_bytes_at_front to decide how many bytes should be written to the lower filesystem for the file header. Unfortunately, at least 8K was being written from the page, despite the chance of the single, zeroed page being smaller than 8K. This resulted in random areas of kernel memory being written between the 0x1000 and 0x1FFF bytes offsets in the eCryptfs file headers if PAGE_SIZE was 4K. The vuln was introduced in upstream commit 87b811c3f9, and it affects upstream kernels version 2.6.28 onwards. Reference: https://bugs.launchpad.net/ecryptfs/+bug/345544
eCryptfs is a Technology Preview feature in Red Hat Enterprise Linux 5.3, and it is not a default configuration - http://markmail.org/message/n2acz2wv7b5xkb2o.
Created attachment 335965 [details] Proposed upstream patch
It's public now: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8faece5f906725c10e7a1f6caf84452abadbdc7b
Created attachment 336239 [details] Upstream patch
Encrypted files that were created on systems running vulnerable version of the ecryptfs may contain leaked data in the ecryptfs file headers. ecryptfs-utils upstream developers created a script that can be used to re-encrypt files inside of ecryptfs mount by making a temporary copy of the file and replacing original with the copy, causing the file to be re-created / re-encrypted on the lower ecryptfs filesystem too. Script is available in the ecryptfs-utils source code repository: http://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/annotate/head:/src/utils/ecryptfs-rewrite-file http://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/annotate/head:/doc/manpage/ecryptfs-rewrite-file.1 Further information about its use is in the upstream bug report: https://bugs.launchpad.net/ecryptfs/+bug/345544/comments/5 This approach, however, has limitations, as ecryptfs files and mounts are under the control of the individual users. Script is meant to be used on files inside of an ecryptfs mount. Therefore, it can not be used to fully "resolve" the consequences this leak under all circumstance, as non-privileged users can not use it to remove "their" data leaked into other users' ecryptfs files, and system administrators can only use it on ecryptfs mounts that are mounted or have pass phrases known to them. This script may appear in the future updates of the ecryptfs-utils packages.
More info: http://kbase.redhat.com/faq/docs/DOC-16748
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:0473 https://rhn.redhat.com/errata/RHSA-2009-0473.html