Open Stack

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