Cinder throws detailed iSCSI information in case of failure

[Adam Heczko]

Apologies for vague bug report but I think this should be reported anyway:

When for some reason iSCSI attachment fails Cinder (or Nova) throws detailed iSCSI information including cloud internal Cinder volume IP address and volume details.
Observed this while operating on Nova instances with Cinder volumes using Horizon.
OpenStack Liberty or Mitaka.

Such detailed iSCSI message reported to end user through Horizon UI is considered as a security violation.

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

What are the information leaked with the volume details? Can you please provide an example error message with the relevant log detail to help us diagnose this issue?

[Tristan Cacqueray (tristan-cacqueray)]

Adding cinder-coresec to triage this bug report.

[Walt Boring (walter-boring)]

Volume attachments can fail at many different points. They can fail in Cinder, Nova or os-brick. Can we get some more specific information here that shows a stack trace with some filtered output? If there is a place in os-brick that needs to be addressed, the stack will help me here.

The log files seems like an ok place to have this information dumped, or an admin will never be able to determine what went wrong.

Horizon shouldn't ever show this error information. Do we have screenshots of these examples?

[Adam Heczko (aheczko-mirantis)]

This example message is displayed as pop up in Horizon, Mitaka release:
Error: Failed to perform requested operation on instance "osbackup", the instance has an error status: Please try again later [Error: Unexpected error while running command. Command: sudo nova-rootwrap /etc/nova/rootwrap.conf scsi_id --page 0x83 --whitelisted /dev/disk/by-path/ip-172.31.1.16:3260-iscsi-iqn.2010-10.org.openstack:volume-a0069ddf-f99d-48bf-932f-fe2ad5a7aa2e-lun-1 Exit code].

[Tristan Cacqueray (tristan-cacqueray)]

While this pop up could be trimmed, I don't think it warrants an advisory nor to be kept private. I suggest a class C1 or D according to VMT's taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).

[Jeremy Stanley (fungi)]

If all that's being exposed is internal implementation architecture of the iSCSI environment and not sensitive credentials, I agree this looks like a security hardening opportunity. If nobody objects before Friday of this week, we should switch it to public.

[Luke Hinds (lhinds)]

no objection from me, agree with above two views.

[Tristan Cacqueray (tristan-cacqueray)]

Switched to public and closed the OSSA task based on above comments.

[Sean McGinnis (sean-mcginnis)]

That horizon error message is bubbling up from Nova, so I think this would need to be addressed there to not include the underlying os-brick error details.

[Matt Riedemann (mriedem)]

What is an "osbackup" operation? Nova doesn't support creating backups of volume-backed instances so I don't think it would be that.

I have no idea where this is failing in nova, especially if it's liberty or mitaka w/o logs. Are there details on a recreate here or some logs to help with this?

Is Horizon pulling the 'fault' information out of the instance and exposing that? The fault should only be viewable for admins by default.

I'm going to mark this as incomplete as I really need more information here about what was being done and logs if at all possible.

[Sean Dague (sdague)]

Automatically discovered version liberty in description. If this is incorrect, please update the description to include 'nova version: ...'