{"action":"opened","issue":{"url":"https://api.github.com/repos/hashicorp/vault/issues/844","labels_url":"https://api.github.com/repos/hashicorp/vault/issues/844/labels{/name}","comments_url":"https://api.github.com/repos/hashicorp/vault/issues/844/comments","events_url":"https://api.github.com/repos/hashicorp/vault/issues/844/events","html_url":"https://github.com/hashicorp/vault/issues/844","id":121892968,"number":844,"title":"rekey can be bait-and-switched","user":{"login":"hashbrowncipher","id":124699,"avatar_url":"https://avatars.githubusercontent.com/u/124699?v=3","gravatar_id":"","url":"https://api.github.com/users/hashbrowncipher","html_url":"https://github.com/hashbrowncipher","followers_url":"https://api.github.com/users/hashbrowncipher/followers","following_url":"https://api.github.com/users/hashbrowncipher/following{/other_user}","gists_url":"https://api.github.com/users/hashbrowncipher/gists{/gist_id}","starred_url":"https://api.github.com/users/hashbrowncipher/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hashbrowncipher/subscriptions","organizations_url":"https://api.github.com/users/hashbrowncipher/orgs","repos_url":"https://api.github.com/users/hashbrowncipher/repos","events_url":"https://api.github.com/users/hashbrowncipher/events{/privacy}","received_events_url":"https://api.github.com/users/hashbrowncipher/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-12-13T02:10:48Z","updated_at":"2015-12-13T02:10:48Z","closed_at":null,"body":"When an unseal key is submitted to /sys/rekey/update, there is no guarantee that it will update any particular rekey operation.  Since rekey is unauthenticated, this makes it possible for someone to initialize a rekey with \"correct\" parameters, and then delete the rekey and reinitialize with \"trapped\" parameters.\r\n\r\n1. Share-holders a rekey.\r\n2. Share-holders check the rekey parameters, and agree that they are correct\r\n3. An attacker deletes the rekey and reinitializes, supplying their own PGP key.\r\n4. t or more shareholders update the trapped rekey\r\n5. The new key shares are now encrypted to the attacker's key.  The attacker can now extract secrets from the physical backend.\r\n\r\nSuggested fix: associate a nonce with each rekey operation, and require rekey updates to specify that nonce."}}