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.
ESI is running an article about a potential information disclosure at Southern Connecticut State University.
Southern Connecticut State University has alerted current and former students after a review of a university web site discovered a vulnerability that could have allowed an unauthorized individual access to personal information. During a recent review of a web server, the university discovered that unauthorized individuals could have had access to applications for graduation dating back to 2002.What I find interesting in this is that the university chose to notify students, while there does not seem to be proof of a disclosure, just a vulnerability that could potentially have been abused. All affected students (past and current) are offered two years of credit watch.
Source: ESI press release
I am involved in the development of the Application for Incident Response Teams (AIRT). AIRT is GNU GPL-licensed Free and Open Source Software that is designed to do one very specific task very well: to support computer security incident response teams (CSIRTs) in the bureaucratic aspects of incident response.
AIRT allows CSIRTs to receive incident reports, extract the relevant information from them, create incident tickets, follow the process flow of handling the tickets, and communicate with the teams that are handling the incidents, or track incident handlers. A lot of AIRT's development is directly influenced by SURFcert, the Dutch National Research and Education Network's CSIRT.
The author argues that information security should focus much more on software-based attack vectors, instead of concentrating on network and operating system attacks.
If you are an old school hacker or old school security professional, I'm going to be upfront with you. Old school hacking is dead, network hacking is dead, firewalls are useless and AV software is a mere redundant software package that underlines your frustration and ignorance about contemporary hacking. Defense in depth is deceased since the nineties and it will never come back. The Internet is operated with knowledge that stems from the late eighties and nineties. All you learned about the Internet from the seventies 'till the late two thousandths is dead. It is no longer the landscape we work on. It is no longer the Internet of today, it is certainly not the Internet of tomorrow. It belongs into history books and nothing more. It is crucial to understand this. If we do not agree, the security field stays behind the facts of today.
Source: http://www.0x000000.com/?i=536
Martin has always been fairly positive about the ScribeFire plugin for Mozilla Firefox. True, it has its quirks, but the plugin seems to work fairly well. I decided to also take a look at it, but was unable to get it to work at my first attempt. I just could not get my blog added to the interface, yet I am running a supported engine (Movable Type). ScribeFire insisted that I provided an invalid username/password.
Here is what I did to get it to work.
The current issue of IEEE Security & Privacy features an article titled Becoming a Security Expert.
In it, the authors (Michael Howard, Microsoft) ponders about the question: "How do you try to learn security?"
