Bug#506961: auctex: reuses old logfile on emacsen upgrades, enabling symlink attack
You wrote: I think this (untested) patch would fix it: --- /usr/lib/emacsen-common/packages/install/auctex 2008-09-08 13:43:54.0 +0200 +++ auctex2008-11-28 22:08:49.0 +0100 @@ -79,6 +79,7 @@ rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ;; (File) + rm -f ${_db_logfile} echo 2 -n update-auctex-elisp: echo 2 Further output will appear in: ${_db_logfile}. echo 2 -n auctex: @@ -89,6 +90,7 @@ ${0##*/}: Unknown Debconf value doautofg = \${_db_doautofg}\. ;; esac ;; (Background) + rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ${_db_logfile} 21 3- echo 2 -n update-auctex-elisp[${!}]: echo 2 Further output will appear in: ${_db_logfile}. ;; Note that I am neither the maintainer (just a lurker on the PTS), nor do I have time to do an NMU in case it is needed. Which might be the case, there are weeks where Davide is quite unresponsive. That reduces the attack window, but it's not a solution. I think the safe thing to do is to create the log file in /var/lib/auctex or /var/log instead. Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious. signature.asc Description: This is a digitally signed message part
Bug#506961: auctex: reuses old logfile on emacsen upgrades, enabling symlink attack
Sven Joachim [EMAIL PROTECTED] wrote: Package: auctex Version: 11.83-7.2 Severity: grave Tags: security Auctex reuses an old logfile name in /tmp for logs whenever an emacsen is installed/upgraded. Since /tmp is cleaned regularly, an attacker may replace it with a symlink after the file has been deleted: , | % debconf-show auctex | debconf: DbDriver passwords warning: could not open /var/cache/debconf/passwords.dat: Permission denied | * auctex/doauto: Background | * auctex/default: true | auctex/logfile: /tmp/update-auctex-elisp.pykjkoG | auctex/alreadydefault: | * auctex/defaultchanged: | auctex/doautofg: File | % ln -s /etc/foo /tmp/update-auctex-elisp.pykjkoG | ls -l /etc/foo | ls: cannot access /etc/foo: No such file or directory | % sudo aptitude reinstall emacs22-gtk | [...] | % ls -l /etc/foo | -rw-r--r-- 1 root root 211129 Nov 26 13:58 /etc/foo | % head /etc/foo | Applying style hooks... | Applying style hooks... done | Sorting environment... | Removing duplicates... | Removing duplicates... done | Applying style hooks... | Applying style hooks... done | Parsing bbox.sty... | Parsing bbox.sty... done | Applying style hooks... | % ` You proved it, but I don't understand it. From /usr/lib/emacsen-common/packages/install/auctex: case ${_db_doautofg} in (Console) rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ;; (File) echo 2 -n update-auctex-elisp: echo 2 Further output will appear in: ${_db_logfile}. echo 2 -n auctex: echo 2 -n Waiting for update-auctex-elisp to terminate... /usr/sbin//update-auctex-elisp ${FLAVOR} ${_db_logfile} 21 So the file is removed before it is written to, and that should be safe, shouldn't it? Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506961: auctex: reuses old logfile on emacsen upgrades, enabling symlink attack
On 2008-11-28 19:49 +0100, Frank Küster wrote: Sven Joachim [EMAIL PROTECTED] wrote: Auctex reuses an old logfile name in /tmp for logs whenever an emacsen is installed/upgraded. Since /tmp is cleaned regularly, an attacker may replace it with a symlink after the file has been deleted: , | % debconf-show auctex | debconf: DbDriver passwords warning: could not open /var/cache/debconf/passwords.dat: Permission denied | * auctex/doauto: Background | * auctex/default: true | auctex/logfile: /tmp/update-auctex-elisp.pykjkoG | auctex/alreadydefault: | * auctex/defaultchanged: | auctex/doautofg: File You proved it, but I don't understand it. From /usr/lib/emacsen-common/packages/install/auctex: case ${_db_doautofg} in (Console) rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ;; (File) echo 2 -n update-auctex-elisp: echo 2 Further output will appear in: ${_db_logfile}. echo 2 -n auctex: echo 2 -n Waiting for update-auctex-elisp to terminate... /usr/sbin//update-auctex-elisp ${FLAVOR} ${_db_logfile} 21 So the file is removed before it is written to, and that should be safe, shouldn't it? No, that code path is not entered because ${_db_doautofg} != Console (and ${_db_doauto} != Foreground), see the debconf values: auctex/doauto: Background auctex/doautofg: File Thus, the code actually run is (Background) /usr/sbin//update-auctex-elisp ${FLAVOR} ${_db_logfile} 21 3- echo 2 -n update-auctex-elisp[${!}]: echo 2 Further output will appear in: ${_db_logfile}. ;; I guess rm -f ${_db_logfile} needs to be added to this case as well. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506961: auctex: reuses old logfile on emacsen upgrades, enabling symlink attack
tags 506961 patch thanks Sven Joachim [EMAIL PROTECTED] wrote: No, that code path is not entered because ${_db_doautofg} != Console (and ${_db_doauto} != Foreground), see the debconf values: Sorry, you're right (and I was fooled by the unusual opening parentheses). I think this (untested) patch would fix it: --- /usr/lib/emacsen-common/packages/install/auctex 2008-09-08 13:43:54.0 +0200 +++ auctex 2008-11-28 22:08:49.0 +0100 @@ -79,6 +79,7 @@ rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ;; (File) + rm -f ${_db_logfile} echo 2 -n update-auctex-elisp: echo 2 Further output will appear in: ${_db_logfile}. echo 2 -n auctex: @@ -89,6 +90,7 @@ ${0##*/}: Unknown Debconf value doautofg = \${_db_doautofg}\. ;; esac ;; (Background) + rm -f ${_db_logfile} /usr/sbin//update-auctex-elisp ${FLAVOR} ${_db_logfile} 21 3- echo 2 -n update-auctex-elisp[${!}]: echo 2 Further output will appear in: ${_db_logfile}. ;; Note that I am neither the maintainer (just a lurker on the PTS), nor do I have time to do an NMU in case it is needed. Which might be the case, there are weeks where Davide is quite unresponsive. Regards, Frank -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]