Bugzilla – Bug 1150510
AUDIT-TRACKER: pam-python: review pam module that is not yet whitelisted in rpmlint
Last modified: 2020-03-03 14:05:55 UTC
+++ This bug was initially created as a clone of Bug #1150178 As discussed in the proactive security team we want to catch up on the packages shipping PAM modules that haven't been reviewed yet. Formerly there was no badness for this type of rpmlint check. Right now the new review bot should catch them. pam-python is one of the packages that ships a pam module that wasn't reviewed yet. So this needs a code review and a corresponding whitelisting when everything is well.
I just disclosed a local root exploit to upstream, in regards to the default environment variable handling of Python. I've also noticed some non-security related issues with the package, which you might want to look into (but won't affect the whitelisting): - not_null_argument_for_strcmp.patch invokes undefined behaviour when strrchr doesn't find a match. 'dot' is a variable not a preprocessor macro, so #ifndef is the wrong construct to use. Best case this leads to a segfault when a Python file without a "." is configured, but the optimizer can end up doing arbitrarily weird things. - the RPM doesn't declare a dependency on python - Python files are searched in /lib/security/ even on 64bit systems where PAM modules are located in /lib64/security/. Compiling with -DDEFAULT_SECURITY_DIR=%{_lib}/security would fix that.
(Making the previous comment public.) Upstream has released a fixed version 1.0.7 a few hours ago. Once that fix lands in openSUSE, we can add the whitelisting.
Hi (In reply to Malte Kraus from comment #1) > I just disclosed a local root exploit to upstream, in regards to the default > environment variable handling of Python. Although the details might be covered in the (non-public) https://bugzilla.suse.com/show_bug.cgi?id=1150178 I requested via the CVE form to MITRE a CVE for this issue, so this might be better trackable. Regards, Salvatore
(In reply to Salvatore Bonaccorso from comment #3) > Hi > > (In reply to Malte Kraus from comment #1) > > I just disclosed a local root exploit to upstream, in regards to the default > > environment variable handling of Python. > > Although the details might be covered in the (non-public) > https://bugzilla.suse.com/show_bug.cgi?id=1150178 I requested via the CVE > form to MITRE a CVE for this issue, so this might be better trackable. Which got assigned CVE-2019-16729. Regards, Salvatore
Thanks, Salvatore! I requested a CVE yesterday too, but it seems your request got processed more quickly. Bug 1150178 is just a tracker for a review of all PAM modules in (open)SUSE, it has no details. I'll see about opening it up, because I understand it can be frustrating to constantly run into these opaque barriers.
1.0.7 fixes the CVE and the strcmp error. The rest seems to be rpm packaging related, and only debian packaging is included in the pam-python source. I'd happily include the .spec file in the source and produce .rpm's if someone gave me the .spec file, but as it is it's been decades since I've done any rpm packaging.
(In reply to Malte Kraus from comment #2) > (Making the previous comment public.) > > Upstream has released a fixed version 1.0.7 a few hours ago. Once that fix > lands in openSUSE, we can add the whitelisting. Version 1.0.7 (incl. fixes for CVE-2019-16729 and strcmp error) is now in our 'security' repo: https://build.opensuse.org/package/show/security/pam-python
(In reply to Malte Kraus from comment #1) > I just disclosed a local root exploit to upstream, in regards to the default > environment variable handling of Python. > > I've also noticed some non-security related issues with the package, which > you might want to look into (but won't affect the whitelisting): Thanks a lot for reviewing, Malte! > > - not_null_argument_for_strcmp.patch invokes undefined behaviour when > strrchr doesn't find a match. 'dot' is a variable not a preprocessor macro, > so #ifndef is the wrong construct to use. Best case this leads to a segfault > when a Python file without a "." is configured, but the optimizer can end up > doing arbitrarily weird things. Fixed in upstream > - the RPM doesn't declare a dependency on python Yes, I added it already. > - Python files are searched in /lib/security/ even on 64bit systems where > PAM modules are located in /lib64/security/. Compiling with > -DDEFAULT_SECURITY_DIR=%{_lib}/security would fix that. It seems that Makefile has it's own LIBDIR. Do you want to have a patch for tarball or it should be done in spec?
(In reply to Russell Stuart from comment #6) > 1.0.7 fixes the CVE and the strcmp error. Thank you, Russell, for the new release! > > The rest seems to be rpm packaging related, and only debian packaging is > included in the pam-python source. I'd happily include the .spec file in > the source and produce .rpm's if someone gave me the .spec file, but as it > is it's been decades since I've done any rpm packaging. Thank you, but I think, even if you will provide the official spec file, each rpm-distro will prefer to have it's own spec, I guess. It would be nice if you finish migration to python3 and fix open issues in the issues tracker. I'd like to have 1.0.8 as quick as possible ;-)
In OBS sr#768759 it is currently requested to delete pam-python from Factory, because it only supports python2. So how is the migration to python3 coming? I'll have to decide whether to whitelist this PAM module now, or not. I wouldn't want to whitelist something that is about to be removed from Factory, thereby adding a stale whitelist entry.
So like I mentioned in comment 10 pam-python is now deleted from Factory. There seems to be no need for immediate action. Therefore I'm closing this bug as WONTFIX. Should it need to go to Factory in the future then please open a new bug for review.