Bug 576359 (CVE-2010-0743)

Summary: CVE-2010-0743 scsi-target-utils: format string vulnerability
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Josh Bressers <bressers>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: bressers, jrusnack, mchristi, mjc, qe-baseos-daemons, rmusil
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-04 21:06:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 578536, 578537, 578539    
Bug Blocks:    
Attachments:
Description Flags
patch to correct the format string flaws none

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-6.2.0.870-8.fc11: (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-6.2.0.870-10.fc12.1: (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-6.2.0.871-0.10.el5: (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