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
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 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
The trick here is either to use the IP stack to redirect privileged ports to known non-privileged ports, or, more commonly, to set up the listeners on the ports while root but then immediately change the UID and GID of the process to something with few or no rights.
Additionally, you can also chroot the process, something the OpenBSD team has experience of as that's one way they helped secure BIND IIRC. This makes it impossible to run shells because there's no/bin/sh in the filesystem available to the pr
OpenSMTPd's subtasks also drop their privileges. Part of the application must remain running under root, but this exploit isn't a privilege escalation or "running as root" problem.
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.
When you make your mark in the world, watch out for guys with erasers.
-- The Wall Street Journal
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)
The trick here is either to use the IP stack to redirect privileged ports to known non-privileged ports, or, more commonly, to set up the listeners on the ports while root but then immediately change the UID and GID of the process to something with few or no rights.
Additionally, you can also chroot the process, something the OpenBSD team has experience of as that's one way they helped secure BIND IIRC. This makes it impossible to run shells because there's no /bin/sh in the filesystem available to the pr
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.