Bug 576359 (CVE-2010-0743) - CVE-2010-0743 scsi-target-utils: format string vulnerability
Summary: CVE-2010-0743 scsi-target-utils: format string vulnerability
Alias: CVE-2010-0743
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Josh Bressers
QA Contact:
Depends On: 578536 578537 578539
TreeView+ depends on / blocked
Reported: 2010-03-23 21:42 UTC by Vincent Danen
Modified: 2019-09-29 12:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-04 21:06:09 UTC

Attachments (Terms of Use)
patch to correct the format string flaws (727 bytes, patch)
2010-03-23 21:49 UTC, Vincent Danen
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Debian BTS 574935 0 None None None Never
Red Hat Product Errata RHSA-2010:0362 0 normal SHIPPED_LIVE Important: scsi-target-utils security update 2010-04-20 15:54:36 UTC

Description Vincent Danen 2010-03-23 21:42:52 UTC
A Debian bug report [1] reported two remotely exploitable format string vulnerabilities in iscsitarget.  We do not provide iscsitarget, but similar code exists in scsi-target-utils (isns.c):

rqs 0.3 ($Id: rqp 349 2010-03-19 23:05:04Z vdanen $)

Searching database records for substring match on files ("/isns.c")

Results in Tag: f11

iscsi-initiator-utils- (source) open-iscsi-2.0-870.1.tar.gz: open-iscsi-2.0-870.1/usr/isns.c
scsi-target-utils-0.9.5-1.fc11: (source) tgt-0.9.5.tar.bz2: tgt-0.9.5/usr/iscsi/isns.c

Results in Tag: f12

iscsi-initiator-utils- (source) open-iscsi-2.0-870.1.tar.gz: open-iscsi-2.0-870.1/usr/isns.c
scsi-target-utils-0.9.5-3.fc12: (source) tgt-0.9.5.tar.bz2: tgt-0.9.5/usr/iscsi/isns.c

Results in Tag: rhel5

iscsi-initiator-utils- (source) open-iscsi-2.0-871-test4.bnx2i.tar.gz: open-iscsi-2.0-871-test4.bnx2i/usr/isns.c
scsi-target-utils-0.0-5.20080917snap.el5: (source) tgt-20080917.tar.bz2: tgt-20080917/usr/iscsi/isns.c

The problem is a few snprintf() statements that don't use format strings (there are 3 in total in this file in iscsitarget, only 1 of which is correct). Checking to see if the same issues are in the RHEL5 iscsi-initiator-utils yielded nothing (one correct use):

% grep snprintf usr/isns.c
snprintf(port, sizeof(port), "%d", isns_port);

Unfortunately, this does affect scsi-target-utils:

% grep snprintf usr/iscsi/isns.c
snprintf(mgmt->name, sizeof(mgmt->name), name);
snprintf(ini->name, sizeof(ini->name), name);
snprintf(port, sizeof(port), "%d", isns_port);

It is unclear to me whether this is remotely exploitable, but the Debian report implies that it is.  With our format string protections, this would not result in arbitrary code execution, but in a denial of service (crash) condition.  This also affects the version shipped with Fedora 12, so I presume Fedora 11 would be vulnerable to this as well.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574935

Comment 2 Vincent Danen 2010-03-23 21:49:12 UTC
Created attachment 402153 [details]
patch to correct the format string flaws

Comment 4 Vincent Danen 2010-03-27 00:26:34 UTC
Bumping up the impact of this issue.

As I understand the problem, this code is present in the tgtd daemon has several roles that are done in a single process, of which the important ones are that it serves up scsi/block data to scsi clients and also has an iSNS client that talks to an iSNS server.  When a client registers to an iSNS server, the server tells other clients about it (the new client), and also tells clients when another client appears/disappears (which is where the flaw resides).

Because there is no separation between these tasks, if a client is killed due to this flaw, there is no way for it to continue serving scsi/block data to other clients.

While this flaw is not exploitable for arbitrary code execution, the format string protection renders this into a denial of service, which means the tgtd daemon will segfault.  This also means that any clients connected to it will not be able to access scsi/block data.  Ultimately, if that were to happen, those _other_ clients could potentially throw a kernel panic.  If they do not panic, they could lose data or eventually hang.  There are various factors involved that determine how a client will handle not being able to access a disk, but if they cannot reconnect then there is a very real possibility of lost/corrupt data or a kernel panic (similar to a locally-attached hard drive crashing).

I am unaware as to whether there are ACLs determining what hosts can talk to tgtd in order to control who has access to the daemon.  If there are, these could be used as a mitigation.  I also noted AV:N vs AV:L due to the fact that some documentation I looked at briefly suggest that iSCSI is useful over the internet meaning it could potentially not be restricted to a LAN or trusted machines.

Comment 5 Mike Christie 2010-03-27 03:23:22 UTC
(In reply to comment #4)
> I am unaware as to whether there are ACLs determining what hosts can talk to
> tgtd in order to control who has access to the daemon.

There are ACLs defined in the specs but tgtd does not implement them.

Comment 20 michal novacek 2010-04-14 15:16:36 UTC
Code review: patch is included in source rpm (scsi-target-utils-0.0-6.20091205snap.el5_5.2.src.rpm) as scsi-target-utils-snprintf-fix.patch.

Comment 21 michal novacek 2010-04-14 15:45:12 UTC
I tried the scenario described in Comment #8 and verified that we do not hit the problem any more.

Comment 22 errata-xmlrpc 2010-04-20 15:54:39 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0362 https://rhn.redhat.com/errata/RHSA-2010-0362.html

Note You need to log in before you can comment on or make changes to this bug.