Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Arthur de Jong]

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 - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Arthur de Jong]

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 - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Vincent Lefevre]

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  adduser3.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  host1: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  nscd2.19-18+deb8u10
ii  nslcd-utils 0.9.4-3+deb8u2

Versions of packages nslcd suggests:
pn  kstart  

-- debconf-show failed