Security risk of clients having access to vector clocks

Jon Meredith jmeredith at basho.com
Fri Jan 18 09:35:48 EST 2013


There is no equivalent of an SQL injection attack on the vector clock. 

If the client is able to tamper with it the only three issues I can think of are

1) deliberately corrupting it so that the put operation crashes which would end up with a timeout. If the application required the store and did not check before continuing it could be a problem. 

2) a more sophisticated version would replace the vector clock with one that was considered an ancestor which would generate a sibling if allow mult is set yes. If you didn't resolve then you could make large objects. 

3) similarly you could add fake entires to the clock which would make more work for the resolution code and slow things down until the clock was truncated by riak. 

If successfully decoded the information contained is a list of tuples with an 8 byte vnode id, and update count and a last update fine for the vnode.   The only information leak I can see is an estimate of the number of updates. 

Jon

On Jan 17, 2013, at 7:29 PM, Gregory Haskins <gregory.haskins at gmail.com> wrote:

> 
> On Jan 17, 2013, at 9:06 PM, Brian Picciano <dustfinger1 at gmail.com> wrote:
> 
>> Are there any ways we could combat this?
> 
> I can't comment on what might be at risk from a Riak perspective, but as a general comment you could combat client-side tampering using crypto (perhaps you have already considered this option, I am not sure). 
> 
> For instance, you could attach an HMAC to the vector clock before returning it client side as a token, and then validate the HMAC when the token is passed back to you in the future.  This will add overhead for both generating and validating the token, but it could alleviate exposure against db tampering.  (Note that an HMAC alone will not protect you from replay of a previously issued vclock+HMAC, however.  For that you will need to be more clever).  Generally, I prefer to handle this stuff server side attached to the session, which I know isn't "RESTful", but it is easier to solve the security problems this way.
> 
> Good luck!
> -Greg
> 
> 
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com




More information about the riak-users mailing list