This post will discuss some of my proposed architecture.

So this is what I envision the final process workflow will probably resemeble:

We can make use of OSLO components in several areas of the architecture. Additionally, we can make use of the new requirements project. And that would certainly be the goal.

The next post I make will contain a rough draft of a proposed schema design for the database.

SecStack in Havana

I am just back from Summit. Where I ran into a bunch of wonderful folks both new and old. OpenStack is getting awesome. The security front is about to get REALLY interesting. HP, Nebula, and a few others are showing serious interest in building out continuous integration methodology to help protect the OpenStack community. I’ll of course be doing my part.

And that’s where the flowchart comes in.

The image above is a variant of a traditional approach to a security audit of an application, basically modified for use in the OpenStack world. I’ll probably do some more work on this modeling as the year progresses and I get input from the OSSG and VMT.

Anyways, you can see that need for compiling an understanding of current known vulnerabilities and risks. This site kind of fills that gap. But to be blunt, it’s not good at it. When I was doing some data analysis for the summit, I realized that there was no single authoritative source for OpenStack threat resources. The OSSA’s are only released in e-mail and the e-mails themselves are not in a parseable format. They also have changed over time. In addition to that the CVEs don’t always have corresponding OSSAs, and vice versa. Currently there is very little in the way of decent attribute data for vulnerabilities that stem from secondary dependencies, and entire dependencies are untracked as far as the OpenStack community is concerned.

During the day job I have been helping with building out our OpenStack packaging toolchain. One of the things I need to do during a release cycle is to verify we have a fully patched package set. In addition to that we need to respond to OSSAs by patching many supported release package sets. As such I have begun to build such a database. As the project progresses I will share the code, the data, and I’ll stend up an experimental API. Hopefully by the end of the Havana release cycle I’ll have something that we can integrate into the OpenStack development cycle.

So I am probably going to begin laying off of the posting of OSSA vulnerabilities from here on out. However, I will begin releasing a comprehensive JSON set as I enter further into the investigation and cataloging of datasets. As part of that effort I will also be building tools to help me harvest that data.

Read on to the next section for further insight into this work effort.

As far as how this site is concerned. I’ll continue to highlight security concerns in the OpenStack community but I will do less copy-paste posting of OSSAs and CVEs. In fact, I have a couple of pending posts I need to finish writing for you guys.

In terms of Security in OpenStack. Havana stands to be a really break out release. I’m giddy with anticipation.

The OpenStack Vulnerability Database

A sample OpenStack CORE vulnerability datastructure: vulndb.json

I have exported a couple of CSV’s from that : here

I have a sample 3d.js render of one of the csv files here: here ( showing vulnerability reports by company )

This should wet your appetite for what I have planned.

The next steps are diagrammed here:

Basically, as you can see in the JSON I have already begun investigation and cataloging of datasets.

I am not happy with the schema I am currently working with. I’ll follow up this post with a new schema break out post as I get further along and solicit input from the community at large. AKA you and the OSSG.

Glossary

VMT

The VMT is the Vulnerability Management Team.

This is a VERY small team of trusted contributors whom receive new vulnerability reports. Currently there are three members of this team. New reports start out as embargo’ed. That is to say, if there isn’t a previously existing launchpad bug that is already public, a new security tagged bug will be created. Visibility of that bug will only be opened up to those folks who are brought in to help patch / fix the bug.

During the embargo period some vendors trusted contacts are informed of the vulnerability and provided access to patch sets that address the issue and will be merged later at time of public disclosure.

Eventually the bug is disclosed publicly in two formats. OpenStack releases an authoritative OSSA and will file corresponding CVEs if they do not exist already.

OSSG

The OSSG is the OpenStack Security Group.

While the VMT is a purely reactive security measure, the OSSG is a pro-active security measure.

The OSSG is a restricted team, meaning unlike the VMT it is not limited to a very small number of individuals. Currently there are 42 members. However, the team is gated for relevancy.

The OSSG performs many functions. They will assist the VMT at their pleasure as well as assist in the issuance of OSNs.

OSSA

An OSSA is an OpenStack Security Advisory. OSSA’s are issued by the VMT team and are intended to advise the OpenStack community of vulnerabilities as they occur and are addressed.

OSN ( OSSN )

An OSN or OSSN is an OpenStack Security Note. Security Notes addressing security concerns that do not justify an OSSA, or extend upon an OSSA providing further information for deployers and developers to help them avoid any potential security risks addressed therein.

CVE: CVE-2013-0335
Date: February 26, 2013
Title: VNC proxy can connect to the wrong VM
Reporter: Loganathan Parthipan (HP), Rohit Karajgi (NTT Data)
Products: Nova
Affects: All versions

Description:

Loganathan Parthipan (HP) and Rohit Karajgi (NTT Data) independently
reported a vulnerability in Nova. If a user requests a console and
then deletes the VM, it is possible that the console token could allow
connectivity to a different VM before the console token expires if the
VNC port gets reused in that time period. This issue can be worked
around by disabling VNC support.

Fixes:

• gerrit review ( master )
• gerrit review ( stable/folsom )
• gerrit review ( stable/essex )

References:

• CVE at Mitre
• Bug at Launchpad

Also and probably more helpful. I hopped into an existing devstack VM I had and pulled some epydoc output of some of the chief components of OpenStack.

Check them out here:

secstack.org/docs/

Autosustainable Services – PyCon Russia 2013 from Jeff Lindsay on Vimeo.

This presentation grew out of my shmoocon presentation. It’s a bit more of a deep dive into analytics that I’ve been putting together regarding Folsom security errata and general development stats as they relate to real world deployment models. Anyways, even if it doesn’t get chosen I’ll be dropping the data sets onto the OpenStack Security Group mailing list.

But if you want to see me rock it live on stage, vote!

Voting is only open to OpenStack Foundation Members.

A quick synopsis:

Folsom Security in Review

This talk is a break down of security concerns relating to the OpenStack Folsom Release. The purpose of this talk is to look at past vulnerabilities in Folsom, existing security models, and emerging technologies that will impact those models. The presentation will follow the flow of describing several deployment models in terms of their security attributes. The next phase will be the discussion of specific protocols in use and their individual security characteristics. I will present statistics on where past vulnerabilities have been found and reported allowing us to consider how we can better address security in our continuous integration processes. The goal of this talk is to present a map of where we are today, and expose some of the issues we have yet to face.

Learning about gating procedures is important in terms of risk assessment. You want to know how developers are vetting code and tagging releases to be sure that injecting nefarious bits of code into the project is well above non trivial.

Anyways. Enjoy the read!

This is the excerpt from the CFP proposal voting pool:

CVE: CVE-2013-1664, CVE-2013-1665
Date: February 19, 2013
Title: Information leak and Denial of Service using XML entities
Reporter: Jonathan Murray (NCC Group), Joshua Harlow (Yahoo!), Stuart
Stent
Products: Keystone, Nova, Cinder (see note)
Affects: All versions

Description:

Jonathan Murray from NCC Group, Joshua Harlow from Yahoo! and Stuart
Stent independently reported a vulnerabilities in the parsing of XML
requests in Python XML libraries used in Keystone, Nova and Cinder. By
using entities in XML requests, an unauthenticated attacker may consume
excessive resources on the Keystone, Nova or Cinder API servers,
resulting in a denial of service and potentially a crash
(CVE-2013-1664). Authenticated attackers may also leverage XML entities
to read the content of a local file on the Keystone API server
(CVE-2013-1665). This only affects servers with XML support enabled.

Note:

The vulnerabilities are actually in the various affected Python XML
libraries, but we provide OpenStack patches working around the issues.

Grizzly fixes:

• Gerrit Review Nova
• Gerrit Review Cinder
• Gerrit Review Keystone

Folsom fixes:

• Gerrit Review Nova
• Gerrit Review Cinder
• Gerrit Review Keystone

Essex fixes:

• Gerrit Review Nova
• Gerrit Review Keystone

References:

• Launchpad Bug Nova
• CVE at Mitre Nova
• Launchpad Bug Keystone
• CVE at Mitre Keystone

OpenStack Security Advisory: 2013-005

CVE: CVE-2013-0282
Date: February 19, 2013
Keystone EC2-style authentication accepts disabled user/tenants
Reporter: Nathanael Burton (National Security Agency)
Products: Keystone
Affects: All versions

Description:

Nathanael Burton reported a vulnerability in EC2-style authentication in
Keystone. Keystone fails to check whether a user, tenant, or domain is
enabled before authenticating a user using the EC2 api. Authenticated,
but disabled users (or authenticated users in disabled tenants or
domains) could therefore retain access rights that were thought removed.
Only setups enabling EC2-style authentication are affected. To disable
EC2-style authentication to work around the issue, remove the EC2
extension (keystone.contrib.ec2:Ec2Extension.factory) from the keystone
API pipeline in keystone.conf.

Grizzly fix:

• Gerrit Review

Folsom fix:

• Gerrit Review

Essex fix:

• Gerrit Review

References:

• Launchpad Bug
• CVE at Mitre