Bug 491254 - (CVE-2009-0787) CVE-2009-0787 kernel: ecryptfs file header infoleak
CVE-2009-0787 kernel: ecryptfs file header infoleak
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 491255 491256
  Show dependency treegraph
Reported: 2009-03-19 23:46 EDT by Eugene Teo (Security Response)
Modified: 2013-04-08 13:31 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-08 13:31:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed upstream patch (4.55 KB, patch)
2009-03-20 02:56 EDT, Eugene Teo (Security Response)
no flags Details | Diff
Upstream patch (5.08 KB, patch)
2009-03-23 00:35 EDT, Eugene Teo (Security Response)
no flags Details | Diff

  None (edit)
Comment 4 Eugene Teo (Security Response) 2009-03-20 00:29:46 EDT
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.

Comment 5 Eugene Teo (Security Response) 2009-03-20 00:43:25 EDT
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.
Comment 6 Eugene Teo (Security Response) 2009-03-20 02:56:29 EDT
Created attachment 335965 [details]
Proposed upstream patch
Comment 8 Eugene Teo (Security Response) 2009-03-23 00:35:31 EDT
Created attachment 336239 [details]
Upstream patch
Comment 10 Tomas Hoger 2009-03-25 07:31:14 EDT
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:


Further information about its use is in the upstream bug report:


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.
Comment 11 Eugene Teo (Security Response) 2009-05-05 23:12:44 EDT
More info: http://kbase.redhat.com/faq/docs/DOC-16748
Comment 12 errata-xmlrpc 2009-05-07 06:53:21 EDT
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

Note You need to log in before you can comment on or make changes to this bug.