Bug 1150510 - AUDIT-TRACKER: pam-python: review pam module that is not yet whitelisted in rpmlint
AUDIT-TRACKER: pam-python: review pam module that is not yet whitelisted in r...
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Malte Kraus
E-mail List
:
Depends on:
Blocks: 1150178
  Show dependency treegraph
 
Reported: 2019-09-12 10:28 UTC by Matthias Gerstner
Modified: 2020-03-03 14:05 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2019-09-12 10:28:08 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.
Comment 1 Malte Kraus 2019-09-17 14:15:47 UTC
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.
Comment 2 Malte Kraus 2019-09-23 08:25:55 UTC
(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.
Comment 3 Salvatore Bonaccorso 2019-09-23 19:42:00 UTC
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
Comment 4 Salvatore Bonaccorso 2019-09-24 04:37:13 UTC
(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
Comment 5 Malte Kraus 2019-09-24 06:17:08 UTC
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.
Comment 6 Russell Stuart 2019-09-24 08:07:27 UTC
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.
Comment 7 Alexander Naumov 2019-09-24 09:35:47 UTC
(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
Comment 8 Alexander Naumov 2019-09-24 09:46:59 UTC
(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?
Comment 9 Alexander Naumov 2019-09-24 10:26:00 UTC
(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 ;-)
Comment 10 Matthias Gerstner 2020-01-31 09:50:33 UTC
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.
Comment 11 Matthias Gerstner 2020-03-03 14:05:55 UTC
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.