Cinder throws detailed iSCSI information in case of failure

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?

Adding cinder-coresec to triage this bug report.

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?

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].

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 ).

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.

no objection from me, agree with above two views.

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

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.

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.

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