...
File names on many operating systems may be used to access device files. Device files are used to access hardware and peripherals. Reserved MS-DOS device names include AUX
, CON
, PRN
, COM1
, and LPT1
. Character special files and block special files are POSIX device files that direct operations on the files to the appropriate device drivers.
Performing operations on device files intended only for ordinary character or binary files can result in crashes and denial-of-service (DoS) attacks. For example, when Windows attempts to interpret the device name as a file resource, it performs an invalid resource access that usually results in a crash \[ [Howard 2002|AA. References#Howard 02]\]. Wiki Markup
Device files in POSIX can be a security risk when an attacker can access them in an unauthorized way. For instance, if malicious programs can read or write to the {{ Wiki Markup /dev/kmem
}} device, they may be able to alter their own priority, user ID, or other attributes of their process or they may simply crash the system. Similarly, access to disk devices, tape devices, network devices, and terminals being used by other processes can also lead to problems \[[[Garfinkel 1996|AA. References#Garfinkel 96]\].
On Linux, it is possible to lock certain applications by attempting to read or write data on devices rather than files. Consider the following device path names:
...
A Web browser that failed to check for these devices would allow an attacker to create a website with image tags such as <IMG src="file:///dev/mouse">
that would lock the user's mouse.
Shared File Access
...
On many systems, files can be simultaneously accessed by concurrent processes. Exclusive access grants unrestricted file access to the locking process while denying access to all other processes, eliminating the potential for a race condition on the locked region. The {{java.nio.channels.FileLock
}} class may be used for file locking. According to the Java API \ [[API 2006|AA. References#API 06] \] documentation,
A file lock is either exclusive or shared. A shared lock prevents other concurrently running programs from acquiring an overlapping exclusive lock but does allow them to acquire overlapping shared locks. An exclusive lock prevents other programs from acquiring an overlapping lock of either type. Once it is released, a lock has no further effect on the locks that may be acquired by other programs.
Shared locks support concurrent read access from multiple processes; exclusive locks support exclusive write access. File locks provide protection across processes, but they do not provide protection from multiple threads within a single process. Both shared locks and exclusive locks eliminate the potential for a cross-process race condition on the locked region. Exclusive locks provide mutual exclusion; shared locks prevent alteration of the state of the locked file region (one of the required properties for a data race).unmigrated-wiki-markup
The Java API \ [[API 2006|AA. References#API 06] \] documentation states that "whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and consequently unspecified."
Microsoft Windows uses a mandatory file-locking mechanism that prevents processes from accessing a locked file region.
...
This noncompliant code example performs the necessary checks and then opens the file. After opening the file, it performs a second check to make sure that the file has not been moved and that the file opened is the same file that was checked. This reduces the chance that an attacker has changed the file between checking and then opening the file. In both checks, the file's fileKey
attribute is examined. This serves as a unique key for identifying files and is a more reliable indicator of the file's identity than its path name.unmigrated-wiki-markup
The SE 7 Documentation \ [[J2SE 2011|AA. References#J2SE 11]\] describes the {{fileKey}} 2011] describes the fileKey
attribute:
Returns an object that uniquely identifies the given file, or null if a file key is not available. On some platforms or file systems it is possible to use an identifier, or a combination of identifiers to uniquely identify a file. Such identifiers are important for operations such as file tree traversal in file systems that support symbolic links or file systems that allow a file to be an entry in more than one directory. On UNIX file systems, for example, the device ID and inode are commonly used for such purposes.
The file key returned by this method can only be guaranteed to be unique if the file system and files remain static. Whether a file system re-uses identifiers after a file is deleted is implementation dependent and consequently unspecified.
File keys returned by this method can be compared for equality and are suitable for use in collections. If the file system and files remain static, and two files are the same with non-null file keys, then their file keys are equal.
...
FIO32-C. Do not perform operations on devices that are only appropriate for files | |
FIO32-CPP. Do not perform operations on devices that are only appropriate for files | |
CWE-67. Improper handling of windows device names |
Bibliography
...
[[API 2006 | AA. References#API 06]] | ] | Class | ||||
11.5, Creating a Transient File | |||||||
Section 5.6, Device Files | |||||||
[Howard 2002] ]></ac:plain-text-body></ac:structured-macro> | |||||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d9bdb544-85ff-49e4-bb19-1a4ae0ca569a"><ac:plain-text-body><![CDATA[ | [[Darwin 2004 | AA. References#Darwin 04]] | 11.5, Creating a Transient File | ]]></ac:plain-text-body></ac:structured-macro> | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="76e00b6f-dcad-4f03-827f-214355879a2a"><ac:plain-text-body><![CDATA[ | [[Garfinkel 1996 | AA. References#Garfinkel 96]] | Section 5.6, Device Files | ]]></ac:plain-text-body></ac:structured-macro> | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ae62493a-b505-4b51-a959-a672931b216f"><ac:plain-text-body><![CDATA[ | [[Howard 2002 | AA. References#Howard 02]] | Chapter 11, Canonical Representation Issues | ]]></ac:plain-text-body></ac:structured-macro> | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1e8c595e-b4fb-468d-9ade-201f62cd3cb7"><ac:plain-text-body><![CDATA[ | [[J2SE 2011 | AA. References#J2SE 11]] | The try-with-resources Statement | ]]></ac:plain-text-body></ac:structured-macro> | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4262cb77-e672-4872-88e1-01211107b04f"><ac:plain-text-body><![CDATA[ | [[Open Group 2004 | AA. References#Open Group 04]] | [ | http://www.opengroup.org/onlinepubs/009695399/functions/open.html] | ]]></ac:plain-text-body></ac:structured-macro> | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="96342475-55cf-40e4-b856-1db5eeef85ba"><ac:plain-text-body><![CDATA[ | [[SDN 2008 | AA. References#SDN 08]] | Bug IDs 4171239, 4405521, 4635827, 4631820 | ]]></ac:plain-text-body></ac:structured-macro> | |||
Chapter 11, Canonical Representation Issues | |||||||
The try-with-resources Statement | |||||||
[SDN 2008] | Bug IDs 4171239, 4405521, 4635827, 4631820 | ||||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9d9ec4d0-47d3-4728-b6e6-ecf3dd751f0e"><ac:plain-text-body><![CDATA[ | [[Secunia 2008 | AA. References#Secunia 08]] | [Secunia Advisory 20132 | http://secunia.com/advisories/20132/] | ]]></ac:plain-text-body></ac:structured-macro> |
...