It was discovered that the xfs_metadump tool of the xfsprogs suite did not fully adhere to the standards of obfuscation described in its man page. In case a user with the necessary privileges used xfs_metadump and relied on the advertised obfuscation, the generated data could contain unexpected traces of potentially sensitive information.
Gabriel Vlasiu reported that xfs_metadump, part of the xfsprogs suite of tools for the XFS filesystem, did not properly obfuscate data. xfs_metadump properly obfuscates active metadata, but the rest of the space within that fs block comes through in the clear. This could lead to exposure of stale disk data via the produced metadump image.
The expectation of xfs_metadump is to obfuscate all but the shortest names in the metadata, as noted in the manpage:
By default, xfs_metadump obfuscates most file (regular file, directory and
symbolic link) names and extended attribute names to allow the dumps to
be sent without revealing confidential information. Extended attribute values
are zeroed and no data is copied. The only exceptions are file or attribute
names that are 4 or less characters in length. Also file names that span
extents (this can only occur with the mkfs.xfs(8) options where -n size > -b
size) are not obfuscated. Names between 5 and 8 characters in length
inclusively are partially obfuscated.
While the xfs_metadump tool can be run by unprivileged users, it requires appropriate permissions to access block devices (such as root) where the sensitive data might be dumped. An unprivileged user, without access to the block device, could not use this flaw to obtain sensitive data they would not otherwise have permission to access.
Upstream patches will be available at https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/
Fixed upstream in xfsprogs v3.2.4:
This issue is not about local users being able to access restricted data via xfs metadumps. In order to be able to generate such a dump, local users need to have the appropriate access permissions to the block device, so this does not cross any security boundaries in that regard.
This issue is about users generating a metadump image via xfs_metadump and then sharing it with 3rd parties (for example for debugging purposes), relying on the xfs_metadump functionality to obfuscate potentially sensitive details. This obfuscation functionality did not work as advertised in the manpage, thus it may be possible that sensitive information is leaked as part of the metadata dump.
If in doubt, do not share xfs_metadump dumps with untrusted 3rd parties.
xfsprogs-3.2.2-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
xfsprogs-3.2.4-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
xfsprogs-3.2.2-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2015:2151 https://rhn.redhat.com/errata/RHSA-2015-2151.html