
Is OpenSMTPD worthy of OpenBSD inclusion? - zx2c4
http://thread.gmane.org/gmane.os.openbsd.misc/225512
======
jerf
It's an SMTP server, started just two or three years ago, written by people
who care about security and hope for it to be included in OpenBSD, written
in... C.

(Edit: Corrected by vezzy-fnord, started in 2009.)

The only currently-extant memory-unsafe language.

I... just... argh... when we will finally be rid of this albatross? What hope
is there for the world of computer security if we can't even greenfield a
solution to what has already proved to be one of the most dangerous security
domains there is (thanks, sendmail) in something other than C? Why are the
words "buffer overflow" appearing in relation to such young code? What am I
doing with my life? Why am I even trying to write secure code in a world where
this is even remotely considered an option?

~~~
rhelmer
I am hoping that Rust will make in-roads into the BSD world, since it
interoperates well with C and is much safer by default while not imposing
overhead like a managed language+runtime would. It also has very liberal
licensing (GCC being GPL has always been a tough pill for some to swallow,
FreeBSD at least has already switched to Clang) [https://github.com/rust-
lang/rust#license](https://github.com/rust-lang/rust#license)

The OpenBSD folks have done great work through auditing and writing safer code
in C, and I agree that using a language that ameliorated at least some of the
common mistakes programmers make would be a net positive.

Related - this blog from @tedunangst is worth reading, regarding the limit to
which even a language like Rust can protect against specific exploits (the
OpenSSL "Heartbleed" vulnerability, in this case)
[http://www.tedunangst.com/flak/post/heartbleed-in-
rust](http://www.tedunangst.com/flak/post/heartbleed-in-rust)

~~~
supdog
From what I understand, Rust is not making in-roads into the OpenBSD world for
at least these reasons:

1) Rust's use of LLVM means it will not work on some hardware platforms that
the OpenBSD folks are committed to run on.

2) The Rust project currently does not offer a long term support release.

These are important to the OpenBSD team. Additionally, I am sure that they
value the memory safety that Rust offers.

I wonder if the OpenBSD team would ever design a systems language?

~~~
rhelmer
Note I said "BSD World" :) FreeBSD is already using LLVM (Clang) instead of
GCC, and support fewer platforms - I think this would be a more pragmatic
place to push something new like Rust.

If it works out there, OpenBSD could audit and import things at their leisure,
at least in theory.

------
oal
I ran my own mail server using OpenSMTPD and Dovecot for a little over a year,
and found OpenSMTPD to be very easy to set up and configure. I needed
something light, that I could easily tweak to fit my needs. I mostly got
things working reading the man files, and asking for help in the IRC channel
(thanks Gilles). I also looked into Postfix, and I'm sure it's great, but the
amount of configuration options were a bit daunting.

I think the project deserves more contributors and more eyes to look at the
code. A fantastic foundation has been laid, but we can't expect Gilles to be
able to do it all alone. This is a diamond in the making!

~~~
nickpsecurity
I think you stumbled onto the recurring problem:

"we can't expect Gilles to be able to do it all alone"

Just like with GPG. In FOSS circles, there's all kinds of people that want to
take the code but few to create it. So, people gripe about the state it's in
while putting no effort in to improve it. At least the author contributes
significantly. However, gotta wonder how many users it has vs how many are
contributing code/audit.

Bet the difference has an impact on the situation. It's why I spend time here
and there investigating proprietary, open-source models that require money or
contributions to use the software. Doesn't even have be a lot: at least enough
for a significant product to support at least one developer. That way the
users are always investing into it and esp bug fixes happen.

~~~
stsp
gilles operates in a community where problems like this are taken very
seriously, and where enough developer resources exist to sweep the smtp code
base several times over. I expect a lot of fixes coming up over the next few
weeks.

The real problem is that the OpenBSD community didn't realise the state of
things internally, because gilles and eric were trusted to not fuck up. This
happens, since not everybody has time to follow every corner of the tree all
the time. But when focus on a particular area is needed we can do it.

It's good that Jason pointed out these problems, however the manner in which
this was done creates huge public exposure which puts pressure on all of us
(especially gilles and eric) to produce results very quickly while we prefer
moving slowly and being careful because that produces better results in the
long term.

~~~
nickpsecurity
To be clear, I wasn't smearing any developers or the project relative to
others. Just noting a common problem in OSS development that probably hurts
their project to some degree.

Appreciate you adding detail on the project's situation. Also on how you all
view the post and its effects. As HN gets exposure, do you a specific,
alternative approach for anyone reading that might end up Jason's shoes to get
the OpenBSD team focused on a particular project and digging into it? I'm
guessing he didn't make an attempt outside the public disclosure or made an
ineffective one.

~~~
stsp
Find out who's been involved with the area of the code base recently, and mail
all their @openbsd.org addresses directly in one mail.

If they don't reply after a few attempts, or give unsatisfactory answers, try
mailing Theo. He acts as arbitrator in such situations.

If even that doesn't help, your last option is to write good fixes yourself,
and keep submitting them as diffs to tech@ until you're either banned from
posting to the list (at which point you should just give up) or your diffs end
up being commited.

~~~
nickpsecurity
That's crystal clear: now anyone reading knows the best approach. Makes sense,
too. Except that last part.

I agree it's the best option to rollup the sleeves and just fix the problem
you're griping about. However, a write-up like Jason's is a valid option, too,
if person doesn't have time/resources/skill for that option. Because, at that
point, known issues would've been ignored by everyone up to Theo despite it
being in default install and under OpenBSD's quality image. A write-up drawing
attention to the issue would be justified to prevent users from placing
unjustified trust in that component. Being informed lets them take action
either on improving the component themselves, limiting damage it could do, or
just avoiding it altogether.

Still agree that the gripe should go to the developers and Theo first.

~~~
stsp
But Jason did send diffs, and we are discussing his situation as an example.

Anyway, like it or not, in the OpenBSD community, working diffs, especially
ones that fix a security issue, are the best way of winning an argument. You
can try to blog about it but you probably won't be taken as seriously. So if
you really care to convince the community from the outside and everything else
has failed, and you can't code C youself, find a friend who can and ask for
help.

------
vbezhenar
What worries me is the lack of updates for OpenBSD. Is those issues he's
talking about are for real? I run "pkg_add -u" frequently and I don't see any
updates. I'm running "stable 5.7". I understand that OpenBSD doesn't provide
updates or bugfixes after release, but security updates should be pushed.

I'm casual OpenBSD user and may be I don't understand something.

~~~
msbarnett
> I'm casual OpenBSD user and may be I don't understand something.

Yikes.

"pkg_add -u" is just for ports/packages. Security updates to OpenBSD itself
are distributed via patch and are listed here for your version here:
[http://www.openbsd.org/errata57.html](http://www.openbsd.org/errata57.html).
Explanation on how to apply them is found in the patch file itself.

~~~
snksnk
Just to be complete, the openup utility from M:Tier covers this as well (see
my other comment for more details).

------
cenal
Probably a dumb question but why did the world need another SMTP solution?
What was OpenSMTPD supposed to do better?

~~~
zx2c4
It's a lot simpler to setup and configure than Postfix or qmail. It promises
all the nice privilege separation of those daemons too. The appeal for me
initially was that it would be small, simple, and very secure.

~~~
nickpsecurity
Could people have just improved the configuration or setup of already rock-
solid qmail?

~~~
tedunangst
The qmail code and configuration are both quite unlike what many people are
used to. It definitely wasn't being imported with the config/service model it
uses, and reworking it to be like every other daemon would involve a lot of
code changes.

~~~
nickpsecurity
Appreciate another insider viewpoint. Going by this:

[http://cr.yp.to/qmail/qmailsec-20071101.pdf](http://cr.yp.to/qmail/qmailsec-20071101.pdf)

Do you think they could apply any of that to current project? Particularly in
sections 3-5. I defer to you here as your experience is directly relevant.
Would any of his approach, on top of looking for top 10 C issues, have
improved the security of this app? Or was none of that applicable?

~~~
tedunangst
I think the approach is quite similar, but the devil's in the details. From
looking at a couple bugs, the efforts to reduce TCB were not as effective as
hoped.

------
nickpsecurity
"it threatens the OpenBSD.org frontpage security claim"

This misinformation is my only problem with the article. That claim has
probably never been true. If it was, they wouldn't be regularly fixing shit
that might be exploitable. Still, I came up with a way to test it years ago on
Schneier's blog for anyone that wanted to try:

"Watch mailing list for bug announcements. Quickly determine if it's
exploitable. If so, turn it into a payload. Hit target system. Profit." So,
it's special in terms of quality focus but still can be hacked if anyone
bothered to try. (Few bother.) Especially at layers below kernel that they
don't care about, privilege escalation because they refuse M.A.C., in a VM
because Theo doesn't worry about those issues, and covert channels because
they probably never heard of them.

Note: It's reputation adds more risk as it's often used for "fire-and-forget"
appliances. This can be reinterpreted as "they don't patch or they patch very
rarely." The more they trust it, the more likely the bad guys get in. ;)"

~~~
ghshephard
"That claim has probably never been true."

Well, pretty easy to disprove. All you have to do is name a single remote hole
in the default install in the last, oh, 8 or so years.

~~~
nickpsecurity
Real quick, as I'm clearly not an OpenBSD user. Does the "default install"
include the apps a deployment will almost certainly use? That is to make the
claim meaningful. And have there been any software defects in OpenBSD or its
critical apps over past "8 or so years" that could've been exploited by
attackers?

That would be a start. My guess was that OpenBSD team didn't track (and update
web site claim for) the number of defects that might have been exploitable:
just fixed all defects as they found them instead. If so, that makes for great
QA practice but inaccurate claim on web site. Otherwise, there's a tracker
somewhere listing all bugs found in privileged software, their exploitability,
and time it took to fix them. That tracker will have a huge list of issues
with only 2 marked as security issues.

~~~
ams6110
OpenSMTPD is in the default install, however in the default configuration it
does not accept remote connections.

~~~
nickpsecurity
That's a good start.

