On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
> The smtpd code is very good.
static void
filter_tx_io(struct io *io, int evt)
{
struct filter_session *s = io->arg;
size_t len, n;
char *data;
char buf[65535];
switch (evt) {
case IO_DATAIN:
data = iobuf_data(&s->ibuf);
len = iobuf_len(&s->ibuf);
memmove(buf, data, len);
buf[len] = 0;
>
>
> On October 5, 2015 12:47:18 PM EDT, "Jason A. Donenfeld" <ja...@zx2c4.com>
> wrote:
> >Hi folks,
> >
> >Like many others, when I learned that OpenBSD was creating from
> >scratch an SMTP daemon, I was thrilled. The OpenBSD name has for a
> >long time been connected with security, stability, and reliability. I
> >was excited to see an extremely easy to configure yet powerful SMTP
> >daemon coming from such a venerable project as OpenBSD. Overtime,
> >OpenSMTPD has replaced all other mail daemons for me, and I've been
> >pleased to use another OpenBSD project as part of my critical
> >infrastructure. Code from OpenBSD is code that the community has
> >learned to trust, a reputation matched by few other projects.
> >
> >It has been, therefore, to my extreme dismay to discover in recent
> >months the sheer number of critical security vulnerabilities - in some
> >cases, remotely exploitable - in OpenSMTPD. Just this past week,
> >Qualys has reported an impressive audit result [1], with a scary
> >remote code execution vulnerability among others, and last night I
> >discovered a remotely exploitable buffer overflow that was being
> >triggered in the wild [2]. If you comb through the OpenSMTPD misc
> >mailing list, you'll find scattered reports of other similar bugs --
> >buffer overflows, remote denial of service vectors, and a host of
> >other nasty glitches and security vulnerabilities -- and if you look
> >at the CVS repository or git repository, you'll see other such goodies
> >baked in there; most of them haven't been publicly revealed as
> >security vulnerabilities and were not assigned CVEs, which is an
> >irreverent point for most reasonably skilled malicious actors.
> >
> >The fact is, OpenSMTPD has suffered a disproportionately high number
> >of security issues, especially for a daemon as important as it. It is
> >not living up to OpenBSD's reputation, and it threatens the
> >OpenBSD.org frontpage security claim. I do not any longer believe
> >OpenSMTPD to be software that is trustable for use in critical
> >infrastructure at this point in time.
> >
> >Personally, I am very attached to OpenSMTPD. I have contributed to its
> >development in, what I think to be, significant ways, and I maintain
> >both distribution packages for it (Gentoo), as well as my entire
> >infrastructure, which is based on OpenSMTPD. I've "bet the farm" on
> >the project, so to speak.
> >
> >But I think it's time we take a step back and reassess the situation.
> >There are some critical questions that need to be answered. What
> >accounts for the high proportion of security vulnerabilities in a
> >project renowned for its brilliant developers and stringent review
> >processes? Do the OpenSMTPD developers have time -- and have they
> >displayed a presence of necessary free time -- to keep the project
> >healthy and moving toward stability at an acceptable pace? Have the
> >correct standards of releases been applied to the OpenSMTPD release
> >process?
> >
> >And most importantly: should OpenSMTPD continue to be a part of the
> >core OpenBSD project? Or should it rather spend some time maturing and
> >securing commitments from developers for maintaining it in a
> >consistent manner, before being accepted by such a reputable
> >organization as OpenBSD?
> >
> >Finally, if OpenSMTPD does continue to exist as a part of core
> >OpenBSD, I would strongly recommend some effort is organized to bring
> >top quality code reviewers and auditors to the source code, in order
> >to give the project the eyeballs it deserves. It would be a great
> >boost in confidence for many who use - or hoped to someday use -
> >OpenSMTPD to see that intelligent minds, capable of securing large
> >codebases, have put their efforts into making it secure.
> >
> >I hope this can begin some discussion on the best way forward toward
> >making OpenSMTPD a piece of infrastructure we can trust. My best
> >wishes for the project.
> >
> >Regards,
> >Jason
> >
> >
> >[1] http://seclists.org/oss-sec/2015/q4/17
> >[2] http://seclists.org/oss-sec/2015/q4/25
