Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 235806 (CVE-2008-4936)

Summary: net-dialup/mgetty < 1.1.36-r3 insecure temp file usage (CVE-2008-4936)
Product: Gentoo Security Reporter: Christian Hoffmann (RETIRED) <hoffie>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: minor CC: craig, net-dialup
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
URL: http://bugs.debian.org/496403
Whiteboard: B3 [glsa errata]
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 235770    

Description Christian Hoffmann (RETIRED) gentoo-dev 2008-08-26 17:27:57 UTC
See $URL and bug 235770.
Comment 1 Christian Hoffmann (RETIRED) gentoo-dev 2008-08-26 19:18:11 UTC
Confirmed, there is vulnerable code in /usr/bin/faxspool. I tested version 1.1.36-r1 (only version in tree).
Vulnerable code is in line 656 (mkdir on that name later, if it fails, faxspool dies) and 678/679 (user input gets cat'ed to that file, so it allows for overwriting arbitrary files).

No patch from Debian yet, may want to follow their bug.

The vulnerable script is only installed with USE=fax (which seems to be default).
Comment 2 Alin Năstac (RETIRED) gentoo-dev 2008-08-31 13:17:58 UTC
If $spool_dir would exist, mkdir would fail and the faxspool process would immediately exit without touching anything.

Am I missing something? If not, please close this bug as INVALID.
Comment 3 Christian Hoffmann (RETIRED) gentoo-dev 2008-09-06 20:52:56 UTC
(In reply to comment #2)
> If $spool_dir would exist, mkdir would fail and the faxspool process would
> immediately exit without touching anything.
> 
> Am I missing something? If not, please close this bug as INVALID.
I think you are. You are right in case of $spooldir in line 656 and below, but there is another (or even more?) issue, as already pointed out: In line 679, the script writes to /tmp/faxsp.$$, independent of $spooldir, and of course this name is guessable and can be made a symlink to an arbitrary file.

Or is it me who is wrong here? ;o)
Comment 4 Alin Năstac (RETIRED) gentoo-dev 2008-09-07 09:59:57 UTC
Fixed in mgetty-1.1.36-r2 by applying mgetty-1.1.36-tmpfile.patch. Feel free to start the stabilization process.
Comment 5 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-09-07 12:48:35 UTC
(In reply to comment #4)
> Fixed in mgetty-1.1.36-r2 by applying mgetty-1.1.36-tmpfile.patch. Feel free to
> start the stabilization process.

Thanks. arches, please test and mark stable.
Target Keywords: "alpha amd64 hppa ia64 ~mips ppc ~ppc64 sparc x86"
Comment 6 Markus Meier gentoo-dev 2008-09-07 19:01:48 UTC
amd64/x86 stable
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2008-09-08 00:49:26 UTC
So the target is this:
=net-dialup/mgetty-1.1.36-r2
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2008-09-08 03:10:27 UTC
Stable for HPPA.
Comment 9 Raúl Porcel (RETIRED) gentoo-dev 2008-09-08 16:52:47 UTC
alpha/ia64/sparc stable
Comment 10 Tobias Scherbaum (RETIRED) gentoo-dev 2008-09-19 18:45:59 UTC
ppc stable
Comment 11 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-09-19 19:54:30 UTC
time for GLSA decision, I vote YES.
Comment 12 Tobias Heinlein (RETIRED) gentoo-dev 2008-09-22 12:40:49 UTC
YES too, request filed.
Comment 13 Stefan Behte (RETIRED) gentoo-dev Security 2008-11-05 21:44:33 UTC
*** Bug 245756 has been marked as a duplicate of this bug. ***
Comment 14 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-12-06 18:00:27 UTC
GLSA 200812-08
Comment 15 Robert Buchholz (RETIRED) gentoo-dev 2008-12-16 22:38:16 UTC
Eygene Ryabinkin reported that the patch in 1.1.36-r2 is insufficient, which was resolved in -r3. This went straight to stable, but a GLSA erratum is warranted.
Comment 16 Alin Năstac (RETIRED) gentoo-dev 2008-12-17 16:57:15 UTC
FWIW, the old patch had a functional problem, not a security one.
Comment 17 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-12-23 22:33:23 UTC
(In reply to comment #16)
> FWIW, the old patch had a functional problem, not a security one.
> 
glsa200812-08.xml updated, and closing as this has no security implications.