[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210113154006.GF13248@suse.de>
Date: Wed, 13 Jan 2021 16:40:06 +0100
From: Marcus Meissner <meissner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2020-28374: Linux SCSI target (LIO)
unrestricted copy offload
Hi,
For tcmu-runner Mitre suggested that we use a different CVE as its not the same codebase.
Please use CVE-2021-3139 for tcmu-runner.
Ciao, Marcus
On Tue, Jan 12, 2021 at 07:01:34PM +0100, David Disseldorp wrote:
> ===============================================================================
> == Subject: Linux SCSI target (LIO) unrestricted copy offload
> ==
> ==
> == CVE ID#: CVE-2020-28374
> ==
> == Versions: Linux: v3.12 and later
> == tcmu-runner: v1.3.0 and later
> ==
> == Summary: An attacker with access to a LUN and knowledge of Unit Serial
> == Number assignments can read and write to any LIO backstore,
> == regardless of SCSI transport settings.
> ===============================================================================
>
>
> Description
> -----------
> SCSI "EXTENDED COPY" (XCOPY) requests sent to a Linux SCSI target (LIO) allow an
> attacker to read or write anywhere on any LIO backstore configured on the
> host, provided the attacker has access to one LUN and knowledge of the victim
> backstore's vpd_unit_serial (AKA "wwn"). This is possible regardless of the
> transport/HBA settings for the victim backstore.
> - with vhost-scsi this can allow VM guests to read or write to images assigned
> to other qemu processes
> - with iSCSI this allows CHAP, ACL and network portal isolation bypass
> - backstores with no corresponding transport LUN mapping remain vulnerable
> - all other LIO transports and backstores which allow for XCOPY processing by
> LIO's target_core_xcopy handler should be considered vulnerable
> - tcmu-runner based user backstores are also vulnerable via a similar logic bug
>
> This is due to the way that LIO behaves when processing XCOPY
> copy-source/copy-destination (CSCD) descriptors; when attempting to match
> CSCD descriptors with corresponding se_devices, target_xcopy_locate_se_dev_e4()
> iterates over LIO's global devices list, which includes all configured
> backstores, instead of only considering backstores which are exposed to the
> initiator via transport layer ACL settings.
>
> Similarly, when LIO is configured to forward SCSI requests to the user-space
> tcmu-runner daemon (via target_core_user), tcmu-runner's xcopy_locate_udev()
> iterates over all tcmu-runner devices, without considering any transport layer
> restrictions.
>
>
> Exploitation
> ------------
> The attacker sends an XCOPY request with two CSCD descriptors.
> One CSCD descriptor must correspond to the NAA IEEE identifier for the LUN to
> which the attacker has access. The other (victim) CSCD descriptor must be an
> NAA IEEE identifier which matches another configured backstore within LIO's
> global device inventory.
>
> For successful exploitation of this bug an attacker must be able to provide a
> matching NAA identifier for the victim backstore.
>
>
> Affected Versions
> -----------------
> Linux Kernel (LIO target_core_xcopy)
> - Exploitable as of
> f99715ac8d6f ("target: Enable global EXTENDED_COPY setup/release")
> + mainline v3.12-rc1 and later
>
> tcmu-runner (user-space SCSI target, coupled with LIO's target_core_user)
> - Exploitable as of 9c86bd0db97a ("tcmur: Add emulate XCOPY command support")
> + tcmu-runner v1.3.0 and later
>
>
> Relevance
> ---------
> Linux kernel LIO deployments are affected under the following conditions:
> - Linux kernel with f99715ac8d6f, i.e. mainline v3.12-rc1 or later
> - LIO SCSI target (target_core_mod) loaded
> - at least two configured backstores
> - one "attacker backstore" must be exposed via a SCSI transport (e.g. iSCSI)
> which permits access to a potential attacker
> + the attacker backstore must allow and use in-kernel LIO XCOPY command
> emulation
> - all backstores except special "pscsi" passthrough and "user" types
> - emulate_3pc=1 must be set (default)
> - one or more "victim backstores" must be configured
> + transport settings for victim backstores are irrelevant
> + all backstore types are vulnerable, including "iblock", "fileio", "rd_mcp",
> "pscsi" and "user"
> + emulate_3pc=1 must be set the victim backstore (default)
>
> tcmu-runner deployments are affected under the following conditions:
> - tcmu-runner with 9c86bd0db97a, i.e. v1.3.0 or later
> - one "attacker backstore" must be exposed via a SCSI transport (e.g. iSCSI)
> which permits access to a potential attacker
> - one or more "victim backstores" must be configured
> + transport settings for victim backstores are irrelevant
> + the victim backstore must also be managed by the same tcmu-runner instance
> - e.g. an XCOPY request to a "user"+tcmu-runner backstore can't be used to
> read or write to an "iblock" backstore, only to other backstores handled
> by the same tcmu-runner instance.
>
>
> Mitigation
> ----------
> Caveat: instructions below do *not* affect XCOPY requests sent to tcmu-runner
> based backstores. They are only suitable for disabling kernel
> (target_core_xcopy) support for XCOPY requests.
>
> Requires acb3f2600eb8 ("target: Reject EXTENDED_COPY when emulate_3pc is disabled")
> - v3.12-rc7 or later
>
> XCOPY support is enabled by default, but can be disabled via:
> echo 0 > /sys/kernel/config/target/core/<backstore>/<name>/attrib/emulate_3pc
> or
> targetcli /backstores/<backstore>/<name> set attribute emulate_3pc=0
>
> ...where <backstore> and <name> should be filled appropriately.
>
>
> Fixes
> -----
> Linux kernel and tcmu-runner fixes will be provided following the coordinated
> release date: 2021-01-12 10:00 Pacific Standard Time.
>
>
> Credits
> -------
> Research and patches by David Disseldorp of SUSE.
> Patch review by Mike Christie of Oracle, and Lee Duncan of SUSE.
>
--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meissner@...e.de>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
