[<prev] [next>] [day] [month] [year] [list]
Message-ID: <518AAADA.1060301@redhat.com>
Date: Wed, 08 May 2013 13:43:22 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: Open Source Security <oss-security@...ts.openwall.com>
Subject: When does resource consumption become a security vulnerability?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
When does resource consumption become a security vulnerability?
"It's not a tumour!"
Originally posted as
https://bugs.launchpad.net/nova/+bug/1175193/comments/9
Ok so this is one of those lovely grey areas of information security,
this is obviously a security related issue, but is this a security
vulnerability (requiring CVE and full security treatment) or is this a
security hardening issue (thus no CVE or full security treatment)?
So first let's look at trust boundaries. Now the end problem here is
that the database gets filled up by spurious log entries. What level
of access is needed to accomplish this? Luckily in this case it
requires authenticated access, this cannot be done as a non
authenticated user from what I am told (if this isn't true please let
us know ASAP!). As such if an anonymous user was able to remotely
flood the database that would be an obvious security problem, they
could kill the system remotely which usually falls into the category
of security vulnerability.
But in this case it requires authenticated access, and in general
users are allowed to consume system resources, however typically we do
not want to allow a single user, or even a group of users to consume
resources in a way that renders the system unstable or unusable. In
this case filling up the database has a very negative effect on the
system.
So this issue falls into the grey area of "is it security or
hardening?" and then further falls down the rabbit hole of "how much
and how quickly do we allow a user to consume system resources before
we call it a security vulnerability?" So clearly the amount of data
logged has a significant impact on this. For example if each
pause/unpause/etc action generated say a megabyte of logged data this
would be extremely easy to use to fill up the database (even a large
database would fill quickly at 1meg/entry). In this case it's
approximately 1k per entry, which is enough to make it interesting,
assuming a few gigabytes are available then it would take some time
for the attacker to exploit this enough times to cause a problem.
Additionally because it requires authenticated access it is easy to
track down who did it and censor them (e.g. tell them not to do it,
remove their account, whatever).
So with this in mind I am inclined to classify this as a security
hardening issue, and not a security vulnerability. This may of course
change if new information comes to light (e.g. unauthenticated access
allows exploitation, or the amount of data logged per entry can be
increased somehow).
Now a note on fixing this: there are several strategies used in
logging systems to deal with attacks like this. The first one is a
classic syslog "the last message was repeated X times", this allows
multiple identical log entries to be consolidated quickly and easily,
reducing the amount of logging space required and can work well with
flooding attacks. The second strategy is to rotate and archive the
logs once they hit a certain size (log files typically compress really
well). Of course neither of these solutions will completely stop
resources from being used, but they will reduce the amount of some of
the resources used (e.g. disk space) at the cost of CPU time (to
rotate/compress logs).
There are other solutions that will prevent resources from being
abused, but will compromise the integrity of the data available, e.g.
using a ring buffer per user (log the last 10000 events and then
overwrite the oldest event once you get more than 10000). This would
allow an attacker to attack the system in ways that are typically
logged, and then cause the log of these activities to be overwritten
by executing 10000 non malicious logged events for example. You can
also trade off availability for logging data, for example by blocking
actions that can't be logged because the logging is full or has
failed. I suspect in almost every use case instance of OpenStack this
is not an acceptable trade off.
TLDR: this is probably security hardening and not a security flaw. We
should fix it by rotating the database entries out and compressing
them, as configured by the user.
- --
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)
iQIcBAEBAgAGBQJRiqraAAoJEBYNRVNeJnmTXS0P/25Eswo3r4/xeOZYoDEFtlk3
WTnnlN8HECFu/6uxZ3XEUcKz9VTL+de23A0Fk3vYf9mwqTmE60d9AO2tIiLH5E7r
337593rjxOR0dpmmybIx92p4PGtLids0QszQ2FcoqiubClq7gJ3yNS4S1uih3n3z
pJkdnr7kflIJwUy4v4nbB/JUdE9GtGI8ukgZyTgbJHSmMvVQ5A6lJ7uS8bjOTPp9
GH8R/TBwRxYTORwDBMa7itCeFkSejWMxl+s84TpYQUGXRj8433oTtjbZe9lOZIe6
26ldWR5JvVHbzdTtwoh2/TVej2nUR4oyiG7pCqscMMcsJGCMfjAwmLosHO0jspOU
DnvFAUcU3WukAxljZqNDrg1QPOH3BahkraBSlBub7jq25fInGjryaDRYKfj0tiVz
XXb1lPDe7TOoW0Mc7nky97geJQA6Z9AsNixWjwRaCrVLeC+7ZPGz0sFNFfNY4uFk
PQ9XRmKTwWwUDBM88KZAEWjD8oIMxbnIlFBBprOH2GESLIY0DPOtN0vtinH4Vl8n
yinypRzSKVni0ykP4+L0anHe2jLsTjwHmAPXtW3VTXMUyQMTlD7stLI3xdHVovr1
vapw7q5c7R52pIGp34Xpq4Oj1rvOW4DnDxqa+w7LBNAJ49YZcIKj0cDx6rNyshK/
kmtK9QBs7TZ3GMTAOuJ3
=5Dy6
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
