[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE request: multiple /tmp races in ppc64-diag
From:       "Vincent Danen" <vdanen () redhat ! com>
Date:       2014-06-18 20:42:33
Message-ID: 97957A64-A04D-4384-ABBA-17DC89709DFF () redhat ! com
[Download RAW message or body]

On 06/16/2014, at 23:17 PM, cve-assign@mitre.org wrote:

>> https://bugzilla.novell.com/show_bug.cgi?id=882667
>> https://bugzilla.redhat.com/show_bug.cgi?id=1109371
>
>
>> 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 = "/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=MIGR-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 = "/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="/var/tmp/ras"
> mkdir -p $TMP_DIR
> MESSAGE_FILE="$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=CVE-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
["signature.asc" (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-----


[prev in list] [next in list] [prev in thread] [next in thread]