Open Stack

Hi Kurt
Whilst I dont buy into your arguments about authenticated users causing 
DOS problems, we have detected the password processing problem that you 
mention ie.
" when I log into OpenStack and enter a huge password the CPU time used 
to process that password doesn't run as my user ". We have noticed that 
processing times increase massively for long passwords. But I would see 
this as a potential DOS attack from an unauthenticated user who is 
simply using large random passwords with known usernames, rather than a 
DOS attack from an authenticated user.

regards

David

On 22/05/2013 09:14, Kurt Seifried wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/13/2013 07:11 AM, Simo Sorce wrote:
>> On Sun, 2013-05-12 at 18:31 +0000, Clark, Robert Graham wrote:
>>> Generally speaking "A DoS from an authenticated user" is a
>>> _massive_ concern for anyone who has a cloud with unaccountable
>>> users, such as shared clouds and for public clouds in
>>> particular.
>>
>> Authenticated users usually have many many ways to cause excessive
>> use of resources.
>>
>> If you are concerned about an authenticated user causing DoS I
>> think the right answer is to look at rate limiting and a monitoring
>> system that reports which users are abusing the system. It's easy
>> to (auto?)terminate accounts that are misbehaving. A completely
>> different class than anonymous DoS.
>>
>> simo.
>
> Two quick notes:
>
> 1) There is resource usage, and then there is resource usage. For
> example Linux allows me to use cgroups to limit what a user can do in
> some cases like memory/cpu usage. Obviously if this can be bypassed
> that would be a problem, which leads to point #2:
>
> 2) In situations like keystone/etc the user is causing code/etc to be
> run as another user. E.g. when I log into OpenStack and enter a huge
> password the CPU time used to process that password doesn't run as my
> user, it runs as whatever keystone uses. So if we apply limits to
> keystone we just end up making it easier often times for a user to DoS
> keystone (as opposed to the whole server).
>
> And depending on the exact nature of the flaw we may or may not have a
> useful audit trail (e.g. if a user has to connect repeatedly and send
> mangled data that will show up, but something like the XML hashdos
> might just be one request).
>
> Also the whole term "authenticated users" has bothered me for a long
> time. It used to be pretty simple, users either paid you to get
> access, or ere given access because they were part of the organization
> (e.g. an employee, a student, whatever). So yeah, if someone did
> something silly you could go club them. But now many services have
> free signups (openshift.redhat.com, all you need is a valid email
> address for example) or have massive numbers of users (e.g. a cloud
> provider) that are not vetted, and not heavily invested (e.g. I can
> signup for an account for free at most cloud providers, and trigger
> things like login DoS's without spending any money). So "authenticated
> user" is no longer a silver bullet.
>
> And no, its not always easy to auto terminate an account that is
> behaving badly. for one thing you have to know which account it is,
> and even then, what if it is a paying customer who claims they got
> compromised? You generally don't want to annoy paying customers to
> much or make it impossible for them to continue paying =).
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
>
> iQIcBAEBAgAGBQJRnH5gAAoJEBYNRVNeJnmTH5sQALMBvmzjVIfUzGUStyivZxBj
> tB+jTgGTIwSTH6pXDk/sFODUZqK6N/xADH9rKyvPBTW8FOLz2p5dvMgHHTp4iPu3
> lThvpRXbdraAgT4ZhJE46Ymh6fgEW1hOeQKhsymTKYyRJZg58ZUrKVqLvsbYT8hf
> gNQfMe8UZiGRJEX6hFUH+autfkOygy7CtZ4nll5MvGQY1pgH8ESNHjEvnDV6I0Lg
> BNk4qud3oD23TfG3/z8NSgnvDsYWFpxgFr5/21SZN7za0/dR2V4H3WvjI8bsinz0
> nJ14Fu1zMWwFgby4IKzcHsQKPG1RMExMXf4lj3iBYPYIT9yS+KSw4YpK0HvSSApJ
> //1lf9KPZPF5KhNI9Q6oapBHuRTIUwOT5ssV6lqKAdKsa88kJL5Lx5+X9ITUA1Cg
> /sXZ3sMbW9/Oz9xevanN6vKDiXuqDBgFyZkSHWWxs1Upo+mTwvlKwpsu7VYOsCub
> eZohFBnV5KtUfdgR99CkjBjyGP1nH6F5uWy7Wzv9WiqzKtxYtat5RfRHekWdOq4h
> 0drEcC4PgPRaKeKEMRg3s8iUEJ8rI7PzqJxZ7LEqdzTLZbNVRXMspUfa/QzO1CA7
> 6uNXRjT5xDefm7Cb7OIXk0uQl820fMhrSG7MyUMlARYZKRFGG89iGdRpct+9+yf4
> caq9u3qlBK4YbvNH8oSc
> =d2n1
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>