On 2020/5/5 下午5:26, Qu Wenruo wrote: > > > On 2020/5/5 下午4:11, Johannes Thumshirn wrote: >> On 04/05/2020 22:59, Eric Biggers wrote: >> [...] >> >>> But your proposed design doesn't do this completely, since some times of offline >>> modifications are still possible. >>> >>> So that's why I'm asking *exactly* what security properties it will provide. >> >> [...] >> >>> Does this mean that a parent node's checksum doesn't cover the checksum of its >>> child nodes, but rather only their locations? Doesn't that allow subtrees to be >>> swapped around without being detected? >> >> I was about to say "no you can't swap the subtrees as the header also >> stores the address of the block", but please give me some more time to >> think about it. I don't want to give a wrong answer. > > My personal idea on this swap-tree attack is, the first key, generation, > bytenr protection can prevent such case. > > The protection chain begins from superblock, and ends at the leaf tree > blocks, as long as superblock is also protected by hmac hash, it should > be safe. > > > Btrfs protects parent-child relationship by: > - Parent has the pointer (bytenr) of its child > The main protection. If attacker wants to swap one tree block, it must > change the parent tree block. > The parent is either a tree block (parent node), or root item in root > tree, or a super block. > All protected by hmac csum. Thus attack can only do such attach by > knowing the key. > > - Parent has the first key of its child > Unlike previous one, this is just an extra check, no extra protection. > And root item doesn't contain the first key. > > - Parent has the generation of its child tree block > This means, if the attacker wants to use old tree blocks (since btrfs > also do COW, at keeps tree blocks of previous transaction), it much > also revert its parent tree block/root item/superblock. > The chain ends at superblock, but superblock is never COWed, means > attacker can't easily re-create an old superblock to do such rollback > attack. > > Also btrfs has backup super blocks, backup still differs from the > primary by its bytenr. Thus attacker still needs the key to regenerate > a valid primary super block to rollback. > > But this still exposed a hole for attacker to utilize, the > usebackuproot mount option, to do such rollback attack. > > So we need to do something about it. >> >> [...] >> >>> Actually, nothing in the current design prevents the whole filesystem from being >>> rolled back to an earlier state. So, an attacker can actually both "change the >>> structure of the filesystem" and "roll back to an earlier state". >> >> Can you give an example how an attacker could do a rollback of the whole >> filesystem without the key? What am I missing? > > As explained, attacker needs the key to regenerate the primary > superblock, or use the usebackuproot mount option to abuse the recovery > oriented mount option. After some more thought, there is a narrow window where the attacker can reliably revert the fs to its previous transaction (but only one transaction earilier). If the attacker can access the underlying block disk, then it can backup the current superblock, and replay it to the disk after exactly one transaction being committed. The fs will be reverted to one transaction earlier, without triggering any hmac csum mismatch. If the attacker tries to revert to 2 or more transactions, it's pretty possible that the attacker will just screw up the fs, as btrfs only keeps all the tree blocks of previous transaction for its COW. I'm not sure how valuable such attack is, as even the attacker can revert the status of the fs to one trans earlier, the metadata and COWed data (default) are still all validated. Only nodatacow data is affected. To defend against such attack, we may need extra mount option to verify the super generation? Thanks, Qu > > The only attack I can thing of is re-generating the csum using > non-authentic algorithm, mostly in user space. > But it can be easily detected. > > Thanks, > Qu > >> >>> It very well might not be practical to provide rollback protection, and this >>> feature would still be useful without it. But I'm concerned that you're >>> claiming that this feature provides rollback protection when it doesn't. >> >> OK. >> >> [...] >> >>> The data on disk isn't trusted. Isn't that the whole point? The filesystem >>> doesn't trust it until it is MAC'ed, and to do that it needs the MAC algorithm. >> >> OK, will add this in the next round. >> >> Thanks, >> Johannes >> >
Attachment:
signature.asc
Description: OpenPGP digital signature
