Re: Bug#302412: exploitable temporary file race in unshar (fwd)

[Santiago Vila]

On Thu, 31 Mar 2005, Bruce Korb wrote:

> Wrong assumption.  It was announced on info-gnu.

May I suggest that sharutils 4.3.77 and 4.3.78 are not put in directories
named "4.3.77" and "REL-4.3.78", then? The current layout is a little
bit misleading.

> These new issues will get faster action with a suggested patch :-).

Ok, here is a patch that maybe you can accept:

diff -ru sharutils-4.2.1.orig/src/unshar.c sharutils-4.2.1/src/unshar.c
--- sharutils-4.2.1.orig/src/unshar.c   2005-04-01 03:04:23.982932000 +0200
+++ sharutils-4.2.1/src/unshar.c        2005-04-01 03:10:59.278838528 +0200
@@ -426,13 +426,15 @@
       }
   else
     {
+#ifdef __MSDOS__
       sprintf (name_buffer, "/tmp/unsh.%05d", (int) getpid ());
       unlink (name_buffer);
 
       if (file = fopen (name_buffer, "w+"), !file)
        error (EXIT_FAILURE, errno, name_buffer);
-#ifndef __MSDOS__
-      unlink (name_buffer);    /* will be deleted on fclose */
+#else
+      if (file = tmpfile(), !file)
+       error (EXIT_FAILURE, errno, "tmpfile");
 #endif
 
       while (size_read = fread (copy_buffer, 1, sizeof (copy_buffer), stdin),


This patch tries not to break the MSDOS stuff. For Unix, there is no
need to unlink the file (the tmpfile function already does this), not
to mention we don't even know the name of the file, so we have to
change the error message a little bit to not reference name_buffer,
since it does not have any useful value.