Package: gnustep-base-runtime Version: 1.26.0-4 Severity: grave Tags: security Justification: user security hole
Dear Maintainer, I had "gnustep-base-runtime" installed on my system, probably as a dependency of "unar". When I upgrade from Debian 9 to Debian 10 (and reboot), there is a network server "gdomap". I did not see this server on Debian 9. "gdomap" is not wanted. It is supposed to be disabled by default since 2013, i.e. in Debian 8.[1] [1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773 The problem is due to this code change: "Disable gdomap via defaults-disabled as per Policy 9.3.3.1." https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f Salvatore Bonaccorso analyzed this for me: > Install a fresh stretch installation and install gnustep-base-runtime > in it. gdomap is not started by default, because gdomap init honours > the ENABLED=no setting in /etc/default/gdomap. Now update the host to > buster. > > During this update /etc/default/gdomap is updated according to the > above. Unless the admin has modified it, where then it will be > noticed and admin asked for a decision. As formerly the init was > enabled, and the code to handle the ENABLED setting is removed this > might be the problem. The postinst calls update-rc.d gdomap > defaults-disabled [...] "update-rc.d" does not do anything in this case. The man page says > If any files named /etc/rcrunlevel.d/[SK]??name already exist then > update-rc.d does nothing. The program was written this way so that > it will never change an existing configuration, which may have been > customized by the system administrator. The program will only > install links if none are present, i.e., if it appears that the > service has never been installed before. It is unfortunate that "Policy 9.3.3.1" does not have an explicit warning about this potential security problem. So this is a problem with upgrades. It does not happen on a fresh install of Debian 10. Salvatore also suggested > I think it's best handled though in a bugreport accordngly, and once > fixed in unstable, to schedule a fix as well via a buster point > release. $ sudo netstat -l -p Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... udp 0 0 0.0.0.0:gdomap 0.0.0.0:* 57/gdomap $ ps aux | grep gdomap nobody 57 0.0 0.0 2736 2052 ? Ss 11:16 0:00 /usr/bin/gdomap -I /var/run/gdomap.pid -p -j /var/run/gdomap $ dpkg-query -S gdomap gnustep-base-runtime: /usr/share/man/man8/gdomap.8.gz gnustep-base-runtime: /etc/default/gdomap gnustep-base-runtime: /usr/bin/gdomap gnustep-base-runtime: /etc/init.d/gdomap [Report sent from a systemd-nspawn container, which I used to reproduce the issue] -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.9-200.fc30.x86_64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnustep-base-runtime depends on: ii gnustep-base-common 1.26.0-4 ii init-system-helpers 1.56+nmu1 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnustep-base1.26 1.26.0-4 ii libobjc4 8.3.0-6 ii lsb-base 10.2019051400 gnustep-base-runtime recommends no packages. gnustep-base-runtime suggests no packages. -- no debconf information