An argument against OpenBSD, qmail, et al.

[zencoder]

Originally posted here by catch
Without formal V&V a "secure" software product is little more than assumptions:

I assume this product the type of security I need.
I assume that the implicit rules have been sufficiently tested.
I assume that there exists no ways to take advantage of flaws that I don't know about.

Here is a not-quite recent article regarding one of the very products illustrated for this discussion, and an issue over a 'security vulnerability'. Take it as you will, but I think it defends the position catch has taken.

Link to full article.

...<snipped and paraphrased, my apologies to Jason Miller>...
(Dan) Bernstein designed qmail with security in mind. If everyone who wrote software actually made security a design priority, we'd be in a lot less trouble with vulnerabilities than we are now. But it appears this is too much to ask, because there's so much software out there that doesn't seem to put much more than a casual afterthought into security.

Secondly, Bernstein strives to write bug-free code. Although this is an unachievable goal, it didn't stop Bernstein from trying. His code has now stood the test of time, and has done so with a very small security vulnerability footprint.

The combination of these two factors has made qmail a very successful application for secure environments.

Qmail isn't perfect

Georgi Guninski recently published a vulnerability in qmail (albeit not a practical one), which can be exploited on specific configurations of some 64-bit systems. That's right. Even qmail has bugs. This shouldn't be a surprise to anybody.

If you're familiar with qmail, you'll undoubtedly be aware of the qmail security guarantee, which offers a monetary reward to the first person to publish a "verifiable security hole in the latest version of qmail". Bernstein has publicly denied this reward to Guninski, with the statement that "Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." This basically means that Bernstein doesn't consider this to be a security vulnerability.

Despite the fact that the vulnerability may have only academic merit -- it doesn't seem very likely that this will be exploited in the wild -- it is still a security vulnerability. As far as I'm concerned, the offending code should be fixed. I don't care how circumstantial it is; not fixing the issue accomplishes nothing.

The fact that software developers feel the need to maintain some sort of "clean record" that might be more important than tidying up even potentially vulnerable code, is quite disturbing to me. If the information security industry is creating this kind of environment for developers, then we're doing something wrong.

A clean record counts for nothing
...<snipped>...

I felt it was important to point this out to you all. Dan does not feel inclined to acknowledge this as a threat. Jason (that author) clearly feels it is a valid vulnerability, regardless of likelihood of exploitation. At what point does a threat become an "official" vulnerability? And by whose voice/hand?

I don't have the answers, I'm just throwing this in to stir things up^U^U^U see what you all think. I do think that Jason's message, in closing the article, was paramount, even though his position may be opposite of catch's. 'Practice' is more important than 'polish'.

[chsh]

I read about that vuln, but had a laugh when I read:

Details:
note:
- you need more than 4GB memory per process for this.
- gdb line numbers may not match because of small changes in qmail src
- tested on athlon64 8400+ with linux

And then again, this vulnerability is mitigated by the fact that no, I doubt there is anyone out there dumb enough to give each process more than 32 bits of addressable memory. Hell, QMail can run corporate mail services for 1100 users without choking on around 250MB of RAM peak (#s from memory). I'm trying to imagine a system where a single mail server would ever need that much RAM.
By the time anyone comes close to being able to exploit this vulnerability, there will be new versions of the software because it will be commonplace to have 64 bit precision and addressability. But it is still a vulnerability.

[gore]

Maybe if Hotmail, Yahoo, AIM mail, Gmail, and Hushmail all ran on the same box

[jinxy]

This is a security discussion, as such. although this is a little off topic. I think still valid as a metaphor (perhaps).

In a shop I used to work in, the insurance company, that under wrote the loss from theft, insisted a five leaver moron (or is it mortice) lock was fitted to an external door. The lock was a tried and tested security mechanism. The door unfortunatly was patched and painted to all hell. This equalled a door you could open by leaning against. Even though the shop had spent, comparitivly speeking a lot of money on a secure lock.

[spurious_inode]

Originally posted here by gore
You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth".

Oh and "It's Free" yea, as long as you buy the CDs.... Or do the FTP install... No remote wholes in 7 years in the default install.. Does that REALLY say something about an OS that boots up without anything even open to begin with?

I haven't been robbed in over 7 years, maybe because I walk around with an SK-47 and no money.... Wow I'm secure!

Maybe I can be a walking turnip like Theo now and have morons kiss me...

First, let me thank you gore for telling us what you really think.

For me, this cuts to the chase on the whole question of 'secure' systems. Software and Computer Security are at odds with each other. It is the way it has always has been, and probably will remain for some time. I am an OpenBSD fan, but I also recognize that the meat of what you said is true.

If asked to build an FTP server, and put it in the DMZ for public, i.e. unrestricted use, I am going to grab some hardware and my Solaris 9 media and spend the next 5 hours installing the most minimal system I possibly can. Then further stripping it down to only the absolute essentials to allow Solaris to function properly, a secure and stable FTP server, remote logging over an SSH tunnel to a logging host. Depending on it's purpose, I may not even install the Tivoli client and do backups on this host; having all the truly important stuff somehwere safe of course for DR.

The point? In the UNIX world anyway, software = security liability. No matter how secure some experts say it is, or how much I spend on super-special-secure OS licenses and support, the more software I have installed the more avenues of attack I have left open. I don't have to spend every waking moment reading bugtrack to see if some useless piece of software is going to get me hacked; thus am free to get other work done too. That was the point behind the way OpenBSD comes by default.

bw, ... Actually, OpenBSD hard-cores will all tell you that inetd and common Unix services are all on by default, which is true.

Make sure your face is clean now, can't have no dirty dead...

[gore]

Heh, so am I going to be here, in a BSD london dongeon?

You know I say what I feel