topic Re: suid script help in Operating System - HP-UX

suid script help

Belinda Dermody — Tue, 18 Oct 2005 08:37:48 GMT

I know suid scripts is a security risk, I have a HPUX 11i system, my problem is I need to let the users know that there password is about to expire. I have about 200 users and the 7 day warning is either ignore or they just do not see it. The system goes into a Database Menu system and the users do not get to the Unix prompt (95% of them couldn't spell unix) and when they exit the database I log them off the system. My problem is I am using the /usr/lbin/getprpw and if the results is less than 7 days to display BIGGER Message that they need to contact the HELP DESK to change there password.
I did a 4755 on the script and it starts with a #!/usr/bin/sh but when I test it under my userid it comes back.
Not Superuser

Re: suid script help

Mel Burslan — Tue, 18 Oct 2005 08:52:34 GMT

So, how do you get the number of days left on the password lifetime using the /usr/lbin/getprpw command and what does your script return ? An error code ? if so, what is the error code (aka exit status) ? If no errors, what do you expoect to see that you can not see ?

Re: suid script help

Belinda Dermody — Tue, 18 Oct 2005 08:58:05 GMT

/usr/lbin/getprpw -m exptm
will return
exptm=89 # That is the number of days till expiration.

The script runs fine as root, but when I run it as a user it comes back
Not Superuser on the next line instead of the exptm=89

Re: suid script help

Gary L. Paveza, Jr. — Tue, 18 Oct 2005 09:46:56 GMT

My understanding is that a script cannot be SETUID (it can be set, but it's ignored). Instead, a program can be setuid that a non-root script can execute. We had a requirement that certain users be able to chown/chmod files that they did not own - so we wrote a c program to do it, then setuid it, and called it from a script. Works like a charm.

Re: suid script help

Belinda Dermody — Tue, 18 Oct 2005 09:50:22 GMT

Thanks Gary, but boo hoo, that is not what I was looking for, I can write pretty good scripts in shell and a little perl and with advice from you guys, but C programming is out of my realm and I am too old to learn. I do not want to use sudo because that means they will be putting in there passwd twice within a few seconds and most of the time for no reason for the sudo command.

Re: suid script help

Jean-Luc Oudart — Tue, 18 Oct 2005 11:53:08 GMT

Hi

I would use "C" programming with a little help :
#####################################
#include
#include

#define SCRIPT "/usr/local/bin/security/yourscript.sh "

main (argc,argv)
char **argv;
int argc;
{
int i;
char comm[200];
(void)strcat(comm,SCRIPT);
/* printf("commande : %s\n",comm); */
/* printf("nb arg : %d\n",argc); */
for(i=1; i < argc ; i++) {
(void)strcat(comm,argv[i]);
(void)strcat(comm," ");
}
/* printf("commande : %s\n",comm); */
system(comm);
}
######################################
compile this program (as root)
cc pgm.c -o pgm
mv pgm /usr/local/bin/security/.
(adapt for your directory)
The script is owned by root
with 0700 permission.
the program "pgm" will call the script with relevant parameter.
Please note full path for the script !

the pgm will be owned by root with 4555 permission.

test the script 1st (as root)
Wrapp it

Regards
Jean-Luc

Re: suid script help

Robert Fritz — Wed, 19 Oct 2005 12:12:11 GMT

One problem with the proposed c-program... it gives everyone on the system root priv. (on most systems this is not the intent)

Here is the demonstration(my 0700 script just echos "hi"):

I compiled the program:
# cc pgm.c -o pgm
# su fritzr
$ id
uid=13553(fritzr) gid=778(security)
$ ./rootgift ';id'
hi
uid=13553(fritzr) gid=778(security) euid=0(root)

Substitute "id" with "rm -rf *" and an arbitrary user has just wiped your system.

There are two problems with the program: #1, unchecked buffer, #2 (the easier exploit), unchecked execution of arbitrary user arguments at elevated privilege.

I'd suggest the following instead:

#####################################

main ()
{
setreuid(0,0);
system("/usr/lbin/getprpw -m exptm `id -nu`");
}
######################################
compile this program (as root)
cc daysleft.c -o daysleft
mv daysleft
Then make a script
with 0555 permission that runs pgm and parses the output.

daysleft will be owned by root with 4555 permission.

The reasons this *doesn't* create a security hole:
1) There is no unchecked buffer to overflow, and
2) there is no untrusted input run by a privileged program

Re: suid script help

A. Daniel King_1 — Thu, 20 Oct 2005 11:29:08 GMT

There is always a risk with SUID:

PATH=/tmp:$PATH ;
echo ksh > /tmp/id ;
chmod 700 /tmp/id ;
./daysleft

Instant root shell.

Re: suid script help

Robert Fritz — Thu, 20 Oct 2005 11:38:51 GMT

Fair enough... I failed to specify the full path... guess I was typing too fast. Substitute /usr/bin/id for id to close the hole.

Re: suid script help

A. Daniel King_1 — Thu, 20 Oct 2005 11:59:51 GMT

You'll still need some date math. exptm lists only the password expiration period. I like GNU date (gdate) to do this in shell scripts, but there are scripts which will do similar things. The following uses gdate, and does not use getprpw ...

#!/usr/bin/ksh

PATH=/usr/bin:/usr/local/bin

exptime=$(grep u_exp /tcb/files/auth/$(echo $LOGNAME | sed "s/^$.$.*$/\1/")/$LOGNAME | sed "s/.*u_exp#$[^:]*$.*$/\1/")
chgtime=$(grep u_succhg /tcb/files/auth/$(echo $LOGNAME | sed "s/^$.$.*$/\1/")/$LOGNAME | sed "s/.*u_succhg#$[^:]*$.*$/\1/")

expires_on=$(gdate -d "January 1, 1970 $chgtime seconds $exptime seconds" +%Y%m%d)
expires_less_seven_days=$(gdate -d "$expires_on 7 days ago" +%Y%m%d)
today=$(gdate +%Y%m%d)

echo Expires $expires_on, less seven days $expires_less_seven_days v $today $((expires_on-$today)) ...

if [ $today -ge $expires_less_seven_days ]
then
echo "Your password is expiring soon!"
exit 1
else
echo "No password change coming this week."
fi

exit 0

Re: suid script help

Belinda Dermody — Thu, 20 Oct 2005 12:53:51 GMT

Daniel, what I see I like, but I went to the GNU site and I couldn't find any reference for gdate and also the HP software site with no luck. Could you point me to where you got it from...

Re: suid script help

Jeff_Traigle — Thu, 20 Oct 2005 15:28:15 GMT

I saw the comment that you don't want to use sudo because the users would need to enter their password a second time, but didn't notice anyone addressing your point. What you stated is not necessarily true. There is an option when configuring a command or group that will allow the authorized users to execute the command with entering their password. Check out the sudo man page for the details. I don't remember the syntax off the top of my head, but I know this is possible.

Re: suid script help

A. Daniel King_1 — Tue, 25 Oct 2005 05:34:11 GMT

Ah, sorry about the naming. "gdate" is GNU "date" part of the shell-utils (now part of coreutils). The prepending of the "g" is a fairly common practice, but it is not the default name. I've not used this particular package, preferring to compile my own. There seem to be some dependencies, which I donâ t recall needing for the run-time for gdate, though.

http://hpux.cs.utah.edu/hppd/hpux/Gnu/coreutils-5.2.1/

Theyâ ve also got sudo, which is fairly easy to use as well,

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/sudo-1.6.8p9/

The syntax for the sudo config item without passwords is as follows (presuming your account is jmarrion):

jmarrion ALL = NOPASSWD: /usr/lbin/getprpw

or for a system group called â itrcâ :

%itrc ALL = NOPASSWD: /usr/lbin/getprpw

"visudo" is the configuration command for sudo.

WARNING: This does not limit the use of getprpw to the calling user, so users would be able to read information other than their own. Perhaps something would be better like:

jmarrion ALL = NOPASSWD: /usr/local/bin/getexptm

where getexptm is:

#!/usr/bin/ksh

/usr/lbin/getprpw $LOGNAME