mktemp()

mktemp()

[Progga]

 Is mktemp() a deprecated function ?  The compiler ( actually the linker ) is 
repeatedly shouting -

 "warning: mktemp() possibly used unsafely; consider using mkstemp()"


 The manpage of mktemp(3) states -

-------
A common problem that results in a core dump is that the programmer
passes in a read-only string to mktemp(), mkstemp(), mkstemps() or
mkdtemp().
------

 - and I have taken care of this.


 The manpage also says -

------
BUGS
     This family of functions produces filenames which can be guessed, though
     the risk is minimized when large numbers of `Xs' are used to increase the
     number of possible temporary filenames.  This makes the race in mktemp(),
     between testing for a file's existence (in the mktemp() function call)
     and opening it for use (later in the user application) particularly dan-
     gerous from a security perspective.  Whenever it is possible, mkstemp()
     should be used instead, since it does not have the race condition.  If
     mkstemp() cannot be used, the filename created by mktemp() should be cre-
     ated using the O_EXCL flag to open(2) and the return status of the call
     should be tested for failure.  This will ensure that the program does not
     continue blindly in the event that an attacker has already created the
     file with the intention of manipulating or reading its contents.
------

 I haven't used open() and hence there's no O_EXCL.  Is it causing the warning ?
I also can't understand how an attacker can dupe the process into writing in
his intended file since mktemp() is supposed to return those names only that are
currently UNUSED.



 Khoda Hafez
 Progga

Re: mktemp()

[Glynn Clements]

Progga wrote:

> Is mktemp() a deprecated function ?

That's a matter of opinion. It's a potential security risk, and safer
alternatives are available.

> The compiler ( actually the linker ) is 
> repeatedly shouting -
> 
>  "warning: mktemp() possibly used unsafely; consider using mkstemp()"

By "unsafe", it's referring to the potential security issues, i.e. a
race condition.

>  The manpage of mktemp(3) states -
> 
> -------
> A common problem that results in a core dump is that the programmer
> passes in a read-only string to mktemp(), mkstemp(), mkstemps() or
> mkdtemp().
> ------

That isn't why it's complaining.

>  The manpage also says -
> 
> ------
> BUGS
>      This family of functions produces filenames which can be guessed, though
>      the risk is minimized when large numbers of `Xs' are used to increase the
>      number of possible temporary filenames.  This makes the race in mktemp(),
>      between testing for a file's existence (in the mktemp() function call)
>      and opening it for use (later in the user application) particularly dan-
>      gerous from a security perspective.  Whenever it is possible, mkstemp()
>      should be used instead, since it does not have the race condition.  If
>      mkstemp() cannot be used, the filename created by mktemp() should be cre-
>      ated using the O_EXCL flag to open(2) and the return status of the call
>      should be tested for failure.  This will ensure that the program does not
>      continue blindly in the event that an attacker has already created the
>      file with the intention of manipulating or reading its contents.
> ------
> 
> I haven't used open() and hence there's no O_EXCL.  Is it causing the warning ?
> I also can't understand how an attacker can dupe the process into writing in
> his intended file since mktemp() is supposed to return those names only that are
> currently UNUSED.

The risk is that, if you don't use O_EXCL, an attacker could create a
symlink between the point that mktemp() returns and the point that you
call open/fopen/etc, causing you to overwrite the target of the
symlink.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: mktemp()

[Progga]

On Sat, Jun 05, 2004 at 05:55:26AM +0100, Glynn Clements wrote:
> 
> The risk is that, if you don't use O_EXCL, an attacker could create a
> symlink between the point that mktemp() returns and the point that you
> call open/fopen/etc, causing you to overwrite the target of the
> symlink.

 Does the above mean that mktemp( "abcXXXXXX" ) can return "abc123456" even if
there's a symlink with the name "abc123456" ?



 Khoda Hafez
 Progga

Re: mktemp()

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On Sat, 2004-06-05 14:17:05 +0600, Progga <abulfazl@juniv.edu>
wrote in message <20040605141705.A681@Imrashi.net.bd>:
> On Sat, Jun 05, 2004 at 05:55:26AM +0100, Glynn Clements wrote:

>  Does the above mean that mktemp( "abcXXXXXX" ) can return "abc123456" even if
> there's a symlink with the name "abc123456" ?

No. This one has good chances to SIGSEGV before it returns at all:)

---------------------------------
char *my_temp_template = "abcXXXXXX";
char *my_temp_file;

my_temp_file = mktemp (my_temp_template);
if (!my_temp_file)
	errex ("Couldn't create temp file\n");
---------------------------------
The above one may SEGV as well, because the template may be stored in
memory marked as read-only.

This one will work:
---------------------------------
char my_temp_template[] = "abcXXXXXX";
char *my_temp_file;

my_temp_file = mktemp (my_temp_template);
if (!my_temp_file)
	errex ("Couldn't create temp file\n");
---------------------------------

Also, I remember there was at least one compiler (some older MAC OS?)
which didn't add the final \0 on it's own to xxx[]...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mktemp()

[Progga]

On Sat, Jun 05, 2004 at 01:16:48PM +0200, Jan-Benedict Glaw wrote:
> 
> This one will work:
> ---------------------------------
> char my_temp_template[] = "abcXXXXXX";
> char *my_temp_file;
> 
> my_temp_file = mktemp (my_temp_template);
> if (!my_temp_file)
> 	errex ("Couldn't create temp file\n");

 mktemp() does not create the tmp file; it just returns the name string pointer.
mkstemp() creates file though.



 Khoda Hafez
 Progga

Re: mktemp()

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Sat, 2004-06-05 18:40:01 +0600, Progga <abulfazl@juniv.edu>
wrote in message <20040605184000.A300@Imrashi.net.bd>:
> On Sat, Jun 05, 2004 at 01:16:48PM +0200, Jan-Benedict Glaw wrote:
> > char my_temp_template[] = "abcXXXXXX";
> > char *my_temp_file;
> > 
> > my_temp_file = mktemp (my_temp_template);
> > if (!my_temp_file)
> > 	errex ("Couldn't create temp file\n");
> 
>  mktemp() does not create the tmp file; it just returns the name string pointer.

That's why my_temp_file is "char *" and neither "FILE *" or "int".

> mkstemp() creates file though.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mktemp()

[Glynn Clements]

Progga wrote:

> > The risk is that, if you don't use O_EXCL, an attacker could create a
> > symlink between the point that mktemp() returns and the point that you
> > call open/fopen/etc, causing you to overwrite the target of the
> > symlink.
> 
>  Does the above mean that mktemp( "abcXXXXXX" ) can return "abc123456" even if
> there's a symlink with the name "abc123456" ?

No.

But an attacker could create a symlink with the name abc123456 between
the point that mktemp() returns and the point that you create the
file.

Or another process might coincidentally create a file named abc123456
between the point that mktemp() returns and the point that you try to
create your file.

This type of situation is known as a "race condition".

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: mktemp()

[Progga]

On Sat, Jun 05, 2004 at 08:42:16PM +0100, Glynn Clements wrote:
> 
> Or another process might coincidentally create a file named abc123456
> between the point that mktemp() returns and the point that you try to
> create your file.

 This sounds serious!  I am using this in a server and this can happen 
of course.  A special Thanks for pointing this special case.   Maybe mkstemp()
is the only solution since open() can't be used here ;-(



> This type of situation is known as a "race condition".

 The manpage mentioned this race condition and I didn't understood even after
going through the OS course ;-(   Need to study hard.



 Khoda Hafez
 Progga

Re: mktemp()

[Martin Olsson]

Imagine two processes using first mktemp() and later on open(). The 
first one checks if there a file called "abc112233" and there is no such 
file, now the second process does the same check and there is still no 
such file. Both processes now thinks its okay to use that filename.

Now two things can happen:

A) Process one writes its data to the file and closes it, followed by 
process two writing its data to the same file (overwriting it). Here the 
data written by process one is lost.

B) Process one writes and while its writing the second process tries to 
write and gets an error. Here process two doesnt get its data written.


In a server with many threads these collisions actually *do* happen in 
reality even if they seem a little obscure at first.



mvh.
/m

Progga wrote:

> 
>  Is mktemp() a deprecated function ?  The compiler ( actually the linker ) is 
> repeatedly shouting -
> 
>  "warning: mktemp() possibly used unsafely; consider using mkstemp()"
> 
> 
>  The manpage of mktemp(3) states -
> 
> -------
> A common problem that results in a core dump is that the programmer
> passes in a read-only string to mktemp(), mkstemp(), mkstemps() or
> mkdtemp().
> ------
> 
>  - and I have taken care of this.
> 
> 
>  The manpage also says -
> 
> ------
> BUGS
>      This family of functions produces filenames which can be guessed, though
>      the risk is minimized when large numbers of `Xs' are used to increase the
>      number of possible temporary filenames.  This makes the race in mktemp(),
>      between testing for a file's existence (in the mktemp() function call)
>      and opening it for use (later in the user application) particularly dan-
>      gerous from a security perspective.  Whenever it is possible, mkstemp()
>      should be used instead, since it does not have the race condition.  If
>      mkstemp() cannot be used, the filename created by mktemp() should be cre-
>      ated using the O_EXCL flag to open(2) and the return status of the call
>      should be tested for failure.  This will ensure that the program does not
>      continue blindly in the event that an attacker has already created the
>      file with the intention of manipulating or reading its contents.
> ------
> 
>  I haven't used open() and hence there's no O_EXCL.  Is it causing the warning ?
> I also can't understand how an attacker can dupe the process into writing in
> his intended file since mktemp() is supposed to return those names only that are
> currently UNUSED.
> 
> 
> 
>  Khoda Hafez
>  Progga
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>