4 ms·

I may be misinterpreting the patch, but it seems like this is a NULL byte injection vulnerability, all stemming from '\0' termination in C-strings. I wonder if

• gizzlon 15y ago
  Not a "C guy", but I simply read it as: Strings could be missing a "\0" and therefore some function could read too far later on..
  • matthavener 15y ago
    Not exactly. Some function expecting a c-string could actually read too short. What happens is some attacker sends a message using a channel/format that specifies a length and a buffer. But, the buffer contains a "\0". For example, (10, "wtf\0extra") is passed as a 10 char string. But, some c function might only see it as (3,"wtf"). The (usually) simply solution is to fail validation when a string of N bytes contains a NULL char before the N+1 byte.
• wladimir 15y ago
  IMO, zero-terminated strings are, and always have been, a bad idea. Discriminating against a certain character instead of just regarding it as opaque blob of data will bite you in unexpected ways, and strlen() taking O(N) is another drawback. The string functions in the C standard library suck. bstring is a better alternative: http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrlib.txt?pathrev=HEAD http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrl... . Glib also has a good string library...
  • kbolino 15y ago
    Something to bear in mind regarding non-standard string libraries: syscalls (like open[1] on POSIX or CreateFile[2] on Windows) use null-terminated strings, which means that you have to be careful about embedded nulls, no matter what library you use, when a string gets passed to a syscall somewhere in the chain. [1] http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html http://pubs.opengroup.org/onlinepubs/000095399/functions/ope... [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
    • wladimir 15y ago
      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.
    • barrkel 15y ago
      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/ff564879%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5... [2] http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%2... [3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff566424%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...
      • deleted 15y ago
        [deleted]