Ok, enough time spent on G-WAN already, I’m getting a serious amount of abuse from the vendor from what they feel is “fear” for this software. Reading the forum you get a feeling this a close to a cult with people writing single entries of the like of “In G-WAN we believe.” multiple times to “support” their leader. The whole thing gives a quite unpleasant aftertaste.
The developer of G-WAN currently proceeds to pretend the buffer overflow never existed and that this instead was a temporary signal handling problem to try to hide the seriousness of the problems from the users. This brings us right back to how security was handled 20 years ago with obscurity being the main strategy for dealing with security. This despite the buffer overflow already having been successfully exploited. The dishonesty is remarkable.
I will say this as a final statement. I’ve done black-box testing and source code reviews of a lot of software and after having done this a while you get a certain “feeling” for what you are looking at. Doing penetration testing is about searching for undefined behaviour, investigating it and seeing if you can actually use it. In a matter of speaking you “poke” the software and look at how it behaves. With software written by a developer that is very conscious about security you typically poke it in many ways without being able to provoke it. With badly written software you poke it and it gives you all sorts of undefined behaviour, and the challenge is then finding a way to exploit the behaviour.
Testing G-WAN I get a very bad feeling and I find it, sadly, to be in the latter category. That is just my personal view, talk to the vendor and you’ll a very different perspective including viewing me as some kind of demon with hidden agendas come to haunt them and tell lies.
As a brief example is the URL parsing routines. There are actually, at least, three different implementations.
- The HTTP/0.9 which did not terminate the decoded string and ended up being broken
- The HTTP/1.0,1.1 static file implementation, which did not parse URL parameters at all
- The HTTP/1.0,1.1 “csp” implementation, which contained the buffer overflow
As any experienced developer will tell you doing the same thing in three different ways is just bad practice. This pattern is called OAOO (Once And Once Only), or in this case, lack of.
The daemon does not implement any chroot or similar “sandbox” to limit the consequences of a vulnerability. Doing this would have lessened the impact of the vulnerabilities.
I would recommend any user of G-WAN that actually uses it in a production environment for a professional service to have a serious look at their use-case and consider whether G-WAN actually fits the bill. My personal view is that G-WAN is far from a production quality software.
lonewolfer 
I removed the comment about G-WAN running with root privileges. In several places it is recommended to run G-WAN as root, but as the author points out it is indeed possible to drop privileges.
Hi, I read you’ve made a new benchmark tool called pounce.
Where can I download it?
Can you make a new post for your benchmark tool explaining it?
Unfortunately, G-Wan’s author propaganda and Wiki war (like constantly removing the link to your report from http://www.wikivs.com/index.php?title=G-WAN_vs_Nginx) seems to be working quite well, since I wrote an article about G-Wan (http://weblambdazero.blogspot.com/2011/09/human-factor.html) in September 2011 and it wasn’t until recently when I found your security report. When you look at the comments to the post you will notice that it was literally invaded by some G-Wan trolls (or, quite possibly, Pierre himself hidden under different nicknames) who have constantly tried to prove that G-Wan is another wonder of the world, Pierre is another Jesus, and I am paid by CIA, NSA, Microsoft and Nginx (not necessarily in this order) to destroy his reputation.
You have done a really great good job, keep it up!
Yes, to take part in the world of G-WAN was a strange and kafkaesque experience. There was quite a bit more to say really both with regards to performance, stability and security, but the time and energy can be better spent doing other things no doubt.
Hi lonewolfer, I found you blog by accident while Googling for technical information on GWAN. After being exposed to grand claims about GWAN so often, I decided that it’s time to take a closer look. Well, color me impressed: despite Pierre’s grand personality there are quite a lot of gems to be found in GWAN. For example, I am very impressed by his C servlet implementation. It protects against crashes seemingly without using processes. Would you be interested in posting more analysis about GWAN in the future?
But regardless of GWAN, I find you blog posts so far very interesting and I hope you would write more in the future. 🙂 It’s clear that you have a lot of expertise in your area.
It only catches the SIGSEGV etc signals. It does not “protect” you against anything, a boundary overflow would still be potentially exploitable, and so forth. After looking at GWAN more closely I find it to be very uninteresting and unimpressive, and would strongly advise anyone against using it.