From: Michael.Paoli@berkeley.edu   
      
   Source: uwsgi   
   Version: 2.0.21-5.1   
   Severity: normal   
   Tags: security upstream   
   X-Debbugs-Cc: Michael.Paoli@berkeley.edu, Debian Security Team <   
   eam@security.debian.org>   
      
   Dear Debian Security Team / Maintainer,   
   Security: likely local only, world writeable PID file,   
   umask(0), possibly (unknown?) additional issues?   
   Probably (quite?) minor security issue, also   
   (unconfirmed) issue may be masked by those using systemd.   
   Likely issue from upstream (not confirmed),   
   Likely from at least Version: 2.0.21-5.1 through   
   most current Debian Version (2.0.31) as this is being   
   submitted.   
   Would appear to come from, e.g.:   
   uwsgi-2.0.21/core/utils.c:162:          umask(0);   
   uwsgi-2.0.28/core/utils.c:162:          umask(0);   
   uwsgi-2.0.31/core/utils.c:162:          umask(0);   
   Further details (including (partial?) work-arounds) below:   
      
   Dear Maintainer,   
      
   What led up to the situation?   
      
   Encountered, e.g. (may be reformatted a bit):   
   # /etc/init.d/mailman3-web stop   
   Stopping Mailman3-web uWSGI service:   
   mailman3-webstart-stop-daemon: matching on world-writable   
   pidfile /run/mailman3-web/mailman3-web.pid is insecure   
    failed!   
   #   
      
   Analyzed and tracked issue back (strace, etc.):   
   $ stat -c '%a %u %g %F %n' \   
   > /run/mailman3-web/mailman3-web.pid   
   666 0 0 regular file /run/mailman3-web/mailman3-web.pid   
   $   
   /etc/init.d/mailman3-web -->   
   start-stop-daemon -->   
   /usr/bin/uwsgi_python3 --ini /etc/mailman3/uwsgi.ini \   
   --pidfile /run/mailman3-web/mailman3-web.pid --daemonize \   
   /var/log/mailman3/web/mailman-web.log   
   /usr/bin/uwsgi_python3 -->   
   /etc/alternatives/uwsgi_python3 -->   
   /usr/bin/uwsgi-core:   
   umask(000)   
   openat(... /run/mailman3-web/mailman3-web.pid   
   uwsgi-core (e.g. 2.0.21-5.1) -->   
   src:uwsgi, e.g.:   
   uwsgi-2.0.21/core/utils.c:162:          umask(0);   
   uwsgi-2.0.28/core/utils.c:162:          umask(0);   
   uwsgi-2.0.31/core/utils.c:162:          umask(0);   
      
   What exactly did you do (or not do) that was effective (or   
   ineffective)?   
      
   (partial?) Work-around?  Haven't fully tested,   
   but looks like if the PID file already exists, it won't   
   change permissions on the file, so I'll likely implement a   
   local work-around in the /etc/init.d/mailman3-web file.   
   Also, unconfirmed, but folks using systemd might not bump   
   into this issue, but regardless, the security issue would   
   appear to still be present in src:uwsgi uwsgi-core   
   and given the umask(0) in src:uwsgi, there may possibly be   
   additional security issues/risks.   
   Looking at recursive rdepends for uwsgi-core it's   
   possible/likely security issue(s) may also be exposed via   
   other packages.   
      
   What was the outcome of this action?   
      
   Existing does or may fail to properly stop due to insecure   
   PID file, and insecure PID file is also security issue.   
   Insecure umask may also have other risks, etc.   
   Work-arounds may be effective, those using systemd   
   might also not encounter this issue.   
      
   What outcome did you expect instead?   
   Was expecting PID file to be sufficiently secure,   
   and nominal stop actions to run successfully.   
      
   Note also: system is almost entirely Debian 13 stable   
   trixie, but at present still have some packages pinned to   
   Debian 12 oldstable bookworm, notably as some mailman3-web   
   related packages very seriously failed to work on Debian 13   
   when upgraded.  Have been whittling it down as feasible,   
   but at present only and exactly these packages are pinned   
   (Pin-Priority 995) to bookworm{,-{updates,security}}:   
   mailman3-web python3-django python3-django-allauth   
   python3-django-compressor python3-django-extensions   
   python3-django-hyperkitty python3-django-mailman3   
   python3-django-postorius python3-djangorestframework   
   python3-mistune uwsgi-core uwsgi-plugin-python3   
      
   Note also: until quite recently system was on systemd,   
   but very recently switched to sysvinit due to unrelated   
   systemd issues upon Debian 12 --> 13 upgrade (notably   
   systemd grossly failed to properly initialized network - had   
   been fine on 12, but not at all on 13, removed systemd and   
   went to sysvinit, then all the networking was fine again).   
      
   In addition to system described below,   
   same issue seen/reproduced on others.   
   Appears in common to be src:uwsgi uwsti-core,   
   and systemd may mask (but not eliminate) the issue.   
      
   -- System Information:   
   Debian Release: 13.3   
     APT prefers stable-updates   
     APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,   
   'stable'), (300, 'oldstable-updates'), (300, 'oldstable-security'), (300,   
   'oldstable')   
   Architecture: amd64 (x86_64)   
   Kernel: Linux 6.12.73+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)   
   Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)   
   (ignored: LC_ALL set to C), LANGUAGE not set   
   Shell: /bin/sh linked to /usr/bin/dash   
   Init: sysvinit (via /sbin/init)   
   LSM: AppArmor: enabled   
      
   Thank you very much for your attention to this and all your   
   work on Debian!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)