From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Insecure tempfile creation
Date: Mon, 22 Dec 2014 20:36:24 +0000 [thread overview]
Message-ID: <20141222203624.GA24855@tarsus.local2> (raw)
[moving to -workers from private email]
[this mail contains two mutually-exclusive (conflicting) patches]
Hello.
A few places in the source distribution use predictable temporary
filenames; for example:
Completion/Unix/Command/_cvs local d=/tmp/zsh-cvs-work-$$
Completion/compinstall: local tmpout=${TMPPREFIX:-/tmp/zsh}compinstall$$
Functions/Calendar/calendar: local mycmds="${TMPPREFIX:-/tmp/zsh}.calendar_cmds.$$"
Functions/Newuser/zsh-newuser-install: local tmpfile=${TMPPREFIX:-/tmp/zsh}-zni-$$
Functions/Zftp/zfcget: local tmpfile=${TMPPREFIX}zfcget$$ rstat tsize
Functions/Zle/edit-command-line local tmpfile=${TMPPREFIX:-/tmp/zsh}ecl$$
Test/ztst.zsh: ZTST_in=${TMPPREFIX}.ztst.in.$$
Some of these could be vectors for symlink attacks. For example, in the
edit-command-line case, a malicious local user could overwrite an
arbitrary file by creating /tmp/zshecl4242 (where 4242 is the pid of an
interactive zsh run by root) as a symlink and waiting for the user
behind pid 4242 to run edit-command-line. (The attacker would also be
able to see the contents of the edited command line, which is a problem
if it contains passwords.)
(Paraphrasing Bart:) In general, the "standard library" should create
tempfiles in ${TMPPREFIX:-/tmp}, and take care to explicitly protect
(e.g., via umask settings) any files which need to be private.
So, for starters:
diff --git Functions/Zle/edit-command-line Functions/Zle/edit-command-line
index 250cac6..1b1762d 100644
--- Functions/Zle/edit-command-line
+++ Functions/Zle/edit-command-line
@@ -6,12 +6,16 @@
# will give ksh-like behaviour for that key,
# except that it will handle multi-line buffers properly.
-local tmpfile=${TMPPREFIX:-/tmp/zsh}ecl$$
-
-print -R - "$PREBUFFER$BUFFER" >$tmpfile
-exec </dev/tty
-${=${VISUAL:-${EDITOR:-vi}}} $tmpfile
-print -Rz - "$(<$tmpfile)"
-
-command rm -f $tmpfile
-zle send-break # Force reload from the buffer stack
+() {
+ # Use =(:) to create a temporary file with 0600 permissions, since
+ # the command-line may contain passwords.
+ local tmpfile=$1
+
+ print -R - "$PREBUFFER$BUFFER" >$tmpfile
+ exec </dev/tty
+ ${=${VISUAL:-${EDITOR:-vi}}} $tmpfile
+ print -Rz - "$(<$tmpfile)"
+
+ command rm -f $tmpfile
+ zle send-break # Force reload from the buffer stack
+} =(:)
This causes the tempfile to be generated by gettempname(), which wraps
mktemp(), eliminating the predictable filename.
Do people find this use of anon functions too obfuscatory? If so,
perhaps a "mktemp" builtin could be added as a thin wrapper around
gettempname() (on systems that don't have a mktemp command already), and
the code be converted to just:
tarsus,5:src/zsh% git di
diff --git Functions/Zle/edit-command-line Functions/Zle/edit-command-line
index 250cac6..584ae16 100644
--- Functions/Zle/edit-command-line
+++ Functions/Zle/edit-command-line
@@ -6,7 +6,7 @@
# will give ksh-like behaviour for that key,
# except that it will handle multi-line buffers properly.
-local tmpfile=${TMPPREFIX:-/tmp/zsh}ecl$$
+local tmpfile=`mktemp ${TMPPREFIX:-/tmp/zsh}ecl.XXXXXX`
print -R - "$PREBUFFER$BUFFER" >$tmpfile
exec </dev/tty
Of course, once we decide what to do with edit-command-line, it would be
good to go through all the other instances and fix them too.
Cheers,
Daniel
next reply other threads:[~2014-12-22 20:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 20:36 Daniel Shahaf [this message]
2014-12-22 22:01 ` Mikael Magnusson
2014-12-23 2:07 ` Bart Schaefer
2014-12-28 6:30 ` Bart Schaefer
2014-12-28 7:44 ` [PATCH] " Bart Schaefer
2014-12-28 8:41 ` Bart Schaefer
2014-12-29 0:49 ` Daniel Shahaf
2014-12-29 4:01 ` Bart Schaefer
2015-01-07 22:03 ` Daniel Shahaf
2015-01-08 6:22 ` Bart Schaefer
2015-01-08 6:48 ` Danek Duvall
2015-01-08 8:08 ` Bart Schaefer
2015-01-08 14:10 ` Daniel Shahaf
2015-01-08 14:24 ` Peter Stephenson
2015-01-08 16:35 ` Ray Andrews
2015-01-08 17:40 ` Peter Stephenson
2015-01-09 2:51 ` Mikael Magnusson
2015-01-09 9:02 ` Peter Stephenson
2015-01-09 12:51 ` Peter Stephenson
2015-01-09 13:35 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141222203624.GA24855@tarsus.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).