They report that various vendors are affected, but its likely
that our iscsitarget is affected as well. Could you check?

Date: Tue, 29 Jun 2010 10:28:59 -0600
From: Vincent Danen <vdanen@redhat.com>
To: vendor-sec@lst.de

We had reported to us two buffer overflow flaws in scsi-target-utils and
upon further investigation, upstream found two more.  We have also
identified that IET and SCST are affected by these issues
(iscsi-initiator-utils is not).

We have assigned CVE-2010-2221 to this issue.

Unfortunately, when dealing with one of the upstream projects they
committed a fix to their public svn so the embargo we had hoped to set
has been cut quite short.  The other upstream projects will be
committing fixes shortly (they had initially wanted to tomorrow, but I'm
requesting they hold off until 20100701 14:00 UTC).

The first two flaws were found by the Vulnerability Research Team at
TELUS Security Labs, the second two flaws were found by Fujita Tomonori
(from scsi-target-utils).

Describing in reverse because TELUS' report is longer (included below in
its entirety).  Fujita's comments for the second two overflows:

"print_scn_pdu() and qry_rsp_handle() wrongly assume that tlv->length is
sane.  Sending invalid tlv->length pdu can crash the target. This patch
fixes it."

I'm attaching patches for scsi-target-utils (should apply to STSC and
IET without too much difficulty), and the reproducer tool Fujita
provided, with wrappers, to assist in testing.

My apologies for the short notice, but with this public already, we are
stuck with a short embargo.  The SCST commit that is public is here:

http://scst.svn.sourceforge.net/viewvc/scst?view=revision&revision=1793

The report from TELUS Security Labs follows:

- Title:

iSCSI target Multiple Implementations Stack Buffer Overflow

- Affected Vendor:
iSCSI Enterprise Project
tgt project (scsi-target-utils)
SCST project
Red Hat Software

- Tested Affected Products:

RHEL Cluster-Storage (v. 5 server)
scsi-target-utils-0.0-6.20091205snap.el5_5.2

- Affected Components:

tgtd

- Vulnerability Details:
iSCSI Initiators can locate appropriate storage resources using the Internet
Storage Name Service (iSNS) protocol. This protocol allows automated
discovery,
management and configuration of iSCSI devices on a TCP/IP network. The iSNS
standard is defined by its four components: the iSNS protocol, iSNS clients,
iSNS servers and iSNS databases. It provides four services:

* Name Registration and Storage Resource Discovery: iSCSI targets and
initiators can register with the iSNS database, and inquire about other
initiators and targets.

* Discovery Domains and Login Control: administrators can use the Discovery
Domains to divide storage nodes into manageable, non-exclusive groups.

* State Change Notification (SCN): allows an iSNS Server to issue
notifications
about each event that affects storage nodes on the managed network.

* Bidirectional Mappings Between Fibre Channel and iSCSI Devices.

The structure of an iSNS message is as follows:

Offset Size Description
--------------------------------------------------------------------
0x0000 2 bytes Version
0x0002 2 bytes Message Type
0x0004 2 bytes Length N
0x0006 2 bytes Flags
0x0008 2 bytes Transaction ID
0x000A 2 bytes Sequence ID
0x000C N bytes Payload


iSCSI initiators will query the iSNS server to discover the presence and
location of iSCSI target devices. iSCSI targets allow themselves to be
discovered by iSCSI initiators by registering their presence with the iSNS
server. After registration an iSCSI target may also register for SCNs in
order
to detect the addition or removal of initiators, the iSCSI target will open a
random TCP port in order to receive the SCNs from the iSNS server.

One of the types of iSNS messages is an SCN message, the Message Type for
this
message is 0x0008 and its payload has the following structure:

Offset Size Description
--------------------------------------------------------------------
0x0000 4 bytes Attribute Tag
0x0004 4 bytes Attribute Length N
0x0008 N bytes Attribute

ne of the types of supported attributes is Name, the Attribute Tag for a
Name
attribute is 32 (0x00000020).

A stack buffer overflow vulnerability exists in multiple implementations of
iSCSI target. The vulnerability is caused by missing bounds checks when
handling SCN messages. The vulnerable code prepares the reply packet by
copying
iSCSI Name into the fixed-length stack buffer. When the iSCSI Name string is
longer than 1008 bytes, the buffer overflows that could lead to corruption of
sensitive stack data such as function return addresses.

Following is the vulnerable source code, comments added by TELUS Security
labs.

static void send_scn_rsp(char *name, uint16_t transaction)
{
char buf[1024]; // Fixed length stack buffer
struct isns_hdr *hdr = (struct isns_hdr *) buf; // Here and further: cast
pointers
struct isns_tlv *tlv;
uint16_t flags, length = 0;
int err;

memset(buf, 0, sizeof(buf));
*((uint32_t *) hdr->pdu) = 0;
tlv = (struct isns_tlv *) ((char *) hdr->pdu + 4);
length +=4;

length += isns_tlv_set_string(&tlv, ISNS_ATTR_ISCSI_NAME, name); // Copy
string
to stack buffer

[... truncated/reordered for readability ...]

static int isns_tlv_set_string(struct isns_tlv **tlv, uint32_t tag, char
*str)
{
return isns_tlv_set(tlv, tag, strlen(str) + 1, str); // Copy string based on
src string length
}

[... truncated/reordered for readability ...]

static int isns_tlv_set(struct isns_tlv **tlv, uint32_t tag, uint32_t length,
void *value)
{
if (length)
memcpy((*tlv)->value, value, length); // Buffer overflow here


--
Vincent Danen / Red Hat Security Response Team