Page MenuHomePhabricator

Store and verify content integrity checksums for files
ClosedPublic

Authored by epriestley on Apr 5 2017, 4:56 PM.
Tags
None
Referenced Files
F13211491: D17625.diff
Fri, May 17, 5:48 AM
F13209404: D17625.diff
Thu, May 16, 11:57 PM
F13196724: D17625.diff
Sun, May 12, 11:30 PM
F13183840: D17625.diff
Fri, May 10, 12:43 PM
Unknown Object (File)
Mon, May 6, 10:17 PM
Unknown Object (File)
Sun, May 5, 12:39 PM
Unknown Object (File)
Fri, May 3, 6:42 AM
Unknown Object (File)
Thu, Apr 25, 7:08 AM
Subscribers
None

Details

Summary

Ref T12470. This helps defuse attacks where an adversary can directly take control of whatever storage engine files are being stored in and change data there. These attacks would require a significant level of access.

Such attackers could potentially attack ranges of AES-256-CBC encrypted files by using Phabricator as a decryption oracle if they were also able to compromise a Phabricator account with read access to the files.

By storing a hash of the data (and, in the case of AES-256-CBC files, the IV) when we write files, and verifying it before we decrypt or read them, we can detect and prevent this kind of tampering.

This also helps detect mundane corruption and integrity issues.

Test Plan
  • Added unit tests.
  • Uploaded new files, saw them get integrity hashes.
  • Manually corrupted file data, saw it fail. Used bin/files cat --salvage to read it anyway.
  • Tampered with IVs, saw integrity failures.

Event Timeline

This revision is now accepted and ready to land.Apr 5 2017, 5:25 PM
This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.

(That double-tap was me manually re-running the task to sort something else out, not a bug.)