Back in the old days we had near weekly RCEs in sendmail and exim and these days it’s OpenSMTPD with strong ties to the f’ing OpenBSD project. That’s the one project I expect an RCE the least from; much less two in as many months.
It’s actually 3 — this one has two separate CVE’s in a single release, including a full local escalation to root on Fedora due to Fedora-specific bugs adding an extra twist (CVE-2020-8793).
The other bug here (CVE-2020-8794) is a remote one in the default install; although the local user still has to initiate an action to trigger an outgoing connection to an external mail server of the attacker, so, I guess OpenBSD might not count it towards the remote-default count of just two bugs since years ago.
I guess OpenBSD might not count it towards the remote-default count of just two bugs since years ago.
I feel like that would be disingenuous. I realize it’s not enabled by default in a way that’s exploitable but in the default install there’s literally nothing running that’s even listening really (you can enable OpenSSH in a default install, I suppose); this is of course the correct way to configure things by default. However, the statement degenerates to “no remotely exploitable bugs in our TCP/IP stack and OpenSSH”…which is awesome, but…
(Also, it’s easy to criticize: I’ve never written enterprise grade software used by millions.)
Can you explain more about why you think that’s disingenuous? OpenBSD making this claim doesn’t seem different to me than folks saying that this new bug is remotely exploitable. It’s very specific and if something doesn’t meet the specific criteria then it doesn’t apply. Does that make sense?
It is my opinion that the statement should be removed – not because it’s not accurate but because I just think it’s tacky.
IMHO it’s disingenuous because it implies that there are only two remote holes in a heck of a long time on a working server. It’s like saying “this car has a 100% safety record in its default state,” that is, turned off.
(I’m reminded of Microsoft bragging about Windows NT’s C2 security rating, while neglecting to mention that it got that rating only on a system that didn’t have a network card installed and its floppy drive glued shut.)
I’m not sure if they include OpenSSH in their “default state” (I think it is enabled by default), but other than OpenSSH there’s nothing else running that’s remotely reachable. Most people want to use OpenBSD for things other than just an OpenSSH server (databases, mail servers, web servers, etc), and they might get an inflated sense of security from statements like that
(Note that OpenBSD is remarkably secure and their httpd and other projects are excellent and more secure than most alternatives, but that’s not quite the point. Again, it’s easy for me to criticize, sitting here having not written software that has been used by millions.)
I appreciate you taking the time to elaborate. I think the claim is tacky as it seems to be more provocative than anything else – whether true or not. I don’t think it’s needed because I think what OpenBSD stands for speaks for itself. I think I understand why the claim was used in the past but this conversation about it comes up every time there’s a bug – whether remote or not. The whole thing is played out.
AFAIK OpenSMTPD is enabled by default, but does local mail delivery only with the default config. This makes the claim about “only 2 remote holes” still stand still, though I agree with your analysis of bullshit-o-meter of this slogan. But hey, company slogans are usually even more bullshit-ridden, so I don’t care.
One of the exploitation paths is parsing responses from remote SMTP servers, so you need to request that OpenSMTP connect out to an attacker-controlled server (e.g. by sending email).
It looks like on some older versions there’s a remote root without local user action needed…
I reckon I’ll go back and read the details again. However, if something requires that a local user do a very specific thing under very specific circumstances (attacker controlled server, etc.) in order to exploit – that does not jive with my definition of remote.
Mail is hard that way in that the daemon needs to listen to privileged ports and the delivery agent needs to write into directories only readable and writable by a specific user.
Both of these parts require root rights.
So your step zero is impossible to accomplish for an MTA. You can use multiple different processes and only run some privileged, but you cannot get away with running none of them as root if you want to work within the framework of traditional Unix mail.
Using port redirection and virtual users exposing just IMAP you can work around those issues, but them you’re leaving the traditional Unix setup and you’re adding more moving parts to the mix (like a separate imap daemon) which might or might not bring additional security concerns
yes. or you redirect the port. but that still leaves mail delivery.
As I said in my original comment: email is hard and that’s ok. I take issue with people reducing these vulnerabilities (or any issue they don’t fully understand) to “just do X - it’s so easy” (which is a strong pointer they don’t understand the issue)
Which is why I sit in my rant about still using C for (relatively) new projects when safer languages exist, though - oh boy is it tempting to be dropping a quick “buffer overflows are entirely preventable in as-performant but more modern languages like rust. why did you have to write OpenSMPTD in C”, but I’m sure there were good reasons - especially for people as experienced and security focused as the OpenBSD folks.
It’s hard if you impose the constraint that you need to support the classical UNIX model of email that was prevalent from the late 70s to the mid 90s. I was once very attached to this model but it’s based on UNIX file-system permissions that are hard to reason about and implement safely and successfully. The OpenSMTPD developers didn’t make these mistakes because they’re stupid, it’s really really hard. But it’s an unfortunate choice for a security focused system to chose to implement a hard model for email rather than making POP/IMAP work well, or some other approach to getting email under the control of a the recipient without requiring priviledges.
Not sure any of these are true, but more of a self-imposed traditional limitation.
Lower ports being bindable by root only could easily be removed; given linux has better security mechanisms to restrict lower port binding, like selinux, I’m not even sure why the kernel still imposes this moronic concept on people.
Mail delivery (maildir, mbox, whatever zany construct) can also be done giving limited rw access to the specific user and the MDA. hell, MAIL on my system just points to /var/spool/mail which is owned by root anyhow.
Thank you @fro. When I first saw your request (prior to your adding a link to the story to merge in to) I thought the story you were asking to merge referred to CVE-2020-7247 / OpenSMTPD 6.6.2p1, which has fallen outside the merge window. I quickly realized you meant story ti21d7 / OpenSMTPD 6.6.4p1, and they are now merged.
I mean, I assume that about everything. From the machines that make my shoes to the laptop I’m typing on now. ;-P
Vein attempts at comedy aside, I really do think it’s safe to assume there’s many vulnerabilities in all complex systems (I would classify MTAs as complex). And if there truly is no vulnerability in <insert doohickey here>, there’s likely a vulnerability in <this other doohickey> deployed on the same server.
I’m a pessimistic realist who realizes we’re all human and prone to mistakes.
Well this is one that’s getting some attention right now :)
What’s most disappointing is that OpenSMTPD doesn’t seem to do much in the way of privilege separation. There’s no reason for the MTA to be running as root or having world writable directories or any of that mess unless you’re trying to preserve the 90s UNIX desktop experience of your mbox in /var/spool/mail and procmail “cleverness”. I’m sure there’s an audience for that by why is that in OpenBSD’s default MTA?
Are they running fingerd and ytalk too? If we’re going for the retro experience over security let’s just use telnet! :)
Anyone actually uses it outside of OpenBSD? I’d imagine noone really does, so, not that many people would be looking for these; OTOH, finding a bug in OpenBSD software always adds extra points to the rep, doesn’t it? (I guess it might not anymore if these reports are to continue.)
On Linux, and on a forum there was a thread recently, and many reported in as moving to OpenSMTPD or have already moved to it from exim/postfix, as they found it easy to work with, and the security responses are impressively quick.
I guess there will be quite some secholes uncovered as nowadays OpenBSD and its sibling projects are getting more attention from security people (probably because they are an easy win as not utilizing as many mitigations/defense-in-depth methods used by other operating systems, and has having been neglected for their relatively small user base).
I’m also using it on a few machines, though only for mail forwarding (Linux and OpenBSD), but I plan to set up a complete mail infra based on it in the near future, to evaluate a complex setup.
I’m just a couple weeks away from deploying an OpenSMTPD installation for HardenedBSD’s build infrastructure. It’ll be an internal-only deployment, though, just to pass emails between systems to a centralized internal mbox.
I did use it for a while, but not on my main mail server. It was nice to work with, but I didn’t look at the code and I’m not really able to audit any c code, really.
Thank you @fro. I have merged story nxn7jz in to story ti21d7.
Your request to merge is correct. The article, despite being the same CVE, is a substantive update, adding three sections that can now be published. It’s appropriate that story nxn7jz was submitted [for merge]–it’s routine for credit, acknowledgments, exploits, or more detailed data to be published in this fashion as part of the responsible disclosure process.
Securing MTA must be a cursed job.
Back in the old days we had near weekly RCEs in sendmail and exim and these days it’s OpenSMTPD with strong ties to the f’ing OpenBSD project. That’s the one project I expect an RCE the least from; much less two in as many months.
Email is hard.
It’s actually 3 — this one has two separate CVE’s in a single release, including a full local escalation to root on Fedora due to Fedora-specific bugs adding an extra twist (CVE-2020-8793).
The other bug here (CVE-2020-8794) is a remote one in the default install; although the local user still has to initiate an action to trigger an outgoing connection to an external mail server of the attacker, so, I guess OpenBSD might not count it towards the remote-default count of just two bugs since years ago.
I feel like that would be disingenuous. I realize it’s not enabled by default in a way that’s exploitable but in the default install there’s literally nothing running that’s even listening really (you can enable OpenSSH in a default install, I suppose); this is of course the correct way to configure things by default. However, the statement degenerates to “no remotely exploitable bugs in our TCP/IP stack and OpenSSH”…which is awesome, but…
(Also, it’s easy to criticize: I’ve never written enterprise grade software used by millions.)
Can you explain more about why you think that’s disingenuous? OpenBSD making this claim doesn’t seem different to me than folks saying that this new bug is remotely exploitable. It’s very specific and if something doesn’t meet the specific criteria then it doesn’t apply. Does that make sense?
It is my opinion that the statement should be removed – not because it’s not accurate but because I just think it’s tacky.
IMHO it’s disingenuous because it implies that there are only two remote holes in a heck of a long time on a working server. It’s like saying “this car has a 100% safety record in its default state,” that is, turned off.
(I’m reminded of Microsoft bragging about Windows NT’s C2 security rating, while neglecting to mention that it got that rating only on a system that didn’t have a network card installed and its floppy drive glued shut.)
I’m not sure if they include OpenSSH in their “default state” (I think it is enabled by default), but other than OpenSSH there’s nothing else running that’s remotely reachable. Most people want to use OpenBSD for things other than just an OpenSSH server (databases, mail servers, web servers, etc), and they might get an inflated sense of security from statements like that
(Note that OpenBSD is remarkably secure and their httpd and other projects are excellent and more secure than most alternatives, but that’s not quite the point. Again, it’s easy for me to criticize, sitting here having not written software that has been used by millions.)
I appreciate you taking the time to elaborate. I think the claim is tacky as it seems to be more provocative than anything else – whether true or not. I don’t think it’s needed because I think what OpenBSD stands for speaks for itself. I think I understand why the claim was used in the past but this conversation about it comes up every time there’s a bug – whether remote or not. The whole thing is played out.
AFAIK OpenSMTPD is enabled by default, but does local mail delivery only with the default config. This makes the claim about “only 2 remote holes” still stand still, though I agree with your analysis of bullshit-o-meter of this slogan. But hey, company slogans are usually even more bullshit-ridden, so I don’t care.
You’re saying a local user has to do something to make it remote? Can you explain how that makes it remote?
One of the exploitation paths is parsing responses from remote SMTP servers, so you need to request that OpenSMTP connect out to an attacker-controlled server (e.g. by sending email).
It looks like on some older versions there’s a remote root without local user action needed…
I reckon I’ll go back and read the details again. However, if something requires that a local user do a very specific thing under very specific circumstances (attacker controlled server, etc.) in order to exploit – that does not jive with my definition of remote.
Apparently you can remotely exploit the server by triggering a bounce message.
Step zero is don’t run as root and don’t have world writable directories.
.
.
.
Sorry, was I yelling?
Mail is hard that way in that the daemon needs to listen to privileged ports and the delivery agent needs to write into directories only readable and writable by a specific user.
Both of these parts require root rights.
So your step zero is impossible to accomplish for an MTA. You can use multiple different processes and only run some privileged, but you cannot get away with running none of them as root if you want to work within the framework of traditional Unix mail.
Using port redirection and virtual users exposing just IMAP you can work around those issues, but them you’re leaving the traditional Unix setup and you’re adding more moving parts to the mix (like a separate imap daemon) which might or might not bring additional security concerns
At least on Linux there’s a capability for binding into privileged ports that is (the cap) not equivalent to root.
yes. or you redirect the port. but that still leaves mail delivery.
As I said in my original comment: email is hard and that’s ok. I take issue with people reducing these vulnerabilities (or any issue they don’t fully understand) to “just do X - it’s so easy” (which is a strong pointer they don’t understand the issue)
Which is why I sit in my rant about still using C for (relatively) new projects when safer languages exist, though - oh boy is it tempting to be dropping a quick “buffer overflows are entirely preventable in as-performant but more modern languages like rust. why did you have to write OpenSMPTD in C”, but I’m sure there were good reasons - especially for people as experienced and security focused as the OpenBSD folks.
It’s hard if you impose the constraint that you need to support the classical UNIX model of email that was prevalent from the late 70s to the mid 90s. I was once very attached to this model but it’s based on UNIX file-system permissions that are hard to reason about and implement safely and successfully. The OpenSMTPD developers didn’t make these mistakes because they’re stupid, it’s really really hard. But it’s an unfortunate choice for a security focused system to chose to implement a hard model for email rather than making POP/IMAP work well, or some other approach to getting email under the control of a the recipient without requiring priviledges.
Not sure any of these are true, but more of a self-imposed traditional limitation.
Lower ports being bindable by root only could easily be removed; given linux has better security mechanisms to restrict lower port binding, like selinux, I’m not even sure why the kernel still imposes this moronic concept on people. Mail delivery (maildir, mbox, whatever zany construct) can also be done giving limited rw access to the specific user and the MDA. hell, MAIL on my system just points to /var/spool/mail which is owned by root anyhow.
selinux isn’t everywhere.
The disclosure from Qualys: https://www.openwall.com/lists/oss-security/2020/02/24/4
edit[0]: A second disclosure from Qualys: https://www.openwall.com/lists/oss-security/2020/02/24/5
@alynpost can you merge this into the one already posted?
here: https://lobste.rs/s/ti21d7/opensmtpd_6_6_4p1_released_addressing
Thank you @fro. When I first saw your request (prior to your adding a link to the story to merge in to) I thought the story you were asking to merge referred to CVE-2020-7247 / OpenSMTPD 6.6.2p1, which has fallen outside the merge window. I quickly realized you meant story ti21d7 / OpenSMTPD 6.6.4p1, and they are now merged.
Yeah I was a bit late on the link. Thanks!
So at this point we assume that there are more nasty bugs in OpenSMTPD and that people wearing various colours of hat are looking for them.
I mean, I assume that about everything. From the machines that make my shoes to the laptop I’m typing on now. ;-P
Vein attempts at comedy aside, I really do think it’s safe to assume there’s many vulnerabilities in all complex systems (I would classify MTAs as complex). And if there truly is no vulnerability in
<insert doohickey here>, there’s likely a vulnerability in<this other doohickey>deployed on the same server.I’m a pessimistic realist who realizes we’re all human and prone to mistakes.
Well this is one that’s getting some attention right now :)
What’s most disappointing is that OpenSMTPD doesn’t seem to do much in the way of privilege separation. There’s no reason for the MTA to be running as root or having world writable directories or any of that mess unless you’re trying to preserve the 90s UNIX desktop experience of your mbox in /var/spool/mail and procmail “cleverness”. I’m sure there’s an audience for that by why is that in OpenBSD’s default MTA?
Are they running fingerd and ytalk too? If we’re going for the retro experience over security let’s just use telnet! :)
It is privsep’d to some degree:
I’m not familiar enough with OpenSMTPD to tell you why this specific code isn’t in one of the privsep’d parts.
Anyone actually uses it outside of OpenBSD? I’d imagine noone really does, so, not that many people would be looking for these; OTOH, finding a bug in OpenBSD software always adds extra points to the rep, doesn’t it? (I guess it might not anymore if these reports are to continue.)
On Linux, and on a forum there was a thread recently, and many reported in as moving to OpenSMTPD or have already moved to it from exim/postfix, as they found it easy to work with, and the security responses are impressively quick.
I guess there will be quite some secholes uncovered as nowadays OpenBSD and its sibling projects are getting more attention from security people (probably because they are an easy win as not utilizing as many mitigations/defense-in-depth methods used by other operating systems, and has having been neglected for their relatively small user base).
I’m also using it on a few machines, though only for mail forwarding (Linux and OpenBSD), but I plan to set up a complete mail infra based on it in the near future, to evaluate a complex setup.
It’s available on pretty much all Linux distros as a package, so I’d say yes. I’ve been using it for years myself on FreeBSD and Linux.
Yes, on Linux.
I’m just a couple weeks away from deploying an OpenSMTPD installation for HardenedBSD’s build infrastructure. It’ll be an internal-only deployment, though, just to pass emails between systems to a centralized internal mbox.
I did use it for a while, but not on my main mail server. It was nice to work with, but I didn’t look at the code and I’m not really able to audit any c code, really.
really with this?
@alynpost can we merge this with https://lobste.rs/s/ti21d7/opensmtpd_6_6_4p1_released_addressing ?
You can correct me if this shouldn’t be merged but I don’t see the point in a new post for this.
Thank you @fro. I have merged story nxn7jz in to story ti21d7.
Your request to merge is correct. The article, despite being the same CVE, is a substantive update, adding three sections that can now be published. It’s appropriate that story nxn7jz was submitted [for merge]–it’s routine for credit, acknowledgments, exploits, or more detailed data to be published in this fashion as part of the responsible disclosure process.