topic Re: Problem with SUID bit in executable in Operating System - HP-UX

Problem with SUID bit in executable

Alex Vinokur — Thu, 04 Nov 2010 09:51:09 GMT

Hi,

I have the following problem.

../bin/memdbkey and ../bin/memdbkey2 are identical executables. The only different thing is permissions: ../bin/memdbkey2 has SIUD bit.

User-1: owner of the executables
hpx418> uname -a
HP-UX hpx418 B.11.23 U ia64 1139467043 unlimited-user license

hpx418> pwd
/devjuser/jp/ccjp/avinokur/proj/gadj750_CNV64/ut

hpx418> id
uid=75308(avinokur) gid=479(pm)

hpx418> ls -l ../bin/memdbkey*
-rwxr-xr-x 1 avinokur pm 2037608 Nov 4 11:15 ../bin/memdbkey*
-rwsr-sr-x 1 avinokur pm 2037608 Nov 4 12:17 ../bin/memdbkey2*

hpx418> ../bin/memdbkey
// Works fine

hpx418> ../bin/memdbkey2
// Works fine

Unber-2: Another user
hpx418> uname -a
HP-UX hpx418 B.11.23 U ia64 1139467043 unlimited-user license

hpx418> pwd
/devjuser/jp/ccjp/avinokur/proj/gadj750_CNV64/ut

hpx418> id
uid=204925(monitor) gid=20(users)

hpx418> ls -l ../bin/memdbkey*
-rwxr-xr-x 1 avinokur pm 2037608 Nov 4 11:15 ../bin/memdbkey*
-rwsr-sr-x 1 avinokur pm 2037608 Nov 4 12:17 ../bin/memdbkey2*

hpx418> ../bin/memdbkey
// Works fine

hpx418> ../bin/memdbkey2
/usr/lib/hpux64/dld.so: Unable to find library 'libicuuc.sl.34'.
Killed

Regards
Alex Vinokur

Re: Problem with SUID bit in executable

Steven Schweda — Thu, 04 Nov 2010 10:23:05 GMT

A ".doc" attachment (MS Word?) is not a
convenient form for everyone. (What's in it
besides plain text?)

> /usr/lib/hpux64/dld.so: Unable to find library 'libicuuc.sl.34'.

Ok. So where's "libicuuc.sl.34", and who
owns it, and what are its permissions
("ls -l")?

Re: Problem with SUID bit in executable

Alex Vinokur — Thu, 04 Nov 2010 10:51:39 GMT

Hi Steven,

My Word-attachment holds the same information as plain text.

=========================================================
> id
uid=75308(avinokur) gid=479(pm)

> ldd ../bin/memdbkey2 | & tee log
...

> grep libicuuc log
libicuuc.sl.34 => /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34

> ls -l /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34
lrwxr-xr-x 1 root sys 16 Feb 20 2007 /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34@ -> libicuuc.sl.34.0

> env | grep "/usr/local64/xerces-c2_6_0_icu_64b//lib"
SHLIB_PATH= ...
LD_LIBRARY_PATH= ...

=========================================================
> id
uid=204925(monitor) gid=20(users)

> ldd ../bin/memdbkey2 | & tee ~/log2
...

> grep libicuuc ~/log2
Unable to find library 'libicuuc.sl.34'.

> ls -l /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34
lrwxr-xr-x 1 root sys 16 Feb 20 2007 /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34@ -> libicuuc.sl.34.0

> env | grep "/usr/local64/xerces-c2_6_0_icu_64b//lib"
SHLIB_PATH= ...
LD_LIBRARY_PATH= ...

---------------

Regards

Re: Problem with SUID bit in executable

Steven Schweda — Thu, 04 Nov 2010 11:09:14 GMT

> > ls -l /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34
lrwxr-xr-x 1 root sys 16 Feb 20 2007 /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34@ -> libicuuc.sl.34.0

Ok. That's a link to something. Now what
about the link target, "libicuuc.sl.34.0"?

Re: Problem with SUID bit in executable

Alex Vinokur — Thu, 04 Nov 2010 11:13:11 GMT

> ls -l /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.3
4.0
-rwxr-xr-x 1 root sys 4078304 Dec 11 2006 /usr/local64/xerces-c2_6_0_icu_64b//lib/libicuuc.sl.34.0*

Thanks

Re: Problem with SUID bit in executable

Dennis Handly — Fri, 05 Nov 2010 04:17:27 GMT

> env | grep "/usr/local64/xerces-c2_6_0_icu_64b//lib"
SHLIB_PATH= ...
LD_LIBRARY_PATH= ...

As mentioned in your comp.sys.hp.hpux newsgroup post, it is important to know that the security police force dld to ignore the setting of those environment variables.

If you want those paths to be honored, you must follow the directions in dld.so(5) and edit /etc/dld.sl.conf.

Re: Problem with SUID bit in executable

Alex Vinokur — Sun, 07 Nov 2010 06:42:01 GMT

Hi

hpx418> uname -a
HP-UX hpx418 B.11.23 U ia64 1139467043 unlimited-user license
hpx418> more /etc/dld.sl.conf
/etc/dld.sl.conf: No such file or directory

Thanks

Re: Problem with SUID bit in executable

Alex Vinokur — Sun, 07 Nov 2010 06:58:42 GMT

Actually, the only thing I need is to give another process to change mode of some directory.

Is this approach correct?

> cp /usr/bin/chmod myChmod

> chmod 4555 myChmod

> ls -ld myChmod
-r-sr-xr-x 1 avinokur pm 52388 Nov 7 08:41 myChmod

Now,

> id
uid=204925(monitor) gid=20(users)

> ls -ld myDir
dr-------- 2 avinokur pm 96 Nov 7 08:42 myDir/

> chmod 777 myDir
chmod: can't change myDir: Not owner

> myChmod 777 myDir

> ls -ld myDir
drwxrwxrwx 2 avinokur pm 96 Nov 7 08:42 myDir/

====================================
Now, I would like to do something like (for any user)
int main ()
{

...
system ("./myChmod 0777 ./myDir/);

...

return 0;
}

Re: Problem with SUID bit in executable

James R. Ferguson — Sun, 07 Nov 2010 11:46:35 GMT

Hi Alex:

> Actually, the only thing I need is to give another process to change mode of some directory.

Then you need to create an executable that is owned by 'root' and has its setuid set. You don't need the setgid bit, though. The permissions will look like:

-r-sr-xr-x 1 root sys

That is, 4555

Instead of calling 'system(3S)' in your executable, simply call 'chmod(2)' to do the work.

Regards!

...JRF...

Re: Problem with SUID bit in executable

Matti_Kurkela — Sun, 07 Nov 2010 12:00:56 GMT

The problem with the "myChmod approach" is that any user that is able to execute it will also be able to get root access on the system, by using it on password files. The chmod command is not designed to be setuid: if you give it setuid root permissions, you'll be creating an unlimited master key that can bypass *all* the security in your system.

If at all possible, you should avoid setting up setuid-root programs. Perhaps you could create a group, add the users of your application to that group and then make myDir writable by that group only?

But if you absolutely must have your program change the permissions on a directory it does not own, make a small program "chmodMydir" and make it setuid root.

You should design to be as secure as possible, and to do exactly one thing and nothing else: to change the permissions of the specific directory your application needs.

The chmodMydir program should open() the desired directory for reading, then _while holding the opened file descriptor_, it should use fstat() to verify the real name of the directory and that it really is the directory your application needs, not something nasty like a symbolic link to a critical system directory.

If the directory passes the checks, use the fchmod() function on the file descriptor to change the permissions directly within your program.

(The purpose of holding the file descriptor while making the checks is to protect your chmodMydir from race conditions. A malicious user might make chmodMydir run on a symbolic link, then change where the link is pointing to while chmodMydir is running. Holding the file descriptor ensures both the checks and the fchmod() will be operating on the same object, no matter what happens in between.)

The chmodMydir program should check the return code of all the system calls it makes. If there is an error, it should output a descriptive error message (perhaps using perror() or strerror(errno)), and then exit.

It would be best if the chmodMydir program would not have to accept any input from the user directly: a hardcoded directory name would be safest. Reading the directory name from a configuration file that is writeable only by root might also be acceptable *if* you clearly document that the permissions of that configuration file will be critical for system security. If you need to accept the directory name from the command line or from an environment variable, be *extremely* careful in the checking phase.

You should assume any external data can be tampered with in order to overflow the buffers in your program, so use appropriate functions to limit the amount of data you're reading (e.g. use fgets() or strncpy() to read the directory name to your buffer, then make sure it's in fact null-terminated).

With at least these precautions, it *might* be reasonably safe to give your chownMydir program setuid-root permissions. (I'm sure I've forgotten something important: please don't blindly trust me.)

Google for "writing setuid programs" to find lots of other advice for making a program secure enough for setuid-root use.

MK

Re: Problem with SUID bit in executable

Dennis Handly — Sun, 07 Nov 2010 19:27:55 GMT

>/etc/dld.sl.conf: No such file or directory

Then you need to create that file.
Also, if all you want is chmod(2), why do you need libicuuc.sl.34?

Re: Problem with SUID bit in executable

Alex Vinokur — Tue, 09 Nov 2010 06:38:54 GMT

A lot of thanks to everyone.