Subject: Security problem with Pine? help!

From: [email-masked]
Date: 16 Jul 1994 18:23:27 -0400

I recently installed pine3.8.9 on a Sparc 5 running SunOS 4.1.3_U1.
I also am running shadow passwording. The problem is that if I go
into setup within pine, I am allowed to change my passwd, which is
then changed in /etc/passwd, NOT /etc/security/passwd.adjunct. This
of course defeats the purpose of shadow passwords. HELP!!!!!!

Frank DiGennaro
[email-masked]

-- 
Frank DiGennaro
[email-masked]
" As far Back As I Can Remember, I Always Wanted To Be A Gangster."
		-- Henry Hill, Brooklyn, N.Y. 1955

---

From: [email-masked] (Jim Davis)
Date: 16 Jul 1994 17:42:03 -0700

In article <[email-masked]>,  <[email-masked]> wrote:
:
:
:I recently installed pine3.8.9 on a Sparc 5 running SunOS 4.1.3_U1.
:I also am running shadow passwording. The problem is that if I go
:into setup within pine, I am allowed to change my passwd, which is
:then changed in /etc/passwd, NOT /etc/security/passwd.adjunct. This
:of course defeats the purpose of shadow passwords. HELP!!!!!!

Worked for me on a Solaris 2.3 machine.

But there is a serious security problem here.  If you look at the
implementation in osdep/chnge_pw, you'll see

    strcpy(cmd_buf, "passwd");
    system(cmd_buf);

Note a relative pathname is used.  This is vulnerable to Trojans in
your $PATH.  I wish I'd noticed the password-changing function before;
looks like I'll be doing a quick edit and recompiling pine on a few
platforms tonight!

I don't see why a mail user agent needs a password-changing function
at all, but this implementation is seriously broken.  Besides the
security hole, passwd isn't necessarily the right program to call.  On
some systems it should be yppasswd or nispasswd instead.

---

From: [email-masked] (Mumit Khan)
Date: 17 Jul 1994 18:10:27 GMT

>looks like I'll be doing a quick edit and recompiling pine on a few

After our systems got broken in a few months ago, PINE was one of the 
pkgs I rebuilt on all of our 5 platforms to take out the password 
changing ``feature'' (which means that I can't use the pre-compiled 
binaries ... sigh). 

>some systems it should be yppasswd or nispasswd instead.

I can see the use of having this, since you might want to have email-only
accounts, with a hacked-up PINE as your shell -- but that's probably
not common at most sites. My recommendation would be take it out
completely, or if not, do a better job of calling the underlying password 
routines to handle NIS+/NIS/C2 etc systems transparently as well.

mumit

---

From: [email-masked] (Jim Davis)
Date: 17 Jul 1994 19:32:08 -0700

In article <[email-masked]>,
Mumit Khan <[email-masked]> wrote:

:I can see the use of having this, since you might want to have email-only
:accounts, with a hacked-up PINE as your shell -- but that's probably
:not common at most sites. My recommendation would be take it out
:completely, or if not, do a better job of calling the underlying password 
:routines to handle NIS+/NIS/C2 etc systems transparently as well.

Perhaps the full pathname to the appropriate password program could be
#define'd in the appropriate osdep/os-xxx.h header file; then it would
be a configurable option for systems where there are different
possible choices.  Even then calling system() wouldn't be wise -- the
pathname argument could be subverted by games with the IFS environment
variable.  An explicit fork and exec would be safer.  Leaving out this
option altogether would be safer still.