OpenBSD Mail Server Bug Allowed Remotely Executing Shell Commands As Root (zdnet.com) 39
This week a remotely-exploitable vulnerability (granting root privileges) was discovered in OpenSMTPD (OpenBSD's implementation of server-side SMTP).
ZDNet notes that the library's "portable" version "has also been incorporated into other OSes, such as FreeBSD, NetBSD, and some Linux distros, such as Debian, Fedora, Alpine Linux, and more." To exploit this issue, an attacker must craft and send malformed SMTP messages to a vulnerable server... OpenSMTPD developers have confirmed the vulnerability and released a patch earlier Wednesday -- OpenSMTPD version 6.6.2p1...
The good news is that the bug was introduced in the OpenSMTPD code in May 2018 and that many distros may still use older library versions, not affected by this issue. For example, only in-dev Debian releases are affected by this issue, but not Debian stable branches, which ship with older OpenSMTPD versions.
Technical details and proof of concept exploit code are available in the Qualys CVE-2020-7247 security advisory.
Hackaday has a more detailed description of the vulnerability, while the Register looks at the buggy C code.
Interestingly, Qualys researchers exploited this vulnerability using a technique from the Morris Worm of 1988.
ZDNet notes that the library's "portable" version "has also been incorporated into other OSes, such as FreeBSD, NetBSD, and some Linux distros, such as Debian, Fedora, Alpine Linux, and more." To exploit this issue, an attacker must craft and send malformed SMTP messages to a vulnerable server... OpenSMTPD developers have confirmed the vulnerability and released a patch earlier Wednesday -- OpenSMTPD version 6.6.2p1...
The good news is that the bug was introduced in the OpenSMTPD code in May 2018 and that many distros may still use older library versions, not affected by this issue. For example, only in-dev Debian releases are affected by this issue, but not Debian stable branches, which ship with older OpenSMTPD versions.
Technical details and proof of concept exploit code are available in the Qualys CVE-2020-7247 security advisory.
Hackaday has a more detailed description of the vulnerability, while the Register looks at the buggy C code.
Interestingly, Qualys researchers exploited this vulnerability using a technique from the Morris Worm of 1988.
the return of sendmail bugs? (Score:2)
Why is it so hard to get email handling right?
Re: the return of sendmail bugs? (Score:2)
Because despite appearances its bloody complex to write and update a public facing multitasking network server that acts as both server and client and has to do some serious parsing of input along with built in database handling to boot and maintain a high level of security. All in the fractions of a second expected for corporate email response times. You might as well ask why there aren't any bug free web servers, it's the same level of complexity.
Cute bug. (Score:3)
Weren't we just talking about the difference between great and other programmers a moment ago?
OpenBSD Mail Server (Score:1)
Thank god I run Postfix (Score:4, Insightful)
While any program can have nasty bugs crop up in it, I don't recall Postfix having any holes this nasty since I started running it 10 years ago.
Postfix also runs as a none privileged account. I'm surprised the OpenBSD guys didn't write their SMTP server to do the same....
everything has issues Postfix is not immune... (Score:3)
Postfix before 2.11.10, 3.0.x before 3.0.10, 3.1.x before 3.1.6, and 3.2.x before 3.2.2 might allow local users to gain privileges by leveraging undocumented functionality in Berkeley DB 2.x and later, related to reading settings from DB_CONFIG in the current directory.
Publish Date : 2018-04-16
pay more attention
Re: (Score:2)
Yes, a local privilege escalation is equivalent to an RCE. /s
Pay more attention? How about "know what you're talking about before opening your mouth"?
Re: (Score:1)
> Postfix also runs as a none privileged account.
You can't bind with unprivileged account to SMTP port.
Re: (Score:3)
That is why I've been proposing for decades that the rules for ports under 1000 allow the port matching the group ids to open ports. That way named runs in group 53, apache in groups 80 and 443 and smtp runs in 25 and other groups.
Re: (Score:2)
That is why I've been proposing for decades that the rules for ports under 1000 allow the port matching the group ids to open ports. That way named runs in group 53, apache in groups 80 and 443 and smtp runs in 25 and other groups.
That's actually a really interesting idea.
It may not be the best to map directly to a group ID, since the GID ranges have a long history of how they are allocated, but that's nothing but an implementation detail.
Debian for example (the one I'm most familiar with) reserves GID 0-99 for static pre-allocated groups that need to be the same on all Debian installations.
3-digit GIDs are system groups but dynamic, and are chosen when you use adduser --system
Then 1000 up to I think 65000 are to match a UID and give
Re: Thank god I run Postfix (Score:2)
Why bother? Under Linux:
setcap 'cap_net_bind_service=+ep' /path/to/bin/program
Re: (Score:3)
Re: (Score:1)
You can't bind with unprivileged account to SMTP port.
Nor do you need to, you simply need connections to the SMTP port to get to your unprivileged processes listening socket.
iptables -t nat -A PREROUTING -p tcp --dport 25 -j REDIRECT --to 2025
root can apply that rule to satisfy permission/policy, and your MTA binds to port 2025 under its own account.
Re: (Score:2)
Re: (Score:2)
Most of it runs non-privileged - root needs to bind to port 25.
But it's properly segmented so it's not a huge attack surface. That design is more than 20 years old so it's not like nobody had time to do it right. I switched to postfix in 2002 and it was difficult to set it up securely with TLS, but today there are enough guides. Distro defaults are often dumb, though, so don't get too cocky. Today i just say class { 'postfix' : } and let software get the configuration right.
Update OpenBSD Wikipedia Page? (Score:3)
Because OpenSMTPD is installed by default on OpenBSD, I wonder if it's time to update the Wikipedia page:
The quote remained unchanged as time passed, until on March 13, 2007 when Alfredo Ortega of Core Security Technologies[42] disclosed a network-related remote vulnerability.[43] The quote was subsequently changed to:
“ Only two remote holes in the default install, in a heck of a long time! ”
This statement has been criticized because the default install contains few running services, and many use cases require additional services.[44] Also, because the ports tree contains unaudited third-party software, it is easy for users to compromise security by installing or improperly configuring packages. However, the project maintains that the slogan is intended to refer to a default install and that it is correct by that measure.
https://en.wikipedia.org/wiki/OpenBSD#Security_record
Re: (Score:1)
Re: (Score:1)
My understanding is in the default install configuration, it is a local exploit (only).
So I think that statement still stands
Re: (Score:2)
Of course, it's nowadays a rather useless brag nowadays.
Over 15 years ago, sure they could brag compared to the general attitude assumed by Windows and Linux behaviors of the time, but a modern install of any popular OS is going to be more restricted.
They deserve credit for being mindful of network security when everyone else was sloppy. They deserve credit for some of their security discipline in big parts of their project.
However bragging about no remote exploits in default configuration is just table st
Why is it using a shell? (Score:2)
Why would security sensitive software ever use a shell to execute commands? It should just be exec()ing the delivery agent directly. That way no parsing of shell meta characters happens and bugs if this type are impossible.
Re: (Score:1)
When performance is not essential piping things through shell is the Unix way and OpenBSD is decidedly Unix. OpenBSD is about trying to create the ultimate bandaids for a gaping wound, not curing it.
Otherwise they would have been working on some Java operating system or something.
Re: (Score:3)
I'd like to crank that up a notch: Why would any software ever use a shell to execute commands?
Re: (Score:2)
Perhaps because writing some task in a programming language like Java or a powerful scripting Perl is more of a burden than the programmer needs to take on? SysV init scripts, which many people use over systemd for cross-compatibility, are shell scripts. The tomcat "start" and "stop" tools are shell scripts. So are many "cron" jobs that do daily tasks or run system backups.
Perhaps we should reverse the question. Why would any program use a system provided binary without using a "shell"? There are security r
Re:Why is it using a shell? (Score:4, Interesting)
You're missing the point. The question is: When implementing program A that needs to invoke program B, why would you use something like bash as an intermediary instead of running B directly?
The merits of bash as a programming language is a separate issue.
Why would any program use a system provided binary without using a "shell"?
I don't understand the question. If you want to run /bin/ls, then run /bin/ls already, what's the point of 'bash -c ls' other than introducing bugs?
Re: (Score:2)
So I personally gravitate to directly running the commands, but the challenge in most cases is that the mechanisms to do that correctly are tedious. It's very much worth it for me as so many things get easier (e.g. if involving a user parameter, I don't have to worry about quoting or escaping it). The tedium is also a nice way to dissuade fork/exec model which frequently slows things down compared to doing things built in. My order of specific recommendations are 'are you sure you need to run a command i
Re: (Score:1)
> Why would any software ever use a shell to execute commands?
Because if you would like to use such niceties as output redirection, wildcard expansion, variable expansion, command expansion, etc. then the alternative is to reimplement the shell yourself.
Re: Escaping strings is the devil's playground (Score:1)
Would you like to swap config.sys and autoexec.bat files? Mine are highly customized!
Re: (Score:1)
config.sys and autoexec.bat files? Mine are highly customized!
Linux really took off because lots of "nerds" discovered that was not all of "IT". Noobies tore their hair out because a current directory was hidden somewhere under an su to root. But it was so much fun.
Re: (Score:2)
I'm pretty sure the industry as a whole went all in with string escaping, not just bourne shell.
dos/cmd/powershell scripts are also bad. But the relatively poor command ecosystem has prevented them from being used much under the covers of applications.
The most damaging culprit has been SQL.
Re: (Score:2)
SQL ... the only thing which can compete with C for exploits caused.
What annoys me worse than everyone doing it wrong in the past is how long we persist with that nonsense. HTML? Sure, lets do it again. XML? Sure, lets do it again. All so a fucking half century old version of a plain text editor can still edit things.
Fundamental problem: stop running shell (Score:5, Informative)
The Register article says that the problem is the validation code, but that is only part of it. Programmers should always assume the validation/escaping code has errors. Escaping is rarely a good solution.
The fundamental issue is that software should not call shell commands [cmu.edu]. Instead of calling system, they should be using execve which fundamentally doesn't have this problem. No escaping is needed!
In this example, instead of the server accidentally running:
/usr/libexec/mail.local -f ;rm -rf /*;
it would have run:
/usr/libexec/mail.local with arguments -f ;rm -rf /*;
which would not have resulted in the vulnerability.
Re: (Score:2)
If at all possible, this guidance should be heeded.
However, if you *are* intent on being lazy, at least look into alternative ways to handle your string. In python, you *can* request that the string be run through shell, but you *can* use shlex.split() instead to help construct your argv.
Yes, mail.local still has the wrong arguments and you could add more arguments that you may not want the command to take and also you'll have bugs where bad input leads to things not working, even if not malicious. This i
smrsh (Score:2)
Re: (Score:1)
The irony is that you can have both; you can both use a shell (with pipes, redirections, etc) AND you can pass it the raw arguments without having to escape and interpolate anything. Just as with prepared SQL queries. And you can do that since 45 years ago:
... | ...", "sh", arg1, arg2, (void*)0);
execl("/bin/sh", "sh", "-c", "command \"$@\" |
You can put whatever nasty characters you like in "file1" or "file2", it DOES NOT MATTER.
The fact that people build up command strings by hand that they then pass to "s
Berkeley? Really? (Score:1)
Morris Worm (Score:1)
> Interestingly, Qualys researchers exploited this vulnerability using a technique from the Morris Worm of 1988.
Shit happens when people write the code just cause other free stuff is not free enough for BSD.