Life as Security Engineer is more funny when you put some time looking through codes and trying to find vulnerabilities and fix it, indeed!
That was one of my first attempts that I’ll tell you and how I failed miserably :). Well sometimes s-happens. But in the second round I could find a memory leak \o/. It wasn’t a expose sensitive info or execute arbitrary code but at least something was found.
But lets start in the begin…
There are plenty of vulnerabilities around and thanks to Intel more and more every day (I’m kidding Intel <3). So, in order to starting in this kind of adventure I grab some books, and start to read about how are the more often vuls, what kind of techniques are used to fix or find it and so on. In all those reads one thing is repeated constantly “take always a look in points where the user entry some info”. Yeah, users + vulnerabilities can really blow up things in a software. As a nice code to look I thought in one that use sometimes to time: dos2unix package. It’s a nice tool and useful one. As my first attempt was to look in code were users can input something and so far so good everything looks fine but one variable grabbed my attention localedir. It’s a buffer of 1024 size. Its content is filled by some internal functions with the value of DOS2UNIX_LOCALEDIR env variable. So I thought what if I set this with a large size and try to overflow it? Here was my first failed because the code check this: if (strlen(ptr) < sizeof(localedir)), where ptr = getenv(“DOS2UNIX_LOCALEDIR”). It was so disappointed for me :(. So I saw that this variable is used to be printed in stdout and I thought “hm, what if I try to put some bash code there and see what happens” – That was my second fail :(. If you do something like: export DOS2UNIX_LOCALEDIR=”`tail ../../../etc/passwd`” by example you will end up with the content of tail into the env var. At first I thought I was executing the command into it, but it wasn’t the case 😦 I didn’t pay attention in the acute accent and what it does (execute the command and return its ouput). It was a shame to report that so happy it was a vul issue. But ok, we learn with mistakes…following in the code I just decided to run valgrind on it and voila! I got a memory leak. Well, not the ideal one, but it was a leak. What happens is that in the code a variable called pFlag is allocated but not freed and that is a memory leak, but unfortunately (again) this happen in program/process that runs just on time, what means that in the end of it the OS request the memory and who cares about that leak. :(. Well, lesson learned.
Core Code 