It may be interesting to note that Windows syscalls (i.e. to the NT kernel rather than the Win32 layer wrappers like CreateFile) do not actually use null-terminated strings - they use UNICODE_STRING[1], which is a structure containing a 16-bit length, 16-bit buffer length, and pointer to a buffer of 2-byte characters.

NtCreateFile[2] (and the kernel-side implementation of ZwCreateFile[3]) take a file name in the form of OBJECT_ATTRIBUTES, whose ObjectName field is of type PUNICODE_STRING. CreateFile is implemented in terms of NtCreateFile; CreateFile enforces Win32 semantics like case insensitivity that NtCreateFile does not; POSIX semantics can be implemented on top of NtCreateFile, but not easily with CreateFile.

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...

[2] http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%2...

[3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...

Yes. You are right. In general, you have to be really careful when passing user-provided input to syscalls. Embedded nulls are only one of the many pitfalls there (another one from the top of my head is unicode handling). Especially if you're writing a webserver.

I'm not sure I follow you here. You can't have NULL characters in filenames on POSIX systems, so there's not an issue here (that I know of). What is the risk you're worried about?

Sorry for the late reply.

The risk only arises if the component of a system that accepts and validates user input does not use (or account for) null-terminated strings. That validator will see a different string than the syscall will; this is called null-character injection, and while it is difficult to craft effectively, it can lead to accessing resources that you thought you had protected by validating the string.

You are quite correct that nulls are not legal characters in POSIX filenames; however, that is irrelevant. The nulls are only an issue in the processing; once they reach a syscall, the first one is treated as a terminator.