From oss-security Wed Jun 18 20:42:33 2014 From: "Vincent Danen" Date: Wed, 18 Jun 2014 20:42:33 +0000 To: oss-security Subject: [oss-security] Re: CVE request: multiple /tmp races in ppc64-diag Message-Id: <97957A64-A04D-4384-ABBA-17DC89709DFF () redhat ! com> X-MARC-Message: https://marc.info/?l=oss-security&m=140312417618709 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--=_MailMate_684D414F-4B2B-4A25-B179-1623650138C6_=" --=_MailMate_684D414F-4B2B-4A25-B179-1623650138C6_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 06/16/2014, at 23:17 PM, cve-assign@mitre.org wrote: >> https://bugzilla.novell.com/show_bug.cgi?id=3D882667 >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1109371 > > >> In the case of rtas_errd/prrn_hotplug, mktemp is used but is assumed >> to have succeeded; there is no check for the return value. > > Are you reporting this as a prrn_hotplug vulnerability? If it were a > vulnerability, it would have a separate CVE ID. We didn't test the > code, but it looks more like an opportunity for a non-security > enhancement or maybe a bug fix. Our guess is: > > 1. If the return value is nonzero, stdout is an empty string. > > 2. All of the ">> $TMPFILE" will fail, and won't write anything into > any file. > > 3. The outcome is that /var/log/prrn_log doesn't have log > information about what happened. We don't know of any direct > security implications. > > 4. Possibly the code should check the return value and print > something like "mktemp failed - maybe you're out of /tmp disk > space?" but it might be better to let the rest of the script run > anyway (i.e., not abort after that error condition). > > At least for now, there is no CVE ID for prrn_hotplug. That sounds fine to me. >> I don't know if the data in /tmp/diagSEsnap is sensitive or not > > mkdir "/tmp/diagSEsnap", 0775; > $general_eed_file =3D "/tmp/diagSEsnap/snapH.tar.gz"; > system("/usr/sbin/snap -o $general_eed_file 2>/dev/null 1>&2"); > > This seems to be similar to the CVE-2014-3925 sosreport issue. > snapH.tar.gz apparently will include /etc/fstab and therefore might > include a password. > http://www.ibm.com/support/entry/portal/docdisplay?lndocid=3DMIGR-54819= > says "When you report a problem to IBM Technical Support, run the snap > utility and send the ... file to them." In addition, snapH.tar.gz > apparently will include /var/log/messages, which traditionally is not > supposed to be a world-readable file. > > (snap and sosreport aren't derivatives of the same code.) > > Also, the question of whether "/usr/sbin/snap -o $general_eed_file" is > exploitable may depend on the behavior of snap. Apparently, snap does > check whether the -o output file exists but doesn't avoid TOCTOU > problems. Arguably, snap isn't responsible for avoiding TOCTOU > problems because it's not inherently designed for use with untrusted > output filenames. > > So, three CVEs seems to be the right number here. > > The ppc64-diag unsafe uses of temporary directories in these three > scenarios: > > "> /tmp/get_dt_files" [ in rtas_errd/diag_support.c ] > > mkdir "/tmp/diagSEsnap", 0775; > $general_eed_file =3D "/tmp/diagSEsnap/snapH.tar.gz"; > system("/usr/sbin/snap -o $general_eed_file 2>/dev/null 1>&2"); > [ in scripts/ppc64_diag_mkrsrc ] > > TMP_DIR=3D"/var/tmp/ras" > mkdir -p $TMP_DIR > MESSAGE_FILE=3D"$TMP_DIR/messages" > [ in lpd/test/lpd_ela_test.sh - see Novell bug 882667 ] > > are primarily of interest because of symlink following, and are all > assigned CVE-2014-4038. > > A second CVE for the ppc64-diag product is for the choice of weak > directory/file permissions for the snapH.tar.gz archive including data > that is not locally world-readable (e.g., /var/log/messages). This is > CVE-2014-4039. > > A third CVE, CVE-2014-4040, is assigned for snap itself. snap can be > found at http://sourceforge.net/projects/powerpc-utils (i.e., it's not > part of the ppc64-diag product). This CVE is the one analogous to > http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2014-3925 (i.e., it= > includes the "cleartext passwords ... lacks a warning" rationale). > > CVE-2014-4039 and CVE-2014-4040 are vulnerabilities in different > products and can be addressed independently. For example, snapH.tar.gz > could have restrictive local permissions and still be sent to a remote > destination without review. Alternatively, snapH.tar.gz could continue > to have weak local permissions but snap could require the user to > acknowledge a warning about off-site distribution of an fstab > password, etc. Great, thanks for this. -- = Vincent Danen / Red Hat Product Security --=_MailMate_684D414F-4B2B-4A25-B179-1623650138C6_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQGcBAEBAgAGBQJTofm8AAoJEJS+gzzouGyrZFoL/2O+SKCFWwa6vpTqsNrHicjT G4mbKFRSBXwHEaBu/sgD7a14Bn+xR3FnENpEVMbx3hg2px3kUp6ghMDB7PcLi6Yf cFdAd/nO/hwAuCDELU4xdk9hvM4a2RN+Dhuzxe4nGN/XLwci823SxmarV6GpaRr1 +MrcM4/rHtqWqdHIlUF9FHj+WJjdqpwqjNSt26LlEnFAxgHjmNG90YG+tJsNY71u ZQ5o//BZPTwvsVW4fKvcEZLpyeKIJZ9p0Xtil+aXkDJtGFar+dpkw92d4wa/gdyP 8BKwhhZjYeOvSzbtemZ2zE6ysGba5FBga9BFewM6CeKqmPJ7jQuOgUb9FkUT6S2U p2oINBebh2yBUi6ng8yLAHWimwzkRkfA1UtigdXmXCpUmeaM2AEY9/TCeWrPT2CV Rn8eW0nS+alFmZel3j9enmSa7FRb213MECYLh9rGf7PcZSjCv9+hi1Bz2j80mA5R 4fpoK+nj/nKsflIQa7PaxrWSCI0Op6cRfgZ44N2/aQ== =tSSs -----END PGP SIGNATURE----- --=_MailMate_684D414F-4B2B-4A25-B179-1623650138C6_=--