[Openstack-security] [OSSN] Draft: Nova Baremetal Exposes Previous Tenant Data
Kurt Seifried
kseifried at redhat.com
Tue Jul 2 19:15:27 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/02/2013 01:06 PM, Jeremy Stanley wrote:
> On 2013-07-02 12:53:34 -0600 (-0600), Kurt Seifried wrote:
>> Huh? According to: https://wiki.openstack.org/wiki/Baremetal
>>
>> "This driver was added to the Grizzly release, but it should be
>> considered somewhat experimental at this point. See the Bugs
>> section for information and links to the Launchpad bug
>> listings."
>>
>> also no mention of any security issues with respect to data not
>> being wiped. Now I get that the software hasn't been officially
>> blessed as production ready, but it has been released publicly.
>> Unless there isa compelling reason not to assign a CVE for this
>> (speak up now!) I'll do so later today.
>
> I agree it's unfortunate if security precautions weren't spelled
> out in the release notes, so if that qualifies for a CVE then it
> sounds like we probably do need one. In your opinion would it have
> needed a CVE if the situation were spelled out in the release notes
> already?
If the documentation specifically said "WARNING: DATA MAY BE EXPOSED
DUE TO LACK OF WIPING" then no CVE most likely. It's a continuum, but
basically some examples:
=======================
http://seclists.org/oss-sec/2013/q1/155
Further note, for example:
A default account/password in a device or service. Is this a security
issue or not? Different scenarios have different outcomes:
1) The default account/password is well documented. The services
forces you to change the password when first run and will refuse to
run until you do change the password. Generally not considered a vuln.
2) The default account/password is well documented. The services does
not force you to change the password when first run. Generally not
considered a vuln as it falls into the "don't do stupid things" class
of issues.
3) The default account/password is not well documented or not
documented at all but can be changed. Generally this would be
considered a vulnerability.
4) The default account/password is not well documented or not
documented at all and can NOT be changed. Generally this would be
considered a vulnerability.
Similar things for other things, is it a security vulnerability or
security hardening, or not a security issue at all? It definitely gets
fuzzy/messy sometimes.
=======================
So this looks like a #4, not documented, not something that can easily
be fixed by the user.
> I suppose this drives to a process question for us as a project,
> whether we can actually develop work-in-progress/experimental
> features in-tree with a timed release schedule, knowing that we
> may need to consider either (dangerously) ripping them back out at
> release time or announcing known security vulnerabilities in them
> at release time instead.
That is a good question. One thing that might be helpful is to mark
such code as experimental/dangerous/may eat all your datas and include
any potential gotchas to warn people about, which is probably a good
idea either way as it would reduce risk, or if not that at least let
people make informed decisions about the risk they are taking.
- --
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)
iQIcBAEBAgAGBQJR0ybPAAoJEBYNRVNeJnmTMOMQAJnhG3tJ/6AoM7wptHLYT+P0
k1RAILsNqWsK213IqL+mpnVlVMqj4NllJyokSejbfywTaFpw0kq9il4BHmr/5k9F
BeXJLBjUicuqaylyTp+dQbKADgViIpAuw703RTO5Irumugmrqcr/Pj6a2e4JGeY9
d6MN0plPEaiKSNUX4H/wyqthzwpfx1OIv9BHhY1geHgZUpxsLGeE0aGxGab91Vwv
SPetHIpB9QqzV9TKFWvTDPWxFU2xU/56mEe/WOqCRdrSh29/ki3zisdCAyvM2ry/
14pDWKFKJDY7OiKx9OnbSFeGf7mH6Si8YfAOxeQU+fe39dPMaZJNxY415pE8Zh0F
p5RWZ7mTGkxGwemk2E11ODUKM9iKmJuWaE8pgIGEVncoJqOLiFCPU5wl97zChHeq
Xiz//CYS7ZklMuvboxIM8knp9eHdFpiLp2h4ELDCNHv807uYNaWptRvlP1Zhyq9u
obqLQP/V9Bb/2HSmqLbOpVsacIZp/BQY/cnjCGERwMA17psY1ggl8NT89exSjop9
jXonYuNoe21Z5Fjh+C50hkBpREBKXTcgk2jKpX2+dSLz/M0japctKCoguc2yCGWl
nzrNLi9l87i/d9bintdMdX/qhREwwb938xnvkfVRFc05XTqEcm+vrLLu0Y5pW76K
G0Hh7vc2TXLY3OygOygX
=lC0m
-----END PGP SIGNATURE-----
More information about the Openstack-security
mailing list