9 ms·

Is OpenSMTPD worthy of OpenBSD inclusion?

66 points by zx2c4 11y ago

cenal 11y ago
Probably a dumb question but why did the world need another SMTP solution? What was OpenSMTPD supposed to do better?
- zx2c4 11y ago
  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 11y ago
    Could people have just improved the configuration or setup of already rock-solid qmail?
    - briankwest 11y ago
      Since when has qmail been simple to setup? LOL
      - nickpsecurity 11y ago
        Let me repeat the question with highlighting on parts relevant to your reply. "Could people have just improved the configuration or setup of already rock-solid qmail?" improved the configuration or setup IMPROVED the CONFIGURATION or SETUP Do you have an answer to my question about refusal to improve an already secure and proven solution? Or do you have another strawman point ready?
    - jethro_tell 11y ago
      I suppose that could be done, but email itself is a very complicated thing to deal with with a lot of moving parts. OpenSMTP was supposed to have a much simpler scope of operation. Think of the configuration method as using duct tape to permanently set the switches/levers of an f1 race car instead of just getting an automatic Toyota car that is simpler for almost all people to drive. A lot of the security and simplicity is supposed to come from not having so many options/knobs/levers of operation.
      - nickpsecurity 11y ago
        Good points. I'd say in that case I'd try to draw on the code or architecture of qmail that was beneficial while ignoring anything unnecessary. Better than trying to get the hard stuff right twice.
        jethro_tell 11y ago
        I think that qmail's design is based off of being super modular. So much that most people don't actually run the qmail-smtpd because it had some security issues (It's been a while but this was around the time they started work on the OpenSMTPd). I assume 5 years later it's much improved but at the time forking the code of an SMTPd that had security vulnerabilities didn't seem like a worthwile investment and everything else has a OpenBSD prohibitive license. Edit: It was all pretty thoroughly discussed on various mailing lists and whatnot if you're curious
        nickpsecurity 11y ago
        Qmail's security advantage came from a number of design decisions detailed here and easy to copy in even clean-slate programs: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf Far as their decision, that makes sense. I still think they should've leveraged proven design principles or tactics in the other software. I've just seen enough of these situations where I believe what you say about how their evaluation and decision process went. I figured licensing would factor into it, too.
    - tedunangst 11y ago
      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 11y ago
        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 11y ago
        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.
  - xorcist 11y ago
    Both postfix and qmail have quite thorough privilege separation. Most people run Postfix out of the box (apt-get install, answer which domains you want to route mail for, done) and it's completely solid. Wietse Venema had a name for himself in security circles long before he started writing it. DJB too. Neither is likely to be the vulnerable link in your system.
  - ams6110 11y ago
    And "a lot simpler" meaning A LOT simpler. It is the first mail server that I as a non-professional sysadmin could understand and configure correctly the first time using just the man page.
- deleted 11y ago
  [deleted]
  - c22 11y ago
    I'm not sure OpenSMTPD is attempting to cover all use cases.
    - deleted 11y ago
      [deleted]
oal 11y ago
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!
- sandGorgon 11y ago
  what do you think about the Lamson[1]/Salmon[2] project (originally by Zed Shaw)? It seemed really cool but seemed to have fizzled out. [1] https://github.com/zedshaw/lamson https://github.com/zedshaw/lamson [2] https://github.com/moggers87/salmon https://github.com/moggers87/salmon
  - nickpsecurity 11y ago
    I like the concept and some attributes of it. Some good ideas might come out of those projects. The thing I can't overemphasize here, though, is that this kind of application might be attacked or just fail in many ways. So, whatever people do, they need to keep the main functionality simple for human and/or machine analysis. Python helps with readable logic but obscures how it's actually implemented (attacker's focus). A similar project in Go might be a better idea as it's easier to see what assembler comes out of it and Go is often the replacement for Python in server apps. Regardless, the main worry areas are parsing, protocol handling, formats, and limiting effects of any given external action on system's state. Making sure those are correct should knock out most issues. Not that it will be simple or easy. ;)
- nickpsecurity 11y ago
  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.
nickpsecurity 11y ago
"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 11y ago
  "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 11y ago
    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.
    - 11y ago
vbezhenar 11y ago
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.
- mhurron 11y ago
  "The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security. Of course security updates for various applications are committed to the ports tree as soon as possible, and corresponding package security updates are made available as snapshots for -current." http://www.openbsd.org/faq/faq15.html#Intro http://www.openbsd.org/faq/faq15.html#Intro
  - nickpsecurity 11y ago
    Exactly. You're safe so long as you don't run 3rd party apps. Past that, let's hope the exploit mitigation technology works. Least they have that tech, though.
- snksnk 11y ago
  For security updates, you could use the openup utility from M:Tier: https://stable.mtier.org/ https://stable.mtier.org/
- protomyth 11y ago
  OpenSMTPD and anything in base are patched and not part of the pkg system. See http://www.openbsd.org/stable.html http://www.openbsd.org/stable.html for 5.7 refer to http://www.openbsd.org/errata57.html http://www.openbsd.org/errata57.html for what has been patched If compiling it yourself is not an option, then refer to snksnk's comment and use https://stable.mtier.org https://stable.mtier.org
jerf 11y ago
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?
- vezzy-fnord 11y ago
  The only currently-extant memory-unsafe language. Some variants of Forth? OpenSMTPD actually dates back earlier to around 2009, when it was introduced in 4.6. Not that this is even notable, as virtually all major OpenBSD projects are C-based.
  - nickpsecurity 11y ago
    Yeah, there are other memory-unsafe languages. His overall point remains. Matter of fact, thanks to you, I can now drop bombs on concurrency angle thanks to Concurrent Pascal, Solo, etc. Relevant given all the C & BSD apps juggling threads. To think mainstream is just now solving these problems in past 3-5 years despite proven solutions available... (rolls eyes)
    - vezzy-fnord 11y ago
      I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory for concurrency was having architectures with thread-level parallelism instead of the dominant instruction-level parallelism, and one specifically optimized for CSP in the occam language. This was, of course, the transputer. So much for that. Erlang/OTP leads in the modern era. But I don't see any relation to our current topic of discussion.

66 points by zx2c4 11y ago

cenal 11y ago

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

zx2c4 11y ago
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 11y ago
  Could people have just improved the configuration or setup of already rock-solid qmail?
  - briankwest 11y ago
    Since when has qmail been simple to setup? LOL
    - nickpsecurity 11y ago
      Let me repeat the question with highlighting on parts relevant to your reply. "Could people have just improved the configuration or setup of already rock-solid qmail?" improved the configuration or setup IMPROVED the CONFIGURATION or SETUP Do you have an answer to my question about refusal to improve an already secure and proven solution? Or do you have another strawman point ready?
  - jethro_tell 11y ago
    I suppose that could be done, but email itself is a very complicated thing to deal with with a lot of moving parts. OpenSMTP was supposed to have a much simpler scope of operation. Think of the configuration method as using duct tape to permanently set the switches/levers of an f1 race car instead of just getting an automatic Toyota car that is simpler for almost all people to drive. A lot of the security and simplicity is supposed to come from not having so many options/knobs/levers of operation.
    - nickpsecurity 11y ago
      Good points. I'd say in that case I'd try to draw on the code or architecture of qmail that was beneficial while ignoring anything unnecessary. Better than trying to get the hard stuff right twice.
      - jethro_tell 11y ago
        I think that qmail's design is based off of being super modular. So much that most people don't actually run the qmail-smtpd because it had some security issues (It's been a while but this was around the time they started work on the OpenSMTPd). I assume 5 years later it's much improved but at the time forking the code of an SMTPd that had security vulnerabilities didn't seem like a worthwile investment and everything else has a OpenBSD prohibitive license. Edit: It was all pretty thoroughly discussed on various mailing lists and whatnot if you're curious
        nickpsecurity 11y ago
        Qmail's security advantage came from a number of design decisions detailed here and easy to copy in even clean-slate programs: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf Far as their decision, that makes sense. I still think they should've leveraged proven design principles or tactics in the other software. I've just seen enough of these situations where I believe what you say about how their evaluation and decision process went. I figured licensing would factor into it, too.
  - tedunangst 11y ago
    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 11y ago
      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 11y ago
        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.
- xorcist 11y ago
  Both postfix and qmail have quite thorough privilege separation. Most people run Postfix out of the box (apt-get install, answer which domains you want to route mail for, done) and it's completely solid. Wietse Venema had a name for himself in security circles long before he started writing it. DJB too. Neither is likely to be the vulnerable link in your system.
- ams6110 11y ago
  And "a lot simpler" meaning A LOT simpler. It is the first mail server that I as a non-professional sysadmin could understand and configure correctly the first time using just the man page.
deleted 11y ago
[deleted]
- c22 11y ago
  I'm not sure OpenSMTPD is attempting to cover all use cases.
  - deleted 11y ago
    [deleted]

oal 11y ago

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!

sandGorgon 11y ago
what do you think about the Lamson[1]/Salmon[2] project (originally by Zed Shaw)? It seemed really cool but seemed to have fizzled out. [1] https://github.com/zedshaw/lamson https://github.com/zedshaw/lamson [2] https://github.com/moggers87/salmon https://github.com/moggers87/salmon
- nickpsecurity 11y ago
  I like the concept and some attributes of it. Some good ideas might come out of those projects. The thing I can't overemphasize here, though, is that this kind of application might be attacked or just fail in many ways. So, whatever people do, they need to keep the main functionality simple for human and/or machine analysis. Python helps with readable logic but obscures how it's actually implemented (attacker's focus). A similar project in Go might be a better idea as it's easier to see what assembler comes out of it and Go is often the replacement for Python in server apps. Regardless, the main worry areas are parsing, protocol handling, formats, and limiting effects of any given external action on system's state. Making sure those are correct should knock out most issues. Not that it will be simple or easy. ;)
nickpsecurity 11y ago
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.

nickpsecurity 11y ago

"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 11y ago
"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 11y ago
  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.
  - 11y ago

vbezhenar 11y ago

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.

mhurron 11y ago
"The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security. Of course security updates for various applications are committed to the ports tree as soon as possible, and corresponding package security updates are made available as snapshots for -current." http://www.openbsd.org/faq/faq15.html#Intro http://www.openbsd.org/faq/faq15.html#Intro
- nickpsecurity 11y ago
  Exactly. You're safe so long as you don't run 3rd party apps. Past that, let's hope the exploit mitigation technology works. Least they have that tech, though.
snksnk 11y ago
For security updates, you could use the openup utility from M:Tier: https://stable.mtier.org/ https://stable.mtier.org/
protomyth 11y ago
OpenSMTPD and anything in base are patched and not part of the pkg system. See http://www.openbsd.org/stable.html http://www.openbsd.org/stable.html for 5.7 refer to http://www.openbsd.org/errata57.html http://www.openbsd.org/errata57.html for what has been patched If compiling it yourself is not an option, then refer to snksnk's comment and use https://stable.mtier.org https://stable.mtier.org

jerf 11y ago

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?

vezzy-fnord 11y ago
The only currently-extant memory-unsafe language. Some variants of Forth? OpenSMTPD actually dates back earlier to around 2009, when it was introduced in 4.6. Not that this is even notable, as virtually all major OpenBSD projects are C-based.
- nickpsecurity 11y ago
  Yeah, there are other memory-unsafe languages. His overall point remains. Matter of fact, thanks to you, I can now drop bombs on concurrency angle thanks to Concurrent Pascal, Solo, etc. Relevant given all the C & BSD apps juggling threads. To think mainstream is just now solving these problems in past 3-5 years despite proven solutions available... (rolls eyes)
  - vezzy-fnord 11y ago
    I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory for concurrency was having architectures with thread-level parallelism instead of the dominant instruction-level parallelism, and one specifically optimized for CSP in the occam language. This was, of course, the transputer. So much for that. Erlang/OTP leads in the modern era. But I don't see any relation to our current topic of discussion.