See $URL and bug 235770.
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).
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.
(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)
Fixed in mgetty-1.1.36-r2 by applying mgetty-1.1.36-tmpfile.patch. Feel free to start the stabilization process.
(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"
amd64/x86 stable
So the target is this: =net-dialup/mgetty-1.1.36-r2
Stable for HPPA.
alpha/ia64/sparc stable
ppc stable
time for GLSA decision, I vote YES.
YES too, request filed.
*** Bug 245756 has been marked as a duplicate of this bug. ***
GLSA 200812-08
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.
FWIW, the old patch had a functional problem, not a security one.
(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.