Bug 861780 (CVE-2001-1593) - VUL-0: CVE-2001-1593: a2ps: insecure use of /tmp
Summary: VUL-0: CVE-2001-1593: a2ps: insecure use of /tmp
Status: VERIFIED FIXED
Alias: CVE-2001-1593
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Deadline: 2014-02-17
Assignee: Dr. Werner Fink
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-03 08:27 UTC by Alexander Bergmann
Modified: 2014-02-26 17:23 UTC (History)
1 user (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bergmann 2014-02-03 08:27:14 UTC
OSS:12013

Jakub Wilk posted a problem with a2ps and the insecure used of temporary files.

---------
Package: a2ps
Version: 1:4.14-1.1
Severity: important
Tags: security

src/main.c contains this code:

   /* Use one of the temp file names so that cleanup can be correctly
      done. */
   tempname_ensure (job->tmp_filenames[0]);
   spyname = job->tmp_filenames[0];
   spy = fopen (spyname, "w");

tempname_ensure() is defined in lib/routines.h as:

  #define tempname_ensure(Str)				\
  do {							\
    (Str) = (Str) ? (Str) : tempnam (NULL, "a2_");	\
  } while (0)

From the tempnam(3) manpage: “Although tempnam() generates names that 
are difficult to guess, it is nevertheless possible that between the 
time that tempnam() returns a pathname, and the time that the program 
opens it, another program might create that pathname using open(2), or 
create it as a symbolic link. This can lead to security holes. To avoid 
such possibilities, use the open(2) O_EXCL flag to open the pathname. Or 
better yet, use mkstemp(3) or tmpfile(3).”

(There are other calls to tempname_ensure() in the a2ps code, but I 
haven't checked them.)
---------

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737385
https://bugzilla.redhat.com/show_bug.cgi?id=1060630
http://comments.gmane.org/gmane.comp.security.oss.general/12013
Comment 1 Swamp Workflow Management 2014-02-03 10:58:59 UTC
The SWAMPID for this issue is 56088.
This issue was rated as moderate.
Please submit fixed packages until 2014-02-17.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.
Comment 2 Swamp Workflow Management 2014-02-03 23:00:21 UTC
bugbot adjusting priority
Comment 3 Alexander Bergmann 2014-02-05 19:57:57 UTC
CVE-2001-1593 was assigned to this issue.
Comment 7 Leonardo Chiquitto 2014-02-24 19:46:06 UTC
Looks like nobody actually checked that our code was vulnerable to this issue. AFAICS, a2ps sources in all maintained products include patch a2ps-4.13-security.patch, which replaces the call to tempnam() with a theoretically save version (safe_tempnam()).

Alex, please check if there's something still missing in our package.
Comment 8 Dr. Werner Fink 2014-02-24 20:25:55 UTC
Indeed that was a very old patch of mine 

 Mon Jan 15 12:49:30 CET 2001 - werner@suse.de
 - Fix the temporary file patch.
 Wed Jan 10 16:37:33 CET 2001 - werner@suse.de
 - Add temporary file patch

.. I wasn't aware of it anymore :(
Comment 9 Dr. Werner Fink 2014-02-24 20:27:13 UTC
CVE-2001-1593 ... was in 2001, wasn't it?
Comment 10 Alexander Bergmann 2014-02-26 13:49:32 UTC
Okay, sorry about the noise. The problem was fixed long time ago. Next time I'll check before assigning such an issue to the maintainer.

tempnam() was replaced with safe_tempnam() that is using mkstemp() internally. 

From the glibc documentation:

"Unlike mktemp, mkstemp is actually guaranteed to create a unique file that cannot possibly clash with any other program trying to create a temporary file. This is because it works by calling open with the O_EXCL flag, which says you want to create a new file and get an error if the file already exists."

Closing bug as fixed.
Comment 11 Leonardo Chiquitto 2014-02-26 14:21:32 UTC
Thanks for confirming. Don't forget to cancel the running patchinfos and update work flow (56088).