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
Created attachment 402153 [details] patch to correct the format string flaws
This is now fixed upstream: http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=commitdiff;h=107d922706cd36f3bb79bcca9bc4678c32f22e59
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.
(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.
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.
I tried the scenario described in Comment #8 and verified that we do not hit the problem any more.
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