Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nice real world example of the poison null byte attack.

For those who don't know what a null byte attack is, that's where you pass in an http request that turns into a string that explicitly encodes a null byte, \0 at the end. So you insert something like subsection=/../../../../../../../../../../../../../../../../etc/passwd%00. Now the code in the application tries to append something like .txt because "how bad could a .txt file be", and it arrives in C land as "/../../../../../../../../../../../../../../../../etc/passwd\0.txt\0" and C thinks that the string ends at the first \0 and doesn't pay any attention to the .txt bit.

This is a good example of why your escaping mechanism should always be "allow only what is explicitly known to be safe" rather than "block what is known to be unsafe". Because you have no idea what unsafe things there are that you don't know about.



Similar issue a while back with SSL certs wasn't there. When will people learn how to deal with null bytes properly :/


I could similarly ask, "When will people learn that null bytes are a terrible way to terminate data?"

But that ship sailed eons ago.


After mangling a number string operations (and the program memory space) when first learning C I realized how terrible they could be. If I can mistakenly destroy my memory space, what would a malicious mind do with such a thing?


This is a very good reason to use a language with built in memory management.


So the problem is that people are using naive string implementations (character arrays) instead of proper strings?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: