Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2013 12:41 AM, Clark, Robert Graham wrote:
> So I think two things probably need to happen here. One is a
> further discussion on how 'dangerous' code should be tagged in
> future, the second is if this needs a CVE.
> 
> In regard to the latter I don't think there's a big reason _NOT_ to
> cut a CVE but I'm not passionate about it either way. What I would
> like is some agreement so if there is a CVE I can reference it in
> the OSSN and if there isn't I can just go ahead and publish.

Since no-one seems to object, and we have a history of cve's for not
wiping disk before usage in these kinds of situations please use
CVE-2013-2235 for this issue.

> 
> Cheers -Rob
> 
> On 02/07/2013 20:15, "Kurt Seifried" <kseifried at redhat.com> wrote:
> 
> 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.
> 
>> 
>> _______________________________________________ 
>> Openstack-security mailing list 
>> Openstack-security at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>> 
- -- 
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)

iQIcBAEBAgAGBQJR09SwAAoJEBYNRVNeJnmTvKUP/AqlQ1xXuTz3SQymNsgCauTF
j6ApQ5B+X8AOl7ugmVMe/01rbiiMPb6P3mb2fLZyDCJ9uZjnuWw+xeFUd8GbWcCN
2mFGWCl/CpShUXe1NnH5emfs2Jx/a99dw8nmsPtStk2H/tu3PUkrUQF2WYYFDhDB
VcOIHim+HiBLLmKAzIgHDEA79Et18o7O3OqgCx3OtlpTxBtIQWiQGWVy1cdP8iBm
Ab52Tr9bvqj/QHMo2U7mcnlx40/FYJcQWjJs6jKva4VhzEdXwX0u2rymjTgi2hY4
kXwwEJX33qmsTHbSuRdtZcmDAhEf31oX8J60rdOFY1bq3hIJSPBBIaIBNM/BN9sD
540FvJBnWml+S2y1CTo+GnH3Xzcn2THd4uhjyo67ubuE2Ju9cqXFTypoXTJfR3NU
avL+9A9HReers5CXVLbLMDz50sj23/hQuJGnSp4gN53m8K9sI1kLM/3FpqR1OAIv
d0xI3yXG4EUPfG3oPVAMg1a+O4jlvOyY3B8zOOtozlqXgqOsbinqReyWKNeN/ZaS
MODOqfh9mPMkklN1EikrcJPFJJvo5mGNwmFiCTIIMbyex+bOs5+QM47SuPtsY3mY
S3nFDcEWXjwREyG2WZapJNYWUAtVxCrOxncWDgncS3DPbSINUxOcq+qF0cXut+H8
a6Yv7dz7n5MrrsC31Zjk
=ybb/
-----END PGP SIGNATURE-----