Description:
'mysqlbug' is vulnerable to multiple tmpfile/symlink bugs, all of which can pose a threat to system security and file integrity, particuarly if root invokes 'mysqlbug'.
1) The variable $TEMP is defined with a fairly insecure tmpfile name.
--
# Try to create a secure tmpfile
umask 077
TEMPDIR=/tmp/mysqlbug-$$
mkdir $TEMPDIR || (echo "can not create directory in /tmp, aborting"; exit 1;)
TEMP=${TEMPDIR}/mysqlbug
--
The file is written to insecurely (and blindly, i.e no file checks) using commands such as:
--
cat > $TEMP <<EOF
--
Variations of the $TEMP file are also written to, such as this:
--
cp $TEMP $TEMP.x
--
And $TEMP.tmp is also written to using blind 'echo' invokations and sed, etc...
2) Another, less obvious (slightly less obvious) is how the script handles a user simply exiting the text editor without changing the bug report. When this happens, the mysqlbug script does the following:
--
if cmp -s $TEMP $TEMP.x
then
echo "File not changed, no bug report submitted."
cp $TEMP /tmp/failed-mysql-bugreport
echo "The raw bug report exists in /tmp/failed-mysql-bugreport"
echo "If you use this remember that the first lines of the report now is a lie
.."
exit 1
fi
--
As can be seen, this time a tmpfile isn't even attempted to be created securely, just a quick 'cp' to an unchecked file (/tmp/failed-mysql-bugreport). This could be bad if a root user had invoked mysqlbug, and then decided that they wanted to gather more info on their potential bug, so exited the text editor (and meanwhile the attacker had symlinked /tmp/failed-mysql-bugreport to /etc/nologin or somewhere...).
How to repeat:
1) This one is a little harder to repeat - this one is more of a race condition, and an attacker would need to have at least done a little preparation to pull of an attack.
--
attacker$ ls -al /nologin
ls: /etc/nologin: No such file or directory
[...]
root# /usr/local/bin/mysqlbug
[attacker VERY quickly does this:]
attacker$ ln -s /etc/nologin /tmp/mysqlbug-<pid>/mysqlbug
[...]
attacker$ ls -al /nologin
-rw-r--r-- 1 root root 0 Mar 24 16:50 /etc/nologin
--
Although I haven't tested, it is possible that when the user is writing the bug report in the fired up text editor, an attacker might be able to delete the tmpfile, and then symlink it somewhere else. The race condition might be made easier because of the time it takes for a user to type a bug report. I haven't confirmed this, though.
2) This one is relatively easy, but requires that mysqlbug is started, then when the text editor is fired up by 'mysqlbug', the user decides the exit it. At this, the script copies the email template rather insecurely into an unverified /tmp file (/tmp/failed-mysql-bugreport).
--
attacker$ ls -al /nologin
ls: /etc/nologin: No such file or directory
attacker$ ln -s /etc/nologin /tmp/failed-mysql-bugreport
[...]
root# mysqlbug
[root decides to exit the text editor that mysqlbug started, because he wants to get more info on his discovered bug]
attacker$ ls -al /nologin
-rw-r--r-- 1 root root 0 Mar 24 16:50 /etc/nologin
---
Suggested fix:
1) I reckon that 'mktemp' could be used to more securely create tempfiles. I.e
--
mktemp /tmp/temp.XXXXXX
--
Or, more ideally,
--
mktemp -d /tmp/temp.XXXXXX
--
which creates a directory. From there, we could define $TEMP as mysqlbug.$$, or continue to use 'mktemp' to generate a more secure tmpfile name.
2) The same workaround as above could be used, or, just don't dump the report at all - just exit mysqlbug.
Another solution for both would be to use 'if' statements to check if the file exists, but this would add extra bloat to the script - mktemp is probably the best way to fix it.
I didn't find any bugs reported in mysqlbug, so I reported this. Sorry if this has been solved in later releases - I didn't see it in any release notes.
Description: 'mysqlbug' is vulnerable to multiple tmpfile/symlink bugs, all of which can pose a threat to system security and file integrity, particuarly if root invokes 'mysqlbug'. 1) The variable $TEMP is defined with a fairly insecure tmpfile name. -- # Try to create a secure tmpfile umask 077 TEMPDIR=/tmp/mysqlbug-$$ mkdir $TEMPDIR || (echo "can not create directory in /tmp, aborting"; exit 1;) TEMP=${TEMPDIR}/mysqlbug -- The file is written to insecurely (and blindly, i.e no file checks) using commands such as: -- cat > $TEMP <<EOF -- Variations of the $TEMP file are also written to, such as this: -- cp $TEMP $TEMP.x -- And $TEMP.tmp is also written to using blind 'echo' invokations and sed, etc... 2) Another, less obvious (slightly less obvious) is how the script handles a user simply exiting the text editor without changing the bug report. When this happens, the mysqlbug script does the following: -- if cmp -s $TEMP $TEMP.x then echo "File not changed, no bug report submitted." cp $TEMP /tmp/failed-mysql-bugreport echo "The raw bug report exists in /tmp/failed-mysql-bugreport" echo "If you use this remember that the first lines of the report now is a lie .." exit 1 fi -- As can be seen, this time a tmpfile isn't even attempted to be created securely, just a quick 'cp' to an unchecked file (/tmp/failed-mysql-bugreport). This could be bad if a root user had invoked mysqlbug, and then decided that they wanted to gather more info on their potential bug, so exited the text editor (and meanwhile the attacker had symlinked /tmp/failed-mysql-bugreport to /etc/nologin or somewhere...). How to repeat: 1) This one is a little harder to repeat - this one is more of a race condition, and an attacker would need to have at least done a little preparation to pull of an attack. -- attacker$ ls -al /nologin ls: /etc/nologin: No such file or directory [...] root# /usr/local/bin/mysqlbug [attacker VERY quickly does this:] attacker$ ln -s /etc/nologin /tmp/mysqlbug-<pid>/mysqlbug [...] attacker$ ls -al /nologin -rw-r--r-- 1 root root 0 Mar 24 16:50 /etc/nologin -- Although I haven't tested, it is possible that when the user is writing the bug report in the fired up text editor, an attacker might be able to delete the tmpfile, and then symlink it somewhere else. The race condition might be made easier because of the time it takes for a user to type a bug report. I haven't confirmed this, though. 2) This one is relatively easy, but requires that mysqlbug is started, then when the text editor is fired up by 'mysqlbug', the user decides the exit it. At this, the script copies the email template rather insecurely into an unverified /tmp file (/tmp/failed-mysql-bugreport). -- attacker$ ls -al /nologin ls: /etc/nologin: No such file or directory attacker$ ln -s /etc/nologin /tmp/failed-mysql-bugreport [...] root# mysqlbug [root decides to exit the text editor that mysqlbug started, because he wants to get more info on his discovered bug] attacker$ ls -al /nologin -rw-r--r-- 1 root root 0 Mar 24 16:50 /etc/nologin --- Suggested fix: 1) I reckon that 'mktemp' could be used to more securely create tempfiles. I.e -- mktemp /tmp/temp.XXXXXX -- Or, more ideally, -- mktemp -d /tmp/temp.XXXXXX -- which creates a directory. From there, we could define $TEMP as mysqlbug.$$, or continue to use 'mktemp' to generate a more secure tmpfile name. 2) The same workaround as above could be used, or, just don't dump the report at all - just exit mysqlbug. Another solution for both would be to use 'if' statements to check if the file exists, but this would add extra bloat to the script - mktemp is probably the best way to fix it. I didn't find any bugs reported in mysqlbug, so I reported this. Sorry if this has been solved in later releases - I didn't see it in any release notes.