What is actually a "NULL byte"?

As far as I know, it's a byte that ends each string. Also seen as \0
So if you had the word hello in a C char type, it'd be like this:

str[0] = 'h';
str[1] = 'e';
str[2] = 'l';
str[3] = 'l';
str[4] = 'o';
str[5] = '\0';

I have no idea what the problem with it is though =/
More info

Like elbekko and MadHatter have already explained, the NULL byte is used to terminate strings. Here's some history

A string, as you might now, is an array of characters. In the ASCII character set, each character is represented by one byte. Each byte has a number between 0 and 255 according to the ASCII table:

As you can see, the character at index zero in the table is called NULL (or NUL, it's the same thing). You can also see that the number zero doesn't represent any particular character. So, if we wanted to store the word "hello" in a string, we would create an array of bytes with the contents:

104,101,108,108,111

But there's a problem with this. If we then want to print that string to the screen, we need to know how many bytes to print. If we don't, we would just continue forever and print whatever appears after this string in the computer's memory. One solution to this problem would be to keep track of how many characters the string contains in a variable in our program. However, that solution isn't very efficient or convenient because then we need an extra variable every time we need to use a string. Instead, we just append the null byte at the end:

104,101,108,108,111,0

Since the number zero doesn't represent any character, we can program our print-to-screen function to continue printing until it encounters the null byte. Most functions that deal with strings work this way. They continue until they encounter the null byte. This is all very convenient, but it has it's own problems. For example, if a program has a string that contains 5 characters followed by the null byte and someone manages to insert a string that is longer than that, we end up with what's called a buffer overrun. But that's a whole different story.

Due to some bugs in PHP, we need to care about null bytes as well. PunBB 1.2.13 contained a patch for a null byte vulnerability that was exploitable by admins only. Here's how it works.

PunBB stores a variable called avatar_path to keep track of where to store avatar images. A malicious administrator (I know, it's almost an oxymoron) can POST a custom form to admin_options.php and set the avatar_path to, for example, "img/avatars/shell.php/%00". %00 is the null byte that has been URL encoded. The administration then uploads an avatar image that has embedded PHP code (for example in the EXIF header). When PunBB receives the file (which it believes to be an image), it will attempt to move the file to the avatar path. The avatar path is img/avatars/shell.php/%00, but due to a bug in PHP, it interprets the null byte as the end of the string which results in the uploaded file being moved to img/avatars/shell.php. We end up with a file called shell.php in the avatars directory that contains PHP code. Not good.

Thanks for the great answers.
Does it mean that if i let users upload something to the server and let them give the path name where their file goes, that i have to always check possible NULL byte from the given path name?

How about the filenames, if i let users upload for example images, do i need to check for the image names if they contains NULL byte?

PS. I'm using php to handle the fileuploads.

Regards

If you're going to rely on the filename provided by the user, I would definately check it. Feel free to borrow the code from PunBB: http://dev.punbb.org/changeset/588

You should also make sure that the files that are uploaded don't end in for example .php. I would set up an array of allowed file extensions, strip out any NULL byte and then make sure the filename has one of the allowed extensions.

Ofcourse it does

It's indeed a good way to do so. WHat I do when allowing image uploads is usually do a strstr() on "image/" for the type.
If possible, run this check: http://be2.php.net/manual/en/function.m … t-type.php

@elbekko: '\0' is an escape char for a null byte, 0, as Rickard mentioned, is it's actual value.  And when you have a string literal in C (eg. "Hello World"), it is implicitly null terminated.

\0 isnt an escaped null, it is the null char.  same way \r or \n is line feed and newline.

echo "test \0 test"; will print both tests and will not assume \0 to be the termination of the string.  I think where the problem comes in is where php wraps the normal platform sdk of the machines they're on.  they pass the functionality through.

echo 'test \0 test'; will print the backslash and 0 as 2 seperate characters.