Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
While looking through the source code for spice-xpi I ran across this print:
448: sprintf (mdData.name, "/tmp/spice.%d.uds", m_child_pid);
449: m_external_controller = new SpiceController(mdData);
It appears that if a local attacker is able to create a socket with the expected name, they could steal the password which is later sent over this socket.
Therefore, we would classify this as having moderate security impact.
Version-Release number of selected component (if applicable):
[ogvura@ogvura ~]$ rpm -q spice-client
spice-client-0.6.3-2.el6_0.3.x86_64
[ogvura@ogvura ~]$ rpm -q spice-xpi
spice-xpi-2.4-1.el6.x86_64
Steps to Reproduce:
1. Connect via the spicec to the VM.
2. Open the Spice Client Log.
Actual results:
We can see the exact location of the file.
Expected results:
This should be worked around by using something like mkdtemp to create a
temporary directory then placing the socket in there.
Need to change the
Additional info:
spice-client version -0.6.3-2.el6_0.3
Please see attached Logs.
(In reply to comment #0)
> ...
> While looking through the source code for spice-xpi I ran across this print:
>
> 448: sprintf (mdData.name, "/tmp/spice.%d.uds", m_child_pid);
> 449: m_external_controller = new SpiceController(mdData);
>
> ...
>
> Version-Release number of selected component (if applicable):
> [ogvura@ogvura ~]$ rpm -q spice-client
> spice-client-0.6.3-2.el6_0.3.x86_64
> [ogvura@ogvura ~]$ rpm -q spice-xpi
> spice-xpi-2.4-1.el6.x86_64
Are you really sure that you are looking into the source of afforementioned builds? This issue is actually CVE-2010-2792 and is fixed in RHEL6 (see bug #620447 && bug #620444); it is also fixed in the builds you mention (verified it via source code inspection).
The problem is actually with the unix domain socket connecting the spice-client
and the spice-usb-share (usbrdrctrl).
in foreign_menu.cpp:
28 #ifdef WIN32
29 #define PIPE_NAME "SpiceForeignMenu-%lu"
30 #elif defined(__i386__)
31 #define PIPE_NAME "/tmp/SpiceForeignMenu-%llu.uds"
32 #else
33 #define PIPE_NAME "/tmp/SpiceForeignMenu-%lu.uds"
34 #endif
From the logs Ortal attached (and Uri's post) it is clear that it's bug #639855. The issue OP is talking about is already fixed:
1289753155 INFO [7844:7844] Controller::Controller: Creating a controller connection /home/ogvura/.spice/spice-084Lot
usbrdrctl predictable UDS name has no security consequences on *nix as no sensitive data are transferred.
Description of problem: While looking through the source code for spice-xpi I ran across this print: 448: sprintf (mdData.name, "/tmp/spice.%d.uds", m_child_pid); 449: m_external_controller = new SpiceController(mdData); It appears that if a local attacker is able to create a socket with the expected name, they could steal the password which is later sent over this socket. Therefore, we would classify this as having moderate security impact. Version-Release number of selected component (if applicable): [ogvura@ogvura ~]$ rpm -q spice-client spice-client-0.6.3-2.el6_0.3.x86_64 [ogvura@ogvura ~]$ rpm -q spice-xpi spice-xpi-2.4-1.el6.x86_64 Steps to Reproduce: 1. Connect via the spicec to the VM. 2. Open the Spice Client Log. Actual results: We can see the exact location of the file. Expected results: This should be worked around by using something like mkdtemp to create a temporary directory then placing the socket in there. Need to change the Additional info: spice-client version -0.6.3-2.el6_0.3 Please see attached Logs.