Weblog
9 September 2012, 21:49
The most important change in this release is a bugfix. Hiawatha could crash in case of a high amount of simultaneous connections due to the usage of select(). I replaced this function with poll().
Other changes are that Hiawatha now returns 403 instead of 401 when a user entered a correct password for HTTP authentication but he/she was not in the right group and the style of the error messages has been restyled.
Copyright © by Hugo Leisink. All rights reserved.
Built upon the Banshee PHP framework.
Built upon the Banshee PHP framework.
Also, to Samiux, note that while you don't have to trust my packages, having a full build environment on a production webserver is probably not the best of ideas. If you're constrained on resources, I'd recommend setting up a clean build environment in a VM (VirtualBox is free and great for this application), then dropping the (preferably signed) ruslting package on your webserver. This isn't just Hiawatha specific though; I strongly recommend that type of process for any production server.
We are now talking about the exploit.
Since my Hiawatha setting is running under the control of AppArmor, the attacker cannot gain execute rights on /tmp and Hiawatha directories even s/he can complie the the exploit code (if any). The most likely, if s/he can break into the web server, s/he can only do the thing is just defacing, I think.
Therefore, the compiler in the box is not the serious problem in this case, in my own opinion.
Sorry, I've only just noticed you replied to my earlier comment. The main reason I propose building the packages in a clean environment is not because of the idea that attackers will use a build environment to gain control of the system. After all, if they have a shell in the first place, you're already in a very bad situation. Rather, it's that when dealing with an environment that will directly touch Internet traffic, it's prudent to assume that you're in hostile waters, and that the box in question may not be 100% trustworthy. Not having a full build environment on production hosts means less cruft, and an environment that is theoretically easier to manage and audit. Further, to me it makes sense that one conserve the often constrained resources on web heads and build on an off-line system, rather than competing with customer traffic. Just some friendly advice.
-C
If the victim box has no compiler, hackers can compile their code in his box and upload to the victim to execute. It is not a big problem to hackers.
I don't disagree with your point, that's why I said: "The main reason I propose building the packages in a clean environment is not because of the idea that attackers will use a build environment to gain control of the system." However, I do feel that separating the build function is worthwhile for several reasons (listed in my last post).
All the best,
-Chris