We all know that HP-UX is insecure (out of the box), right? Here is some
proof.

We are talking about HP-UX 10.20

One night I had nothing better to do, so I logged on to my college to
play with the computers...

I was surprised to see in MOTD that we are upgraded to Hp-UX 10.20

So I decided to check for suid binaries...

Sure enough I found a ton of them (more than 50 I belive)

One of the programs that attracted my attention was cue (Hewlett Packard
Character-based User Environment)

As it was possible to make it a login program, I decided to investigate
further...

$ export LOGNAME=root
$ cue
Welcome root

That was encouraging, of course it gave up the suid priviledges when I
got the shell, but a different problem exists...
Since it was mislead by $LOGNAME (big oops in login programs :), it
detected that I am in fact not root... BUT

When I did ls -la, among others I found this:

-rw------- root mygroup 0 IOERROR.mytty

So, it also follows my umask...

$ umask 000
$ cue
-rw-rw-rw- root mygroup  0 IOERROR.mytty

I decided to check whether or not it will follow symlinks, so I created a
symlink  to /lost+found/test (unwriteable by anyone)

$ cue
$ ls -la /lost+found
-rw-rw-rw- root mygroup 0 test

So, it also follows symlinks...

However, it wipes out the target file. A symlink to /etc/passwd comes to
mind.

But, since it follows the umask, it might be possible to replace binaries
executed by system...

In any event, a very dangerous condition...

I do not have the access to source code, so I can't think of a patch.
Probably replace getenv with getuid or something like that.

So the recommendation would be to remove the program's suid bit, as
usual.


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


> However, it wipes out the target file. A symlink to /etc/passwd comes to
> mind.

the file would retain permissions. permissions are set on create, it
probably is simply truncating the file.

>
> But, since it follows the umask, it might be possible to replace binaries
> executed by system...

See above.

>
> In any event, a very dangerous condition...

Indeed. .forward/.rhosts is the most obvious attack.

>
> I do not have the access to source code, so I can't think of a patch.
> Probably replace getenv with getuid or something like that.

It's kinda lame, but:

remove the s bit from the program, write a c program that clears the
environment and exports those variables it needs (setting the user via
getpwuid() or somesuch) then executes the program (while euid=0,
ruid=you).