Recently in Secure Coding Category

Sometimes I need to play around with some digital certificates and I do not feel like shelling out a lot of money each time to buy real ones. Here's how to set up your own CA (certificate authority) in a quick-and-dirty way. Please do not use this guideline to set up a real CA!

The scenario in which I am interested is to set up a single root-CA, which signs the certificates of two sub-authorities. The sub-authorities are the entities that actually sign the end-user certificates. I will create one sub-authority to issue person certificates and one to issue site certificates.

A detailed description of my efforts has been posted.

I've been trying to get some very simple buffer overflow code proof-of-concept to run for quite a while. While I always thought I had a good understanding of what a buffer overflow is, and how it can lead to Badness, I was actually never able to recreate a deliberately vulnerable application and exploit it.

The problem that I kept on running into was that I was unable to point the instruction pointer to a point in my NOP-sled that would be correct the next time that the code was invoked.

Well, as it turns out, the problem wasn't with my code, or with my exploit, but in the Linux kernel that I used. After spending an insane amount of time trying to Google up why it didn't work, I finally found that I was missing one simple step:

# sysctl -w kernel.randomize_va_space=0

As it turns out, 2.6 Linux kernels randomize the address space of new processes when this option is set to '1', which is exactly the problem that I had. This makes a great deal of sense, since there is really no need to NOT do this. Adding that kind of randomization makes buffer overflows much harder to pull off.

Another option that is useful to know about when you want do demonstrate buffer overflows is --no-stack-protector option on gcc. Without that option, gcc adds a guard variable to functions with vulnerable object which adds extra code to check for buffer overflows, such as stack smashing attacks.

These two bits of knowledge finally helped me connect the dots and allowed me to finish up my demo code.

Every now and then, I dabble in coding. Every time I develop software, I realize that writing code that does what it supposed to do is not all that hard. However, writing code that does exactly what it supposed to do, and only what it is supposed to do, is incredibly hard.

Automated application testing is a very valuable tool. Systematic and complete checking of all inputs and outputs is something that is incredibly tedious, labor intensive, and as a result, takes a lot of time and patience. That also makes it a very expensive process to do manually.

Good tools are available to test each input element and each output element of a web application, and their use should be far more wide-spread than it is now.

Web application security is about much more though; it involves session handling, authentication and authorization, access control, cookie theft, replay attacks, URL manipulation, intrusion detection (and prevention), etc., etc. Good people who understand these issues in-depth are rare and deserve all the credits that one may give them.

In addition to using automated tools to test the application, peer-review of code is a good thing and it may catch ugly solutions or design flaws. Using "eyes on lines" it becomes much easier to catch backdoors, or other code vulnerabilities that might not be obvious to find using automated tools.

All in all, we need to do much more quality control on code before it gets released. Automated testing tools must be run before code gets released and careful peer-review of code should be embedded in the full software development cycle.

Robert Graham over at Errata Security has a very interesting post up. The topic of the post is confirmation bias, a well-known concept in science that revolves around the idea that a theory is only valid when you can not disprove it (rather than when you can prove it).

"Because of this, the first time somebody misconfigures BitTorrent to use too many connections, the router crashes. Likewise, internal processes within the router crash often and silently restarting without being visible from the outside - but still passes QA tests because they aren't looking for that. Anything unusual that the user does is likely to cause a crash."

Definitely an interesting read.

Happy Monday.