openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 06 Sep '17

06 Sep '17

On 09/06/2017 09:29 AM, Howard Chu wrote: > > Learn something about Unix, please. > > Use the ps command to verify that the process at least has the correct name. > The init script should know it's looking for a process named slapd, not init. > Supposing we want to copy/paste two or more "ps" calls into every slapd init script, this still lets a hacker prevent his own hacked process from being killed by writing junk into the file. If the standard practice was to write the PID file as an unprivileged user, we would need to not only copy/paste those "ps" calls into every slapd init script, but literally every init script for every daemon. Apparently my predecessors didn't want to do that, so the standard practice is to write the PID file as root. Do with that information what you will.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by hyc＠symas.com 06 Sep '17

06 Sep '17

michael(a)orlitzky.com wrote: > On 09/06/2017 08:29 AM, Howard Chu wrote: >>> 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate >>> the weird behavior resulting from the hack. >> >> Even if that were possible, it's clearly a bug in the init script, which >> failed to check that the process with that PID was the process it was >> expecting to find. Note that this is something any init script needs to do >> anyway, since PID files can go stale and some other process may be using the >> PID by the time you reference the file. > > Have you ever seen such an init script? > > How should the init system know what process it was expecting to find, > if not by reading that process's PID from the PID file? Learn something about Unix, please. Use the ps command to verify that the process at least has the correct name. The init script should know it's looking for a process named slapd, not init. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 06 Sep '17

06 Sep '17

On 09/06/2017 08:29 AM, Howard Chu wrote: > >> 4. Someone compromises the daemon, which sits on the open network. > > Nobody compromises slapd from the network. There are no buffer overflow > vulnerabilities, there are no RCE vulnerabilities. > Oh, it's one of /those/ daemons. >> >> 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate >> the weird behavior resulting from the hack. > > Even if that were possible, it's clearly a bug in the init script, which > failed to check that the process with that PID was the process it was > expecting to find. Note that this is something any init script needs to do > anyway, since PID files can go stale and some other process may be using the > PID by the time you reference the file. Have you ever seen such an init script? How should the init system know what process it was expecting to find, if not by reading that process's PID from the PID file? If you decide not to write the PID file as root, that's of course up to you, but I still have to tell something to the people who ship OpenLDAP as part of their distributions. I can tell them "Howard says it should be easy," but considering that no one has ever done it, that's not real helpful advice. There are only two requirements really: it needs to be portable POSIX sh, and the stop() function must only kill the one process created by start(). If you give that a shot, you might see why I suggested that this be fixed in slapd.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by hyc＠symas.com 06 Sep '17

06 Sep '17

michael(a)orlitzky.com wrote: > On 09/05/2017 05:38 PM, Ryan Tandy wrote: >> >> If you would like to propose a patch, we could review that. For myself I >> don't think I would attach a high priority to this. > > I understand that it's a low priority, I'm just trying to clean up the > hundred or so cases of this that we have in Gentoo. In a few, it's > impossible to do so because of the way the daemon creates the PID file > (like it is here), so I'm doing bugs/CVEs to keep track of them. This > way that distribution maintainers have something to watch and will know > when they can fix their init scripts. Your problem scenario is still unrealistic. > 4. Someone compromises the daemon, which sits on the open network. Nobody compromises slapd from the network. There are no buffer overflow vulnerabilities, there are no RCE vulnerabilities. > 5. The attacker is generally limited in what he can do because the > daemon doesn't run as root. However, he can write "1" into the > slapd.pid file, and he does. > > 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate > the weird behavior resulting from the hack. Even if that were possible, it's clearly a bug in the init script, which failed to check that the process with that PID was the process it was expecting to find. Note that this is something any init script needs to do anyway, since PID files can go stale and some other process may be using the PID by the time you reference the file. > 7. Oops, the machine reboots, because I killed PID 1. > Big deal, you caused a temporary service outage. No remote code was injected, no data was leaked, no actual lasting damage was done. I'm inclined to close this ticket. It presupposes a class of bug that doesn't exist in OpenLDAP code, and it relies on an additional bug in a script that isn't part of OpenLDAP code. At best, this ticket has been mis-filed and the submitter needs to submit it to somewhere relevant, like whoever authored the broken init script. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 06 Sep '17

06 Sep '17

On 09/05/2017 05:38 PM, Ryan Tandy wrote: > > If you would like to propose a patch, we could review that. For myself I > don't think I would attach a high priority to this. I understand that it's a low priority, I'm just trying to clean up the hundred or so cases of this that we have in Gentoo. In a few, it's impossible to do so because of the way the daemon creates the PID file (like it is here), so I'm doing bugs/CVEs to keep track of them. This way that distribution maintainers have something to watch and will know when they can fix their init scripts. > Howard pointed out on IRC that if the directory containing the pid file > is sticky, making it owned by root means slapd can no longer remove it > on exit. I'm not sure how common that is but it's a setup that works > right now. Typically the PID file would go directly in /run (or /var/run) and be owned by root. That means that you can't clean it up when the daemon exits, but no one expects a daemon to do that. Practically, the PID file exists solely for the benefit of init systems. Given the choice between, 1. How do I determine if I can trust the contents of this file owned by an untrusted user? 2. How do I remove the PID file after killing the daemon? the second is much easier to do. The first is next to impossible to get right; so if we have to pick one, that's the way to go IMO.

1 0

Re: (ITS#8714)
by michael＠stroeder.com 06 Sep '17

06 Sep '17

michael(a)stroeder.com wrote: > If you don't mind I just produce another follow-up patch for the > man-page. Find this man-page patch here: https://www.stroeder.com/temp/0001-ITS-8714-man-page-corrections-regarding-… Ciao, Michael.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by ryan＠openldap.org 05 Sep '17

05 Sep '17

On Fri, Jul 28, 2017 at 07:35:47PM +0000, michael(a)orlitzky.com wrote: >The slapd daemon should create its PID file before dropping privileges. This >represents a minor security issue; additional factors are needed to make it >exploitable. If I understood you correctly, "Additional factors are needed" basically means you have to find a code execution vulnerability in slapd? At that point I think you can do much more interesting things - pretending that your user is uid 0, or in various admin groups are only the first ideas that come to mind. If you would like to propose a patch, we could review that. For myself I don't think I would attach a high priority to this. Howard pointed out on IRC that if the directory containing the pid file is sticky, making it owned by root means slapd can no longer remove it on exit. I'm not sure how common that is but it's a setup that works right now.

1 0

Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com 05 Sep '17

05 Sep '17

This has been assigned CVE-2017-14159.

1 0

Re: (ITS#8714)
by michael＠stroeder.com 05 Sep '17

05 Sep '17

Howard Chu wrote: > You could add a LIMITATIONS section, as slapd-monitor.5 and > slapd-shell.5 does. The manpage now needs an update to note that > the exop value is base64 encoded. Also, since it is encoded, I > don't believe it's necessary to explicitly send the valuelen. Ah, yes. Forgot to update the message format in the man-page. If you don't mind I just produce another follow-up patch for the man-page. Ok? Ciao, Michael.

1 0

Re: (ITS#8714)
by hyc＠symas.com 05 Sep '17

05 Sep '17

Michael Str=C3=B6der wrote: > hyc(a)symas.com wrote: >> There's a weird indent at extended.c:50 or so, the if() >> statement. >> >> Would be better to use op->o_tmpalloc instead of ber_memalloc >> since you'r=3D e=3D20 immediately freeing the buffer again anyway. >> >> I can fix those here if you don't care. >=20 > Yes, I'd highly appreciate if you simply adjust it to your coding style= . >=20 > One additional point: > Currently the external program is not able to produce a custom extended= =20 > operation response. Mainly it should always return CONTINUE or an error= =20 > response. I wanted to make this limitation clear in the man-page but wa= s=20 > unsure about the appropriate section. You could add a LIMITATIONS section, as slapd-monitor.5 and slapd-shell.5= =20 does. The manpage now needs an update to note that the exop value is base= 64=20 encoded. Also, since it is encoded, I don't believe it's necessary to=20 explicitly send the valuelen. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs