commit 2161e741da94b3ceb60cbd57a78643dd4169dfb7 Author: Mark Vitale Date: Mon Nov 7 14:16:50 2016 -0500 dir: do not leak contents of deleted directory entries Deleting an AFS directory entry (afs_dir_Delete) merely removes the entry logically by updating the allocation map and hash table. However, the entry itself remains on disk - that is, both the cache manager's cache partition and the fileserver's vice partitions. This constitutes a leak of directory entry information, including the object's name and MKfid (vnode and uniqueid). This leaked information is also visible on the wire during FetchData requests and volume operations. Modify afs_dir_Delete to clear the contents of deleted directory entries. Patchset notes: This commit only prevents leaks for newly deleted entries. Another commit in this patchset prevents leaks of partial object names upon reuse of pre-existing deleted entries. A third commit in this patchset prevents yet another kind of directory entry leak, when internal buffers are reused to create or enlarge existing directories. All three patches are required to prevent new leaks. Two additional salvager patches are also included to assist administrators in the cleanup of pre-existing leaks. [kaduk@mit.edu: style nit for sizeof() argument] Reviewed-on: https://gerrit.openafs.org/12460 Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit f591f6fae3d8b8d44140ca64e53bad840aeeeba0) Change-Id: I41f76649f4bed609793b944db32c5ae62aa07458 Reviewed-on: https://gerrit.openafs.org/12465 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 27515016cf92d0456b2a6e8a90758a02729f7407 Author: Benjamin Kaduk Date: Sun Nov 6 23:29:22 2016 -0600 afs: do not leak stale data in buffers Similar to the previous commit, zero out the buffer when fetching a new slot, to avoid the possibility of leaving stale data in a reused buffer. We are not supposed to write such stale data back to a fileserver, but this is an extra precaution in case of bugs elsewhere -- memset is not as expensive as it was in the 1980s. Reviewed-on: https://gerrit.openafs.org/12459 Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit a26c5054ee501ec65db3104f6a6a0fef634d9ea7) Change-Id: Id60559ed84581e2f6a50cd4313f64780b8a0bafd Reviewed-on: https://gerrit.openafs.org/12464 Reviewed-by: Michael Meffie Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Stephan Wiesand commit 82b681f594c84cd7f3d1874ae4506486e73aa496 Author: Benjamin Kaduk Date: Wed Nov 30 10:55:55 2016 -0600 Make OpenAFS 1.6.20 Update version strings for the 1.6.20 security release. Change-Id: I7f5ffa5e20173d399ed79dfb6358882caf05e27e Reviewed-on: https://gerrit.openafs.org/12467 Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand Tested-by: Stephan Wiesand commit 3fd2ed164658d1541fa3a52667effc66b6e2ee60 Author: Benjamin Kaduk Date: Wed Nov 30 09:28:18 2016 -0600 Update NEWS for 1.6.20 Change-Id: Id5bfbf5013f1ce7879473a1d40fea535314f6370 Reviewed-on: https://gerrit.openafs.org/12466 Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand Tested-by: Stephan Wiesand commit f234083a324085ebc7a2509b5878da5a3d10b956 Author: Mark Vitale Date: Fri May 13 00:01:31 2016 -0400 dir: fileserver leaks names of file and directories Summary: Due to incomplete initialization or clearing of reused memory, fileserver directory objects are likely to contain "dead" directory entry information. These extraneous entries are not active - that is, they are logically invisible to the fileserver and client. However, they are physically visible on the fileserver vice partition, on the wire in FetchData replies, and on the client cache partition. This constitutes a leak of directory information. Characterization: There are three different kinds of "dead" residual directory entry leaks, each with a different cause: 1. There may be partial name data after the null terminator in a live directory entry. This happens when a previously used directory entry becomes free, then is reused for a directory entry with a shorter name. This may be addressed in a future commit. 2. "Dead" directory entries are left uncleared after an object is deleted or renamed. This may be addressed in a future commit. 3. Residual directory entries may be inadvertently picked up when a new directory is created or an existing directory is extended by a 2kiBi page. This is the most severe problem and is addressed by this commit. This third kind of leak is the most severe because the leaked directory information may be from _any_ other directory residing on the fileserver, even if the current user is not authorized to see that directory. Root cause: The fileserver's directory/buffer package shares a pool of directory page buffers among all fileserver threads for both directory reads and directory writes. When the fileserver creates a new directory or extends an existing one, it uses any available unlocked buffer in the pool. This buffer is likely to contain another directory page recently read or written by the fileserver. Unfortunately the fileserver only initializes the page header fields (and the first two "dot" and "dotdot" entries in the case of a new directory). Any residual entries in the rest of the directory page are now logically "dead", but still physically present in the directory. They can easily be seen on the vice partition, on the wire in a FetchData reply, and on the cache partition. Note: The directory/buffer package used by the fileserver is also used by the salvager and the volserver. Therefore, salvager activity may also leak directory information to a certain extent. The volserver vos split command may also contribute to leaks. Any volserver operation that creates volumes (create, move, copy, restore, release) may also have insignificant leaks. These less significant leaks are addressed by this commit as well. Exploits: Any AFS user authorized to read directories may passively exploit this leak by capturing wire traffic or examining his local cache as he/she performs authorized reads on existing directories. Any leaked data will be for other directories the fileserver had in the buffer pool at the time the authorized directories were created or extended. Any AFS user authorized to write a new directory may actively exploit this leak by creating a new directory, flushing cache, then re-reading the newly created directory. Any leaked data will be for other directories the fileserver had in the buffer pool within the last few seconds. In this way an authorized user may sample current fileserver directory buffer contents for as long as he/she desires, without being detected. Directories already containing leaked data may themselves be leaked, leading to multiple layers of leaked data propagating with every new or extended directory. The names of files and directories are the most obvious source of information in this leak, but the FID vnode and uniqueid are leaked as well. Careful examination of the sequences of leaked vnode numbers and uniqueids may allow an attacker to: - Discern each layer of old directories by observing breaks in consecutive runs of vnode and/or uniqueid numbers. - Infer which objects may reside on the same volume. - Discover the order in which objects were created (vnode) or modified (uniqueid). - Know whether an object is a file (even vnode) or a directory (odd vnode). Prevent new leaks by always clearing a pool buffer before using it to create or extend a directory. Existing leaks on the fileserver vice partitions may be addressed in a future commit. Reviewed-on: https://gerrit.openafs.org/12458 Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Reviewed-by: Benjamin Kaduk (cherry picked from commit 70065cb1831dbcfd698c8fee216e33511a314904) Change-Id: Ifa9d9266368ed3775898b7628ca980edcb230356 Reviewed-on: https://gerrit.openafs.org/12463 Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Stephan Wiesand commit 30fbf5a5cc5dfdefa0ad64b488be22b9375e5b09 Author: Benjamin Kaduk Date: Sun Nov 6 15:06:02 2016 -0600 bos: allow salvage -salvagedirs with -all Allow the -salvagedirs option on bos salvage when invoked with the -all option to salvage the whole server. The -salvagedirs -all options will rebuild every directory on the server. Reviewed-on: https://gerrit.openafs.org/12457 Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 1637c4d7c1ce407390f65509a3a1c764a0c06aa6) [not actually cherry picked, but is the equivalent functionality] Change-Id: I3978a5c4a704e0a0f2aab1cfad75573c16496a4d Reviewed-on: https://gerrit.openafs.org/12462 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand commit d5f05cce7ffc61a3340509f94388421e3cf2522d Author: Michael Meffie Date: Sun Nov 6 14:31:22 2016 -0600 dafs: honor salvageserver -salvagedirs Do not ignore the -salvagedirs option when given to the salvageserver. When the salvageserver is running with this option, all directories will be rebuilt by salvages spawned by the dafs salvageserver, including all demand attach salvages and salvages of individual volumes initiated by bos salvage. This does not affect the whole partition salvages initiated by bos salvage -all. Reviewed-on: https://gerrit.openafs.org/12456 Reviewed-by: Mark Vitale Tested-by: Mark Vitale Reviewed-by: Michael Meffie Tested-by: BuildBot Reviewed-by: Benjamin Kaduk (cherry picked from commit 9e66234951cca3ca77e94ab431f739e85017a23a) Change-Id: I121299a5524cb46a519aead7818b0a7bd2fd4f69 Reviewed-on: https://gerrit.openafs.org/12461 Tested-by: BuildBot Reviewed-by: Michael Meffie Reviewed-by: Stephan Wiesand