A while back I was looking for a new way to exploit applications and I ran past a simple programming style which leads to predictable branching inside the application. It can lead to really hard to track down bugs inside your application. It has to do with some people declaring variables, and then not initializing them properly. Per the documentation for the linux and UNIX operating systems I have checked the variables are supposed to be auto initialized with the /dev/random when created. I have found that this DOES happen but only in select variables in select positions inside the application. This means say you start out with 4 variables created, 2 out of the 4 are predictably “0” and 2 are initialized with a random number. So were thinking “who the (@*$ cares right?”. This is where it gets interesting. As you program and get deeper inside the application branching occurs within the code. It is quite possible that some braches are conditional, and if you forgot to initialize your variables you may branch or not branch even when you were intending the other.
I have checked the following operating systems: Linux (all) Solaris X86 *BSD.
Yes even OpenBSD seemed to have this problem last time I was using it. WHich is real funny because if you look at the code for OpenBSD they use a random number generator for new variables. Oh well.
Here is code (simple and sweet) for you to check if your system has this problem:
using namespace std;
cout << a << “n”; cout << a1 << “n”; cout << a2 << “n”; cout << a3 << “n”; cout << a4 << “n”; cout << a5 << “n”; cout << a6 << “n”; cout << a7 << “n”; cout << a8 << “n”; cout << a9 << “n”; cout << a10 << “n”; cout << a11 << “n”; cout << a12 << “n”; cout << a13 << “n”; cout << a14 << “n”; cout << a15 << “n”; return 0; } As you will see by compiling with: g++ test.cpp then running ./a.out The results are kinda freaky. Not only do very specific variables has a “0” value, the random number generator seems to have create 2 numbers and initialized 3 variables with the same number, and one with the other. This is also predictable. Here is some sample output: fuion@laptop:~$ ./a.out 2 0 4196941 0 4196064 0 0 0 4196864 0 4196064 0 284099424 32765 0 0 fuion@laptop:~$ ./a.out 2 0 4196941 0 4196064 0 0 0 4196864 0 4196064 0 690163968 32765 0 0 As you can see it is very accurate (the prediction of which has what). I would not say this is anything as simple as finding a buffer overflow, but this predictable logic can lead to some applications allowing things that they shouldn’t simply by finding this programming error and controlling any of the variables. Please let me know if you find any of this useful. -Casey