Insecure Temporary File - Revision history

Imifos at 12:40, 22 January 2016

2016-01-22T12:40:42Z

Imifos at 12:44, 2 December 2015

2015-12-02T12:44:46Z

Henri Salo: Added link to guide in Python-documentation

2010-06-04T12:18:48Z

Added link to guide in Python-documentation

MediaWiki spam cleanup: Reverting to last version not containing links to www.texttrocoulino.com

2009-05-27T18:27:33Z

Reverting to last version not containing links to www.texttrocoulino.com

Deleted user at 17:34, 21 May 2009

2009-05-21T17:34:13Z

KirstenS: /* Group 2 – "Unique" Files */

2009-02-26T11:06:36Z

‎Group 2 – "Unique" Files

KirstenS: /* Risk Factors */

2009-02-26T11:02:18Z

‎Risk Factors

KirstenS: /* Description */

2009-02-26T11:02:02Z

‎Description

KirstenS at 01:25, 21 February 2009

2009-02-21T01:25:46Z

KirstenS at 02:33, 18 February 2009

2009-02-18T02:33:12Z

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
-Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
@@ Line 114: / Line 114: @@
 [[Category:OWASP ASDR Project]]
-[[Category:OWASP C/C++ Project]]
+[[Category:C/C++]]
 [[Category:Code Snippet]]
 [[Category:File System]]

@@ Line 114: / Line 114: @@
 [[Category:OWASP ASDR Project]]
-[[Category:C]]
+[[Category:OWASP C/C++ Project]]
 [[Category:Code Snippet]]
 [[Category:File System]]

← Older revision		Revision as of 12:18, 4 June 2010
Line 73:		Line 73:
	* [[Technical Impact 1]]		* [[Technical Impact 1]]
	* [[Technical Impact 2]]		* [[Technical Impact 2]]
		+
		+
		+	==Related Coding==
		+
		+	* [http://docs.python.org/library/tempfile.html#tempfile.mkstemp Python creating a temporary file the most secure manner possible]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
@@ Line 11: / Line 10: @@
 Creating and using insecure temporary files can leave application and system data vulnerable to attacks.
-Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and WindowsÂ® API. Most of these functions are vulnerable to various forms of attacks.
+Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows® API. Most of these functions are vulnerable to various forms of attacks.
 ==Risk Factors==
@@ Line 36: / Line 35: @@
-===Group 1 â "Unique" Filenames===
+===Group 1 – "Unique" Filenames===
 The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess.
@@ Line 45: / Line 44: @@
-===Group 2 â "Unique" Files===
+===Group 2 – "Unique" Files===
 The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp().

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
@@ Line 10: / Line 11: @@
 Creating and using insecure temporary files can leave application and system data vulnerable to attacks.
-Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows® API. Most of these functions are vulnerable to various forms of attacks.
+Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and WindowsÂ® API. Most of these functions are vulnerable to various forms of attacks.
 ==Risk Factors==
@@ Line 35: / Line 36: @@
-===Group 1 – "Unique" Filenames===
+===Group 1 â "Unique" Filenames===
 The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess.
@@ Line 44: / Line 45: @@
-===Group 2 – "Unique" Files===
+===Group 2 â "Unique" Files===
 The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp().

@@ Line 50: / Line 50: @@
 The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker can pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance.
-Finally, mkstemp() is a reasonably safe way create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.
+Finally, mkstemp() is a reasonably safe way to create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.
 ==Related [[Attacks]]==

@@ Line 13: / Line 13: @@
 ==Risk Factors==
 TBD
 ==Examples==

← Older revision		Revision as of 11:02, 26 February 2009
Line 11:		Line 11:

	Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows® API. Most of these functions are vulnerable to various forms of attacks.		Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows® API. Most of these functions are vulnerable to various forms of attacks.
−

	==Risk Factors==		==Risk Factors==