Operating System - HP-UX
1832857 Members
3151 Online
110048 Solutions
New Discussion

Re: SSRT3618 Security Vulnerability in HP-UX shells

 
Berlene Herren
Honored Contributor

SSRT3618 Security Vulnerability in HP-UX shells


A security bulletin has been issued:

-----------------------------------------------------------------
Source: HEWLETT-PACKARD COMPANY
SECURITY BULLETIN: HPSBUX0308-275
Originally issued: 26 August 2003
SSRT3618 Security Vulnerability in HP-UX shells
-----------------------------------------------------------------

To access the bulletin from the itrc:

Select "maintenance and support"
Select "search technical knowledge base"
Select "HP-UX Software Security Bulletins"
Select "Search by Security Bulletin Number"
Enter "HPSBUX0308-275"
Search

The complete list of security bulletins can be found here:

http://itrc.hp.com/cki/bin/doc.pl/screen=ckiSecurityBulletin
=================================================================

Berlene
http://www.mindspring.com/~bkherren/dobes/index.htm
10 REPLIES 10
Pete Randall
Outstanding Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

Berlene,

Cheryl beat you to it:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xca755a744468af429789b937ca5fbd9b,00.html

And I have to admit that I like the way she documented it better.


Sorry I missed you in Atlanta!


Pete


Pete
Cheryl Griffin
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

I wasn't trying to beat Berlene to the post, I simply wanted to post it in the general HP-UX forum since Berlene always places these in the Security forum.

Since the shell issue affects everyone, this bulletin needs maximum exposure so that everyone obtain the patches.
"Downtime is a Crime."
Pete Randall
Outstanding Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

Ouch! Sorry Cheryl. Didn't mean to imply that you were trying to beat Berlene - and I obviously didn't notice that it was in different forums. I'll be quiet.


Pete


Pete
Cheryl Griffin
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

No harm Pete. I wanted to respond just to say that I don't want to step on Berlene's toes, because she does a super job at keeping everyone updated.
"Downtime is a Crime."
Berlene Herren
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

You guys say the nicest things :-) Cheryl is right, this one needs max exposure.

Berlene
http://www.mindspring.com/~bkherren/dobes/index.htm
Jeff Schussele
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

Berlene,

The description in the bulletin is rather vague. Could you expand on it at all?
For instance, how could "Improper error checking of various sytem calls" allow an exploit? And is "name based on a process id" part of the problem?

Thanks,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Berlene Herren
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

Hi Jeff,
All I can give you is what I found on the cert site:

When performing the "<<" redirection, /bin/sh creates a temporary file in /tmp with a name based on the process id, writes subsequent input out to that file, and then closes the file before re-opening it as the standard input of the command to be executed. At no stage are the results of the creat(), write(), or open() calls checked for an error status.
II. Impact
It is possible for another user to alter what is read from this file.
If the sticky bit is not set on /tmp, the file can be simply removed, and a new file created in its place
If the sticky bit is set, then it is possible to guess what the file will be called and create it before /bin/sh does (the creat() call performed by the shell does not result in an open() call with O_EXCL set) and hence it is possible to maintain a handle on the underlying file.
If a fifo is created in place of the temporary file it is particularly easy to insert an extra command into the input transparently, and without having to worry about ensuring the bug is exploited during the narrow window of time in which it occurs.
Even without reading, creating this file may block the execution of commands using the << operator.
It may also be possible to create a symbolic link named as the temporary file and pointed to any other file on the system writable by the user of the shell, which may lead to corruption of the file to which the link is pointed.

Berlene
http://www.mindspring.com/~bkherren/dobes/index.htm
Jeff Schussele
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

Ahhh, I see now said the blind man.
Thanks Berlene - makes perfect sense.

I wonder if you might encourage your staff to possibly include more of the CERT details into it's bulletins? Then we wouldn't have to surf to the CERT site for them.

Thanks,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Berlene Herren
Honored Contributor

Re: SSRT3618 Security Vulnerability in HP-UX shells

I will certainly pass that suggestion on, Jeff.

Tks
Berlene
http://www.mindspring.com/~bkherren/dobes/index.htm
Alan Turner
Regular Advisor

Re: SSRT3618 Security Vulnerability in HP-UX shells

On this topic of creating a file with the name the shell would use, thereby
causing denial of service, I think I may have come across another scenario
where this happens, even with PHCO_27345, 27019, 26561.
The problem is in the thread "11i boot: auto_parms[1589]: /tmp/sh##.###:" in
the HPUX System Administration forum.
Not fully resolved - and I'll have to suspend investigation for a week as we're
shipping some of the boxes - but what i suspect is happening is that the shell
is trying to create a temp file so that it can source a start-up script, is starting
with /tmp/sh76.1 and running throug hto /tmp/sh76.113 then baling out
(another system, got failure at /tmp/sh81.113). I think the reason the files
accumulate is that one of the sourced scripts mounts local filesystems, so
/tmp is used as a mount point and the temp file can't be deleted from the /tmp
directory on the root FS.
N.B. Further investigation is needed - other explanations are being
considered -see thread for more info - but I'll have to wait a few days before
continuing.