Bug 1228571 – CVE-2015-3238 pam: DoS/user enumeration due to blocking pipe in pam_unix module

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 1228571 - (CVE-2015-3238) CVE-2015-3238 pam: DoS/user enumeration due to blocking pipe in pam_unix module

Summary:	CVE-2015-3238 pam: DoS/user enumeration due to blocking pipe in pam_unix module

Status:	NEW

Aliases:	CVE-2015-3238

Product:	Security Response
Classification:	Other
Component:	vulnerability (Show other bugs)
Sub Component:
Version:	unspecified
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Red Hat Product Security
QA Contact:
Docs Contact:

URL:
Whiteboard:	impact=moderate,public=20150625,repor...
Keywords:	Security

Depends On:	1233234 1233236 1249067 1249068 1249069 1249070
Blocks:	1222875
	Show dependency tree / graph

Reported:	2015-06-05 04:46 EDT by Stefan Cornelius
Modified:	2016-01-22 05:03 EST (History)
CC List:	5 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	It was discovered that the _unix_run_helper_binary() function of PAM's unix_pam module could write to a blocking pipe, possibly causing the function to become unresponsive. An attacker able to supply large passwords to the unix_pam module could use this flaw to enumerate valid user accounts, or cause a denial of service on the system.
Story Points:	---
Clone Of:
Environment:
Last Closed:
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
The patch limiting the supported password length to 512 bytes (5.54 KB, patch) 2015-06-15 05:29 EDT, Tomas Mraz	no flags	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2015:1640	normal	SHIPPED_LIVE	Moderate: pam security update	2015-08-18 18:45:27 EDT

Groups: None (edit)

Description Stefan Cornelius 2015-06-05 04:46:24 EDT

From the original report:
"If SELinux is enabled, the _unix_run_helper_binary function in Linux-PAM 1.1.8
and earlier hangs indefinitely when verifying a password of 65536 characters,
which allows attackers to conduct username enumeration and denial of service
attacks.

When supplying a password of 65536 characters or more, the process will block
on the write(2) call at modules/pam_unix/support.c:614 because it tries to
write strlen(passwd)+1 bytes to a blocking pipe and a pipe has a limited
capacity of 65536 bytes on Linux."

Acknowledgements:

Red Hat would like to thank Sebastien Macke of Trustwave SpiderLabs for reporting this issue.

Comment 2 Tomas Mraz 2015-06-15 05:27:29 EDT

So we (as PAM upstream developers) acknowledge the issue. I developed a patch that was reviewed by peer upstream developers and we will do a release after vendor notification.
Can we get a CVE assigned?

Comment 3 Tomas Mraz 2015-06-15 05:29:24 EDT

Created attachment 1038860 [details]
The patch limiting the supported password length to 512 bytes

Comment 12 Stefan Cornelius 2015-06-25 14:56:15 EDT

Public via: http://www.openwall.com/lists/oss-security/2015/06/25/13

Comment 13 Fedora Update System 2015-06-30 16:20:41 EDT

pam-1.1.8-19.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2015-07-03 14:39:08 EDT

pam-1.1.8-19.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Ashok Kumar Rajendran 2015-07-06 19:52:30 EDT

In the patch provided

linux-pam/modules/pam_unix/pam_unix_passwd.c
 static int _unix_run_update_binary

There is a "else" missing for both "if (fromwhat) " and "if (towhat)", Hence this ends up in writing  "pam_modutil_write(fds[1], "", 1);" irrespective of the value. Is it something expected or is it a bug in the patch?

Thanks,
-

Comment 16 Tomas Mraz 2015-07-07 03:51:24 EDT

Yes, that is fully intentional as we need to write the NULL byte as well.

Comment 19 errata-xmlrpc 2015-08-18 14:45:47 EDT

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7
  Red Hat Enterprise Linux 6

Via RHSA-2015:1640 https://rhn.redhat.com/errata/RHSA-2015-1640.html

Note You need to log in before you can comment on or make changes to this bug.