> So, here's my favourite example of the "bad implementation" problem: > AWstats. It's had a long history of: > > o Someone finds yet another way its stats-generating CGI can be subverted by > sending it aberrant URL information from the public. > o The upstream maintainer issues an update. > o Debian issues a new package. > o An exploit emerges and gets rolled into automated attack tools. > o Lather, rinse, repeat. > > If you look more closely at AWstats, you might start to wonder: "I > guess the author never quite got input validation right. But why > does it have to run as a CGI (awstats.pl) in the first place? Can't it > run as a cronjob, instead, generating the same stats page as static HTML > every hour, instead?"
The most recent vulnerability that I was aware of in Awstats can still work even in static mode. http://www.securityfocus.com/bid/14525. The referrer in the log file is not sanity checked. Unfortunately awstats seems to have organically grown as a single perl script. This one script is upto almost 50000 lines of code. I've looked a little at the code, and I can't say it is easy to follow. But it does seem to do a good job of generating stats. I just don't feel comfortable trusting it on my servers. > > And you'd be right to wonder. That's a solved problem, thanks to Steve > Kemp over at debian-administration.org: > http://www.debian-administration.org/articles/85 > > I keep meaning to file a very polite bug with Debian maintainer Jonas > Smedegaard, suggesting that static-page mode be the default since > upstream's CGI default is (in my opinion) too risky, but I haven't done > that yet. > I would agree with that idea. In fact, I've just lodged a bug report along those lines. Bug #341308. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
