Security risk of clients having access to vector clocks

Brian Picciano dustfinger1 at gmail.com
Fri Jan 18 12:53:03 EST 2013


Awesome, thank you so much for the help everyone!

On Fri, Jan 18, 2013 at 9:35 AM, Jon Meredith <jmeredith at basho.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130118/01d9ba47/attachment.html>


More information about the riak-users mailing list