Acknowledgement sent
to Vincent Lefevre <[email protected]>:
New Bug report received and forwarded. Copy sent to Arthur de Jong <[email protected]>.
(Mon, 21 Aug 2017 11:27:04 GMT) (full text, mbox, link).
Subject: nslcd: can be killed by the OOM Killer, DoS
Date: Mon, 21 Aug 2017 13:17:10 +0200
Package: nslcd
Version: 0.9.4-3+deb8u2
Severity: grave
Tags: jessie
Justification: causes non-serious data loss
and DoS from an end user.
It appears that nslcd can be killed by the OOM Killer when some user
process takes all the memory. In such a case, it is no longer possible
to connect to the machine by SSH. Thus this is DoS by an end user,
with possible data loss concerning what is running on the machine.
Shouldn't the patch be backported?
https://lists.arthurdejong.org/nss-pam-ldapd-users/2015/msg00036.html
(I know that there is a new Debian/stable version, but it is quite new,
so that there will be some time before the machines are upgraded to it.)
-- System Information:
Debian Release: 8.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nslcd depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.56+deb8u1
ii libc6 2.19-18+deb8u10
ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2
ii libldap-2.4-2 2.4.40+dfsg-1+deb8u3
Versions of packages nslcd recommends:
ii bind9-host [host] 1:9.9.5.dfsg-9+deb8u13
ii host 1:9.9.5.dfsg-9+deb8u13
ii ldap-utils 2.4.40+dfsg-1+deb8u3
ii libnss-ldapd [libnss-ldap] 0.9.4-3+deb8u2
ii libpam-ldapd [libpam-ldap] 0.9.4-3+deb8u2
ii nscd 2.19-18+deb8u10
ii nslcd-utils 0.9.4-3+deb8u2
Versions of packages nslcd suggests:
pn kstart <none>
-- debconf-show failed
Control: sevirity -1 normal
On Mon, 2017-08-21 at 13:17 +0200, Vincent Lefevre wrote:
> Severity: grave
> Justification: causes non-serious data loss and DoS from an end user.
The severity is a bit questionable and, at the very least not a flaw in
or unique to nslcd. Any local user that does not have resource limits
applied to them can DoS the whole system easily so I'm lowering the
severity to normal.
> It appears that nslcd can be killed by the OOM Killer when some user
> process takes all the memory. In such a case, it is no longer
> possible to connect to the machine by SSH. Thus this is DoS by an end
> user, with possible data loss concerning what is running on the
> machine.
The OOM is indeed a bit of Russian roulette on your system. You can
tune it a bit with vm.panic_on_oom and vm.overcommit_memory sysctls or
perform the following action that is equivalent to what newer nslcd
does:
echo -1000 > /proc/`cat /var/run/nslcd/nslcd.pid`/oom_score_adj
The patch should be pretty easy to backport though. I've put it on my
list but can't really guarantee a turn-around-time.
Thanks,
--
-- arthur - [email protected] - https://people.debian.org/~adejong --
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Mon, 21 Aug 2017 22:54:07 GMT) (full text, mbox, link).
Subject: Re: Bug#872798: nslcd: can be killed by the OOM Killer, DoS
Date: Tue, 22 Aug 2017 00:52:27 +0200
Control: severity -1 normal
(fixing the typo in the Control line)
On 2017-08-21 21:47:04 +0200, Arthur de Jong wrote:
> Control: sevirity -1 normal
>
> On Mon, 2017-08-21 at 13:17 +0200, Vincent Lefevre wrote:
> > Severity: grave
> > Justification: causes non-serious data loss and DoS from an end user.
>
> The severity is a bit questionable and, at the very least not a flaw in
> or unique to nslcd.
Perhaps not unique to nslcd, but the consequences are the worst when
nslcd is killed: one can no longer access to the machine.
> Any local user that does not have resource limits applied to them
> can DoS the whole system easily so I'm lowering the severity to
> normal.
Note that users here are not malicious (they would have serious
problems if they DoS the whole system on purpose). Memory can be
exhausted by mistake (e.g. due to bugs) or just because the users
try to push the limits to solve some problems, and for this reason,
there are no resource limits. Still, one expects that the system
reacts in a reasonable manner if possible, e.g. the whole machine
should not crash and should remain accessible.
> The OOM is indeed a bit of Russian roulette on your system. You can
> tune it a bit with vm.panic_on_oom and vm.overcommit_memory sysctls or
> perform the following action that is equivalent to what newer nslcd
> does:
>
> echo -1000 > /proc/`cat /var/run/nslcd/nslcd.pid`/oom_score_adj
I suppose that a workaround based on this in /etc/init.d/nslcd could
be after "start-stop-daemon --start ...":
status=$?
if [ $status -eq 0 ]; then
echo -1000 > /proc/`cat $NSLCD_PIDFILE`/oom_score_adj
fi
log_end_msg $status
;;
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Arthur de Jong <[email protected]>:
Extra info received and forwarded to list.
(Tue, 22 Aug 2017 18:54:03 GMT) (full text, mbox, link).
On Tue, 2017-08-22 at 00:52 +0200, Vincent Lefevre wrote:
> Control: severity -1 normal
>
> (fixing the typo in the Control line)
Thanks, I somehow never get these right ;)
> Perhaps not unique to nslcd, but the consequences are the worst when
> nslcd is killed: one can no longer access to the machine.
That is true. It is probably also true for systemd, udev and similar
processes but some of these also seem to tweak oom priority.
> I suppose that a workaround based on this in /etc/init.d/nslcd could
> be after "start-stop-daemon --start ...":
>
> status=$?
> if [ $status -eq 0 ]; then
> echo -1000 > /proc/`cat $NSLCD_PIDFILE`/oom_score_adj
> fi
> log_end_msg $status
> ;;
That should be a workaround for now.
Thanks,
--
-- arthur - [email protected] - https://people.debian.org/~adejong --
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Tue, 22 Aug 2017 21:21:02 GMT) (full text, mbox, link).
Subject: Re: Bug#872798: nslcd: can be killed by the OOM Killer, DoS
Date: Tue, 22 Aug 2017 23:17:59 +0200
On 2017-08-22 20:51:10 +0200, Arthur de Jong wrote:
> On Tue, 2017-08-22 at 00:52 +0200, Vincent Lefevre wrote:
> > Perhaps not unique to nslcd, but the consequences are the worst when
> > nslcd is killed: one can no longer access to the machine.
>
> That is true. It is probably also true for systemd, udev and similar
> processes but some of these also seem to tweak oom priority.
Note that contrary to nslcd, these processes run as root, so that
even if they do nothing special, they are less likely to be killed.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.