Open Stack

Two reasons

1. I think that some of your arguments (like long pw) were really 
unauthenticated not authenticated user arguments which can be used by 
any attackers, and

2. I think that a cloud service that offers free services to anyone with 
any email address is not really an authenticated user service, its more 
like a public service for everyone, where everyone is allowed to go back 
to their own specific stake in the cloud. So the users have not been 
identified and authenticated in any real sense.  Its an OpenID, level of 
assurance =1, type of service, where all the cloud can be assured of, is 
that is it probably the same user every time, but it has no idea of who 
this user is.

regards

David

On 22/05/2013 12:00, Clark, Robert Graham wrote:
> David,
>
> Can you elaborate on what you "don't buy", is it that authenticated user
> attacks aren't a problem or that something should be throttling their
> actions before they interact with keystone?
>
> On 22/05/2013 11:03, "David Chadwick" <d.w.chadwick at kent.ac.uk> wrote:
>
>> 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
>>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>