Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Fri, Apr 08, 2005 at 04:28:13PM -0700, Steve Langasek wrote: Um, no, they are not. I don't need to dig into the source to know you're wrong. Check the PAM spec, the API documentation in the pam-doc package, or the symbol table of any Debian version of libpam.so.0 -- if these symbols are missing, your build is very badly broken. You are right, sorry, reviewing it again I've found that the code is indeed in the library (actually in pam_item.c). I will try to check what's wrong here... Javier signature.asc Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Mon, Apr 04, 2005 at 02:45:24AM -0400, Sam Hartman wrote: I'd recommend importing PAM 0.78's upstream and then looking at each of the debian local patches and seeing whether they should be maintained, dropped or modified. Well, I've dedicated an hour of work to this today and I've (almost) gotten the 0.78 package to work. Attached is my current diff to the 0.78 sources forward porting the Debian patches (although debian/patches-applied has not been updated). The package builds fine save for one issue: applications that use the libpam library do not compile properly. This includes both pam_tally (which is installed by the package in /usr/sbin) and the examples). All applications build fail with: ../../libpam/libpam.so: undefined reference to `pam_get_item' ../../libpam/libpam.so: undefined reference to `pam_set_item' However this is _not_ related to the Debian patches it happens to the original source too. If you get the original sources and try to compile it will not work (the first failure you get is when trying to compile pam_tally), moreover, if in the original sources you build the library (not the modules) and then try to compile the examples in you get this: pam-0.78.orig/Linux-PAM/examples$ LC_ALL=C make gcc -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -Dlinux -g -O2 -I./include -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/include -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpamc/include -fPIC -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam_misc/include -o blank blank.o -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpamc -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam_misc -lpam -lpam_misc blank.o(.text+0x15e): In function `main': /home/jfs/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/examples/blank.c:76: undefined reference to `pam_misc_drop_env' /home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/libpam.so: undefined reference to `pam_get_item' /home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/libpam.so: undefined reference to `pam_set_item' collect2: ld returned 1 exit status make: *** [blank] Error 1 :-? I guess this is a bug upstream, since it seems that applications need to define this functions before using PAM. A workaround for this is _not_ compiling the applications (or the examples) and don't include the pam_tally binary in the package (commenting the installation routine in debian/rules and removing it from debian/libpam-modules.files). This is done in the patch and the package builds fine. I'm not sure if people will miss pam_tally though. BTW, it's missing a manpage so I can't really tell what this is for :-? Please tell me if this solution is OK for you. I could provide this new PAM version in experimental, for others to use... Regards Javier signature.asc Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Fri, Apr 08, 2005 at 07:53:06PM +0200, Javier Fernández-Sanguino Peña wrote: pam-0.78.orig/Linux-PAM/examples$ LC_ALL=C make gcc -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -Dlinux -g -O2 -I./include -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/include -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpamc/include -fPIC -I/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam_misc/include -o blank blank.o -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpamc -L/home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam_misc -lpam -lpam_misc blank.o(.text+0x15e): In function `main': /home/jfs/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/examples/blank.c:76: undefined reference to `pam_misc_drop_env' /home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/libpam.so: undefined reference to `pam_get_item' /home/devel/debian/NMU/pam-modules/orig/pam-0.78.orig/Linux-PAM/libpam/libpam.so: undefined reference to `pam_set_item' collect2: ld returned 1 exit status make: *** [blank] Error 1 I guess this is a bug upstream, since it seems that applications need to define this functions before using PAM. A workaround for this is _not_ compiling the applications (or the examples) and don't include the pam_tally binary in the package (commenting the installation routine in debian/rules and removing it from debian/libpam-modules.files). This is done in the patch and the package builds fine. undefined reference means that libpam.so does not contain symbols for these functions. That's a rather critical problem, considering these are core PAM functions. You also say that applications fail with ../../libpam/libpam.so: undefined reference to `pam_get_item' ../../libpam/libpam.so: undefined reference to `pam_set_item' ... which means that the PAM library itself is looking for these functions and can't find them. Upstream bug or not, this .so is totally screwed; this isn't something you can patch around by choosing not to build stuff. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
I hate to be a pain in the ass, but it is going to be very difficult for me to take a huge .diff.gz that applies all the debian patches. That's hard to audit, hard to understand and not well documented. I'm happy to give you access to the repository so you can work on a branch and try to get things in shape, but you'll need to make reasonably small commits with good commit logs. I want to make it clear that I do appreciate the effort you've put in. However I think having pam work is critical and so I think we need to work on the package using good software engineering methodology. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Fri, Apr 08, 2005 at 12:20:10PM -0700, Steve Langasek wrote:
undefined reference means that libpam.so does not contain symbols for
these functions. That's a rather critical problem, considering these are
core PAM functions.
If you took a little bit of time to dig into the source before making
statements you would see this:
libpam/include/security/_pam_types.h:
extern int pam_set_item(pam_handle_t *pamh, int item_type, const void
*item);
extern int pam_get_item(const pam_handle_t *pamh, int item_type,
const void **item);
These new functions are _external_ to the PAM library itself but
applications need to build them in.
You also say that applications fail with
../../libpam/libpam.so: undefined reference to `pam_get_item'
../../libpam/libpam.so: undefined reference to `pam_set_item'
... which means that the PAM library itself is looking for these functions
and can't find them. Upstream bug or not, this .so is totally screwed;
this isn't something you can patch around by choosing not to build stuff.
No, again, you are not reading properly what I said. I said that
building and _linking_ upstream applications failed with that bug because
neither the examples (which we don't ship) neiter pam_tally (an application
PAM installs in /usr/sbin/ but which is neither documented not used) don't
define pam_get_item or pam_set_item, which any application linking to PAM
should do. So, yes, this is a bug in the upstream sources and, yes, this
can potentially mean that other applications that link to PAM sources might
need to get updated but is _not_ totally screwed.
I could actually get those to compile just by patching the source and
adding:
int pam_set_item(pam_handle_t *blah int blah, void *blah) {
return 0;
}
in them. So that they are available when PAM they are compiled with this
new libpam version.
Please take a minute to either read my e-mails in depth or go through the
sources yourself before taking a wild guess.
Regards
Javier
signature.asc
Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Fri, Apr 08, 2005 at 03:35:17PM -0400, Sam Hartman wrote: I hate to be a pain in the ass, but it is going to be very difficult for me to take a huge .diff.gz that applies all the debian patches. That's hard to audit, hard to understand and not well documented. I'm Well documented? The diff is just a forward patch of the Debian patches, so I've basicly done: 1) take pam-0.78 2) apply the patch used for 0.76-22 to 1) 3) fix the rejects 4) build the package and fix the building issues. happy to give you access to the repository so you can work on a branch and try to get things in shape, but you'll need to make reasonably small commits with good commit logs. Ok. If you want to go that route is fine by me. My alioth login is the same as my Debian login btw. I will need to investigate subversion branches if you intend for me to create one, I'm familiar enough with CVS, but not that much with subversion (although I do contribute in some subversion repos at alioth, mainly d-i) I want to make it clear that I do appreciate the effort you've put in. However I think having pam work is critical and so I think we need to work on the package using good software engineering methodology. Regardless of the changes at subversion, and to get wider testing, would you approve to an upload to _experimental_ of pam 0.78? (maybe with big red warnings labeling it as an untested release, even though it's in experimental). Also note that one of the reasons of such an unwildely patch is that the Debian sources are heavily patched. Actually, I really cannot understand why some of the improvements (like the manpages in debian/local/) have not been contributed back upstream. Some Debian fixes seem to have found their way back upstream, but there are still a number of deviations... I've also looked up at the patches produced by Mandrake, RedHat and SuSE to PAM 0.78 and I'm wondering if it would be worthwhile to review these and add them to the Debian shipped version too... Regards Javier signature.asc Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Sat, Apr 09, 2005 at 12:34:23AM +0200, Javier Fernández-Sanguino Peña wrote:
On Fri, Apr 08, 2005 at 12:20:10PM -0700, Steve Langasek wrote:
undefined reference means that libpam.so does not contain symbols for
these functions. That's a rather critical problem, considering these are
core PAM functions.
If you took a little bit of time to dig into the source before making
statements you would see this:
libpam/include/security/_pam_types.h:
extern int pam_set_item(pam_handle_t *pamh, int item_type, const void
*item);
extern int pam_get_item(const pam_handle_t *pamh, int item_type,
const void **item);
These new functions are _external_ to the PAM library itself but
applications need to build them in.
Um, no, they are not. I don't need to dig into the source to know you're
wrong. Check the PAM spec, the API documentation in the pam-doc package, or
the symbol table of any Debian version of libpam.so.0 -- if these symbols
are missing, your build is very badly broken.
You also say that applications fail with
../../libpam/libpam.so: undefined reference to `pam_get_item'
../../libpam/libpam.so: undefined reference to `pam_set_item'
... which means that the PAM library itself is looking for these functions
and can't find them. Upstream bug or not, this .so is totally screwed;
this isn't something you can patch around by choosing not to build stuff.
No, again, you are not reading properly what I said. I said that
building and _linking_ upstream applications failed with that bug because
neither the examples (which we don't ship) neiter pam_tally (an application
PAM installs in /usr/sbin/ but which is neither documented not used) don't
define pam_get_item or pam_set_item, which any application linking to PAM
should do. So, yes, this is a bug in the upstream sources and, yes, this
can potentially mean that other applications that link to PAM sources might
need to get updated but is _not_ totally screwed.
I could actually get those to compile just by patching the source and
adding:
int pam_set_item(pam_handle_t *blah int blah, void *blah) {
return 0;
}
Of course you could get it to compile that way, but that's broken beyond
belief. pam_set_item() is an interface for setting data associated with the
pam_handle_t handle, and *must* be provided by the library.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
Javier == Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Javier On Thu, Mar 24, 2005 at 08:49:01PM -0500, Sam Hartman Javier wrote: severity 300775 wishlist tags 300775 -security Javier ^ Why this? PAM 0.76 is indeed Javier vulnerable to the issues fixed in 0.78 Someone pointed out in mail to this bug that Debian is not vulnerable to these issues because of local patches. Hi. I've explicitly decided not to upgrade PAM for sarge. I had also decided when 0.77 came out that I didn't see a good reason to take it. Taking a new pam release is a painful process. Javier Yes, it might be painful, but fixing bugs is also Javier important and these releases are primarily bug-fix Javier releases. That said, I'm looking for people to help with PAM. Would you be interested? Are you familiar with pam enough to help try and merge in a new release? Javier I can help out, I am not extremely familiar with PAM but Javier wouldn't mind jumping in and helping you with this Javier release. Since sarge's base is frozen maybe an upload to Javier experimental with 0.78 plus patches would be best right Javier now and have it move into sid as soon as sarge is PAM is maintained in a subversion repository on alioth. I can give you write access to that repository if you're sufficiently familiar with subversion etc. I'd recommend importing PAM 0.78's upstream and then looking at each of the debian local patches and seeing whether they should be maintained, dropped or modified.
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
On Thu, Mar 24, 2005 at 08:49:01PM -0500, Sam Hartman wrote: severity 300775 wishlist tags 300775 -security ^ Why this? PAM 0.76 is indeed vulnerable to the issues fixed in 0.78 Hi. I've explicitly decided not to upgrade PAM for sarge. I had also decided when 0.77 came out that I didn't see a good reason to take it. Taking a new pam release is a painful process. Yes, it might be painful, but fixing bugs is also important and these releases are primarily bug-fix releases. That said, I'm looking for people to help with PAM. Would you be interested? Are you familiar with pam enough to help try and merge in a new release? I can help out, I am not extremely familiar with PAM but wouldn't mind jumping in and helping you with this release. Since sarge's base is frozen maybe an upload to experimental with 0.78 plus patches would be best right now and have it move into sid as soon as sarge is released... Have you reviewed 0.78 or is that still work todo, if that is still pending I could try to get 0.78 preliminary packages out there Regards Javier signature.asc Description: Digital signature
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
severity 300775 wishlist tags 300775 -security thanks Hi. I've explicitly decided not to upgrade PAM for sarge. I had also decided when 0.77 came out that I didn't see a good reason to take it. Taking a new pam release is a painful process. That said, I'm looking for people to help with PAM. Would you be interested? Are you familiar with pam enough to help try and merge in a new release? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300775: Pam: newer upstream version (0.78) available fixing security bugs
Package: libpam-runtime Version: 0.76-22 Priority: serious Tags: security It seems we are missing some of upstream releases (0.77 was released in September 2002 and 0.78 was released in November 2004). Please package this new release: ftp://ftp.kernel.org/pub/linux/libs/pam/pre/library/ The 0.78 release includes two important security bugs as well as some of the patches from Debian and other releases. The relevant security bugs are: - Severe denial of service possible in pam_unix - Pam_wheel with the trust module can be spoofed Some other fixes in the PAM modules might be security-related, see below. The full changelog entries are: 0.78: Do Nov 18 14:48:36 CET 2004 * pam_unix: change the order of trying password changes - local first, NIS second (t8m) * pam_wheel: add option only_root to make it affect authentication to root account only * pam_unix: test return values on renaming files and report error to syslog and to user * pam_unix: forced password change shouldn't trump account expiration * pam_unix: remove the use of openlog (from debian - toady) * pam_unix: NIS cleanup (patch from Philippe Troin) * pam_access: you can now authenticate an explicit user on an explicit tty (from debian - toady) * pam_limits, pam_rhosts, pam_unix: fixed hurd portability issues (patch from Igor Khavkine) * pam_env: added comments in the configuration file to avoid errors (from debian - toady) * pam_mail: check PAM_NO_ENV to know if we can delete the environment variable (from debian - toady) * pam_filter: s/termio/termios/g (from debian - toady) * pam_mkhomedir: no maxpathlen required (from debian - toady) * pam_limits: applied patch to allow explicit limits for root and remove limits on su. (from debian - toady) * pam_unix: severe denial of service possible with this module since it locked too aggressively. Bug report and testing help from Sascha Loetz. (Bug 664290 - agmorgan) * getlogin was spoofable: /tmp/ and /dev/ have the same number of characters, so 'ln /dev/tty /tmp/tty1 ; bash /tmp/tty1 ; logname' attacks could potentially spoof pam_wheel with the 'trust' module argument into granting access to a luser. Also, pam_unix gave odd error messages in such a situation (logname != uid). This problem was found by David Endler of iDefense.com (Bug 667584 - agmorgan). * added my new DSA public key to the pgp.keys.asc file. Also included a signed copy of my new public key (1024D/D41A6DF2) made with my old key (1024/2A398175). * added include directive to config file syntax. The whole idea is to create few systemwide pam configs and include parts of them in application pam configs. (patch by Dmitry V. Levin [EMAIL PROTECTED]) (Bug 812567 - baggins). * doc/modules/pam_mkhomedir.sgml: Remove wrong debug options (Bug 591605 - kukuk) * pam_unix: Call password checking helper whenever the password field contains only one character (Bug 1027903 - kukuk) * libpam/pam_start.c: All service names should be files below /etc/pam.d and nothing else. Forbid paths. (Bug 1027912 - kukuk) * pam_cracklib: Fix error in distance algorithm in the 0.9 pam_cracklib module (Bug 1010142 - toady) * pam_userdb: applied patch from Paul Walmsley [EMAIL PROTECTED] it now indicates whether encrypted or plaintext passwords are stored in the database needed for pam_userdb (BerliOS - toady) * pam_group: The module should also ignore PAM_REINITIALIZE_CRED to avoid spurious errors (from Linux distributors - kukuk) * pam_cracklib: Clear the entire options structure (from Linux distributors - kukuk) * pam_issue: We write a NUL to prompt_tmp[tot_size] later, so make sure that the destination is part of the allocated block, make do_prompt static (from Linux distributors - kukuk) * ldconfig: Only run full ldconfig, if we don't install into a FAKEROOT environment, else let ldconfig only create the symlinks correct (from Linux distributors - kukuk) * pam_unix/pam_pwdb: Use SIG_DFL instead of SIG_IGN for SIGCHLD (from Linux distributors - kukuk) * Add most of Steve Grubb's resource leak and other fixes (from Linux distributors - kukuk) * doc/Makefile: Don't include .cvsignore files in tar ball (kukuk) * libpam_misc/misc_conv.c: Differentiate between Ctrl-D and Return (Bug 1032604 - kukuk) * Make.Rules.in: Add targets for installing man pages for modules (from Linux distributors - kukuk) * Add pam_xauth module (Bug 436440 - kukuk) * Add pam_localuser module (Bug 436444 - kukuk) * Add pam_succeed_if module (from Linux distributors - kukuk) * configure.in: Fix check for libcrypt (Bug 417704 - kukuk) * Add the broken_shadow argument to pam_unix, for ignoring errors reading shadow information (from Linux distributors - kukuk) * Add patches to make PAM modules reentrant (Bug 440107 - kukuk) * Merge patches from Red Hat (Bug 477000 and other - kukuk) * Fix pam_rhosts option parsing (Bug 922648 - kukuk) * Add $ISA support in config files (from Red Hat - kukuk) 0.77: Mon Sep 23 10:25:42
