If the secret key doesn't match for the ec2 request, the exception
passed back to the user, showing the correct password.
# export EC2_ACCESS_KEY='oomNAG3AGwnlKDAM9gFe'
# export EC2_SECRET_KEY='anything'
InvalidSignature: Invalid signature
w6q++6lcvoEcBkcQuT1yNDURSpM8tq3a+WbhYeKWuX4= for user
User('nova', 'nova', 'oomNAG3AGwnlKDAM9gFe', 'eXTMGYDx7FhSI7ng3YfE', True).
i.e. the correct password is leaked back to the user if the incorrect password is given
CVE 2011-4076 is reserved for the issue
Although a serious security issue, it's actually quite unlikely anyone has Fedora 16 OpenStack deployed in a hostile environment - the default configuration does no password checking for this API and we haven't even written any instructions for configuring, or test cases for testing, the API with authentication enabled
(In reply to comment #1)
> Although a serious security issue, it's actually quite unlikely anyone has
> Fedora 16 OpenStack deployed in a hostile environment
Obviously, I forgot to include "*yet*" - we may well see such deployments, but I don't think any exist yet
Proposing as a F16 freeze exception since going ahead and shipping with such a security issue in a Fedora 16 Feature seems like a bad idea
openstack-nova-2011.3-6.fc16 has been submitted as an update for Fedora 16.
is this stuff actually on the dvd and included in any kind of selectable package set? if not, it really doesn't make much difference whether it 'makes the release' or goes out as an update.
The CVE identifier of CVE-2011-4076 has been assigned to this issue:
Note: Wasn't sure if security response bug is necessary also for
upcoming F-16 packages. Will know next time, thanks for
dealing with this one.
Discussed at 2011-10-28 NTH review meeting. Rejected as NTH as openstack is not on any release media so this can safely be fixed with a 0-day update, it does not need to go through the freeze.