Say no to ProFTPD January 15th, 2008
It looks like people are still recommending ProFTPD. I wish they wouldn't. This isn't news. It's an opinion I find myself repeating frequently, and now I'll be able to cut'n'paste or provide a URL as appropriate.
Search the National Vulnerability Database for vulnerabilities disclosed against vsftpd and ProFTPD during 2004, 2005 and 2007. You could search all of time, but that would give you a skewed view, because ProFTPD is older than vsftpd, and because you need to allow for software becoming more secure over time.
You'll find 8 vulnerabilities in ProFTPD. One of them is an authentication bypass vulnerability. The rest are stack and buffer overflows that allow denial of service attacks and remote code execution.
You won't find any vulnerabilities for vsftpd.
I used to buy the argument that ProFTPD is more feature rich. But recently, I set up vsftpd for a customer, providing chrooted sessions for virtual users. It was a lot less hassle than it is with ProFTPD.
Interestingly, vsftpd is (at the time of writing) the FTP server software used by kernel.org, the Linux kernel distribution site. From the perspective of a black hat, there aren't many non-commercial sites that would be more useful to break into, so their threat exposure is probably high.
Say no to FTP. If you can't, say no to ProFTPD.
The fundamental flaw in PC security March 8th, 2007
Heard in the antispam community (and reproduced with permission):
The fundamental flaw in the idea of DRM is that it's not possible to simultaneously show something to someone, and not show it to them.
Is the fundamental flaw in PC security that it's not possible to simultaneously allow users to execute arbitrary code (or make arbitrary network connections, or whatever) and not allow them to?
Huey Callison
Astute, I thought. I've known for ages that the RIAA is ripped off repeatedly by crackpots who claim to have the final ultimate solution to digital rights management, because of this problem. But it had never occurred to me that PC security is the same class of problem.
Until users can't execute arbitrary code on their own personal computers, the security of those computers is a measures / counter-measures game at best.
This is worth bringing up next time someone in the board room laughs at you for suggesting you deliver application functionality via the web.