[Openstack-security] Python Crypto libs Trustability

Travis McPeak Travis_McPeak at symantec.com
Thu Jun 5 19:58:54 UTC 2014


Hi all,

I¹ve been thinking about some of the crypto libraries that are being used
in OpenStack projects, specifically how much confidence should we have in
them.  It has occurred to me that we don¹t really know if they have been
audited, or even if anybody has taken a hard look at them.  We know that
security of a system is only as good as the weakest link, but what about
these backbones of security that we are relying on?  Have they been
vetted?  

I have started an etherpad:
https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very
issue.  Please contribute if you know anything about any of the libraries
listed.  If there are libraries that I haven¹t listed, please add them.

I think with the collective knowledge of the community, we can begin to
build some clarity around which libraries are more ³trustworthy² than
others, and how much we can trust them.

Thanks,
  -Travis




On 6/5/14, 5:00 AM, "openstack-security-request at lists.openstack.org"
<openstack-security-request at lists.openstack.org> wrote:

>Send Openstack-security mailing list submissions to
>	openstack-security at lists.openstack.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>or, via email, send a message with subject or body 'help' to
>	openstack-security-request at lists.openstack.org
>
>You can reach the person managing the list at
>	openstack-security-owner at lists.openstack.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Openstack-security digest..."
>
>
>Today's Topics:
>
>   1. [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation
>      for signing (Morgan Fainberg)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 04 Jun 2014 23:23:55 -0000
>From: Morgan Fainberg <morgan.fainberg at gmail.com>
>To: openstack-security at lists.openstack.org
>Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010]
>	Insecure directory creation for signing
>Message-ID: <20140604232358.27834.43216.launchpad at gac.canonical.com>
>Content-Type: text/plain; charset="utf-8"
>
>** Changed in: keystone/folsom
>       Status: Fix Committed => Fix Released
>
>-- 
>You received this bug notification because you are a member of OpenStack
>Security Group, which is subscribed to OpenStack.
>https://bugs.launchpad.net/bugs/1174608
>
>Title:
>  [OSSA 2013-010] Insecure directory creation for signing
>
>Status in OpenStack Identity (Keystone):
>  Invalid
>Status in Keystone folsom series:
>  Fix Released
>Status in OpenStack Compute (Nova):
>  Fix Released
>Status in OpenStack Compute (nova) folsom series:
>  Fix Committed
>Status in OpenStack Compute (nova) grizzly series:
>  Fix Released
>Status in OpenStack Security Advisories:
>  Fix Released
>Status in Python client library for Keystone:
>  Fix Released
>
>Bug description:
>  Originally found by Grant Murphy (gmurphy at redhat.com):
>
>  The signing directory is used to store the signing certificates
>  and the default location for this directory is:
>
>      signing_dir = /tmp/keystone-signing-nova
>
>  In the file:
>
>     keystone/middleware/auth_token.py
>
>  During the initialization of the AuthMiddleware the following
>  operations are made for the signing directory:
>
>      IF the directory exists but cannot be written to a configuration
>error is raised.
>      ELSE IF the directory doesn't exist, create it.
>      NEXT chmod permisions(stat.S_IRWXU) to the signing_directory
>
>  AFAICT The signing certificates used in validation will only be
>  fetched from the keystone if the cms_verify action raises an exception
>  because the certificate file is missing from the signing directory.
>
>  This means that if an attacker populated the /tmp/keystone-signing-nova
>  with the appropriate files for signautre verification they could
>potentially
>  issue forged tokens which would be validated by the middleware. As:
>      - The directory location deterministic. (default for glance, nova)
>      - *If the directory already exists it is reused*
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions
>
>
>
>------------------------------
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>End of Openstack-security Digest, Vol 16, Issue 10
>**************************************************





More information about the Openstack-security mailing list