OpenStack Object Storage (swift)

Bug #1157454
Comment #8

Comment 8 for bug 1157454

Revision history for this message

David Hadas (david-hadas) wrote on 2013-03-20: Re: Swift exposed to hash collision attacks

The attack vectors I found, much with the help of the discussion in 2011, are:

1. A user allowed access to a container/account/tenant may create a planned collision and sue the provider for loss of data

2. A user with access to the system may produce large amount of objects/containers/accounts that will be placed on a specific device creating a DoS attack.

3. A user with access to a container may create an object that is an alias of a different object of the same tenant thus overriding the ACLs of the aliased object and gaining full control over the object (read/change/delete).

4. A user with access to an account (account owner) may create a container that is an alias of a different container thus overriding the ACLs of the aliased container and gaining full control over the container (e.g. change its ACLs).

In attacks 1,2 - the user has control over both aliases that need to collide
There are known and efficient MD5 attacks allowing to create aliases either if no prefix is used or when the prefixes of both aliases are known.
This attack can be mitigated by a secret prefix.
This attack is not affected by a secret suffix as used in Swift today.
Attack 1 also requires the user to come forward and account for his actions (i.e. show that this was not a deliberate attack) - this seems like an attack that can be contained reasonably well.
Attack 2 is a DoS attack and not a threat to user data. Swift requires some level of disk monitoring anyhow and when a given disk fills up beyond a reasonable level (compared to others), the admin need to be alarmed and investigate - again, this seems like an attack that can be contained reasonably well.

In attacks 3 and 4 - the user has control over one alias and may try to collide with a specific object or with any object in the system.
There are no known MD5 preimage attacks (need to reconfirm this) that allow colliding with a given fully qualified name efficiently (without shire brute force).
Yet, as the number of objects increase the birthday paradox may yield an increased chance of collision.
There is no immediate risk here even when a prefix is not used.

The attack vectors I found, much with the help of the discussion in 2011, are:

1. A user allowed access to a container/account/tenant may create a planned collision and sue the provider for loss of data

2. A user with access to the system may produce large amount of objects/containers/accounts that will be placed on a specific device creating a DoS attack.

3. A user with access to a container may create an object that is an alias of a different object of the same tenant thus overriding the ACLs of the aliased  object and gaining full control over the object (read/change/delete).

In attacks 1,2 - the user has control over both aliases that need to collide
There are known and efficient MD5 attacks allowing to create aliases either if no prefix is used or when the prefixes of both aliases are known. 
This attack can be mitigated by a secret prefix.  
This attack is not affected by a secret suffix as used in Swift today. 
Attack 1 also requires the user to come forward and account for his actions (i.e. show that this was not a deliberate attack) - this seems like  an attack that can be contained reasonably well. 
Attack 2 is a DoS attack and not a  threat to user data. Swift requires some level of disk monitoring anyhow and when a given disk fills up beyond a reasonable level (compared to others), the admin need to be alarmed and investigate - again, this seems like  an attack that can be contained reasonably well.

In attacks 3 and 4 - the user has control over one alias and may try to collide with a specific object or with any object in the system. 
There are no known MD5 preimage attacks (need to reconfirm this) that allow colliding with a given fully qualified name efficiently (without shire brute force). 
Yet, as the number of objects increase the birthday paradox may yield an increased chance of collision. 
There is no immediate risk here even when a prefix is not used.