Conference turris::digital_unix

	Uh,

	This has been reported already, and we expect rapid fix now :-)
	I did not IPMT, but reported directly to Eng. contacts, and
	got resonse that it has been escalated now.

	Just a policy statement: Do NOT announce way to crack system
	in public places!!! ALWAYS, repeat: ALWAYS report these kind
	of problems with High Priority (Show Stopper) Escalation
	to official channels!

	I know that this problem has been widely announced in
	alpha-osf-managers, but still, our policy is not to 
	introduce ways to crack system...

	Anyway, dop is part of new SysMan GUI, and you can fix the
	hole by doing:

		# chmod 611 /usr/sbin/dop

	It will break your access to SysMan GUI from other accounts
	but root. I feel that cure has so little pain involved that
	it's worth of using this temporary medicine until the real
	medicine is available.

	I leave it up to moderator if .0 should be left public or 
	hidden. 

	regards,

		-jari

	This has been reported already, and we expect rapid fix now :-)

Oh... DIR/TITLE=dop  didn't find anything germane, so I wasn't sure.

	Just a policy statement: Do NOT announce way to crack system
	in public places!!!

This is reasonable... note, however, that I was reposting from 
BUGTRAQ, which is a public mailing list -- notes should contain 
at least the same quality of information that our customers have 
(my own opinion, of course =).

	[fix it with chmod]

That's exactly what I needed to know.  Thanks.

cheers,
mike

	Mike,

	My intention was not to blame you, I just wanted to make that
	statement because it is very hard to give instructions on
	what can be and what can't be published in Notes. The only 
	clear rule is "no crashers at all", but warning of possible
	security problem and requests for help are ALWAYS welcome. Your
	case is very clear, as 1000s of customers know the problem now
	via alpha-osf-managers and bugtraq distributions... 

	Be prepared to ne beaten in news and press :-(

		-jari

    FYI, I set the base note hidden because it sounds kinda scary....
    Correct me if I'm wrong.

	re: hiding base note.

	The readers of the alpha-osf-managers mailing list will all
	know within 24 hours if they read their on a regular basis.
	The ones on vacation will know a little later.  It shouldn't
	be long before it shows up on comp.risks, comp.sys.dec and
	comp.unix.osf.osf1.

	So, by the end of the week, nearly everybody in the world
	that matters will how to take advantage of the dop, except
	the few unlucky people within Digital that don't have outside
	News or mailing list access.

	But, at the same time, how to take advantage of it is
	less important than how to fix it.  It would be enough
	to say there is a security problem...

    RE: -.*
                    ********* DIGITAL INTERNAL USE ONLY *********
    
BSS::BOREN   "Software Security Response Team/Americas & Asia PAC" 
 4-MAR-1997 16:03:41.96
Subj:	I/U   RECENT report of DOP problem on DIGITAL UNIX

                    ********* DIGITAL INTERNAL USE ONLY *********

    Just to let everyone know - eng does have a prelim fix confirmed to
    resolve the DOP problem you may have heard of today through various
    mails etc... they are working on how to produce a kit with proper
    regression testing etc. to facilitate the packaging/delivery of a
    solution as a p0 critical. No eta's have been developed to date.
    
    We'll update the delivery/kit availibility information as it becomes
    available.

                    ********* DIGITAL INTERNAL USE ONLY *********
              

    

    I think in this case you should of allowed the posting of the
    base note.  I was very widely published and hence the damage
    was done.  Also it does help when you can verify that this
    cause the problem.
    
    By killing the base note, there it is not known what the problem
    is.  If you are going to kill that note, then you should have
    posted a followup that states that /usr/sbin/dop has a known
    security bug and fix it by doing a chmod on it.
    
    Of course, there is the other side of the story which states
    only if you publish the problem will it get fixed.  Not to mention
    that this is a Digital notesfiles, which is not as public
    as the newsgroups.  
    
    I hope someone has published a reply to the newsgroup with a 
    temporary fix to the issue or we might get a bloody nose.
    
    I am against publishing of the bug, but there needs to be
    enough info to fix it.  Also since it was widley posted it
    doesn't seem to me that killing the base note is appropiate.
    I did see the original bug and did try it.  As soon as I
    saw it worked, I immediately notified my customers that
    we have a security hole and to change permissions on that
    file.  In addition, I also stated Digital will have a more
    formal solution after the issue is analyzed.
    

    For information, the bug including documentation on how to exploit it
    was reported through proper security channels on november 29th.
    
    What scares me is the response time to such problems. We still have an
    outstanding sendmail report where a patch was promised *in this
    conference* in november if my memory serves me right.
    
    Btw, the comment from University of Oslo who reported the bug was "the
    error is probably caused by using the C-routines system(3) or popen(3),
    both of which is completely forbidden in setuid programs". Hopefully we
    don't have any more such programming errors. Would someone check the
    source pool with grep?
    
    Bj�rn

	What I know about this is that there is customer bug report 
	"Show Stopper" level from 3-dec-1996, so it really scares me if:

		- this serious problems leak to products that are shipping
		  1-3 months later than problem has been reported
		- if field service hasn't been informed about this problem
		  and it's been known problem (and workaround is very simple!)

	Re: distribution

	First channel to report this was (probably) alpha-osf-managers or
	bugtrack, and at least alpha-osf-managers had two messages introducing
	workaround (chmod 611) in less than two hours after the problem became
	widely known. Haven't checked the usenet news yet though...

			-jari

    Well, since the whole world knows about this, we might as well
    stay up with the state of the art here. If another moderator
    wants to rehide the note, be my guest.

A Bit of Good News...
    
The following BLITZ has been submitted for distribution. This will assist in 
the recommended workaround until the official patch arrives for customers 
via normal support channels.
    *                                                                           
	                                       
    NOTE: With the exception of the author, and internal data etc... this
    info was created to assist customers requiring help now in a
    workaround and describe the impacts.  The author has granted permission
    to share the problem data and comments with customers.
                                               

--------------------------------------------------------------------------
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.

			*** DIGITAL INTERNAL USE ONLY ***
      +---------------------------+TM
      |   |   |   |   |   |   |   |
      | d | i | g | i | t | a | l |             TIME DEPENDENT CASE
      |   |   |   |   |   |   |   |
      +---------------------------+

			*** DIGITAL INTERNAL USE ONLY ***
      Title/Problem Summary: 

                                               DATE: 3/5/97

      AUTHOR: Philip Vitale            		TD #:
      DTN:    462-6087
      ENET:   [email protected]		       CROSS REFERENCE #'s:
      DEPT:   UNIX Engineering - System Mgmt 	(PRISM/TIME/CLD#'s)
							CLD SSRT0435U
      INTENDED AUDIENCE: U.S./EUROPE/GIA	PRIORITY LEVEL: 1
      (U.S./EUROPE/GIA)				(1=TIME CRITICAL,
						 2=NON-TIME CRITICAL)
      ====================================================================
    
			*** DIGITAL INTERNAL USE ONLY ***
    
    
      PROBLEM:

        On DIGITAL UNIX V4.0 and higher, the Division of Privileges (DoP)
        command /usr/sbin/dop has a potential security vulnerability where
        under certain circumstances, system integrity may be compromised.
        This command has the setuid bit set and with a specifically written
        script, users have the capability of becoming root.


      RESOLUTION/WORKAROUND:

	Prior to receiving the official patch for this fix, a temporary
	workaround for this problem is to clear the setuid bit from
	the /usr/sbin/dop command as follows:

		# chmod 0 /usr/sbin/dop

	This temporary workaround will resolve the security issue, but
	will also defeat DoP's purpose.  See "ADDITIONAL COMMENTS" below
	for the purpose of DoP, the effect of using this temporary workaround,
	and what to do as a solution while using this temporary workaround.

	This security issue has been resolved and an official fix for this
	problem is being made available through official DIGITAL support
	channels.


      ADDITIONAL COMMENTS:

	The DoP command is used to provide non-root users with the
	ability to enter the root password to access the graphical
	system management applications via the CDE application manager
	or the Host Manager.  When a non-root user attempts to execute
	a system management application through one of these applications,
	the user will be prompted with a password dialog.  If the user
	enters the correct root password, they will gain root privilege
	while running the given application.

	If the setuid bit is cleared from /usr/sbin/dop, then users
	will not be able to access the system management applications
	from either the CDE application manager or the Host Manager.

	The following are workarounds to allow users to run the graphical
	system management applications with DoP disabled:
	   1) Log into a CDE session as root and access the system
	      management applications.
	   2) If logged in as a normal user, become root in your favorite
	      X-based terminal emulator (xterm, dxterm, dtterm, etc.) and
	      run the graphical system management application via the
	      command line.


			*** DIGITAL INTERNAL USE ONLY ***

\\ GRP=TIME_DEPENDENT CAT=HARDWARE DB=CSSE_TIME_CRITICAL
\\ TYPE=KNOWN_PROBLEM TYPE=BLITZ STATUS=CURRENT

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

Hi,

Today our customer asked us about the fix schedule of this problem.
I was looking for the patch from official patch area in node guru.
But I couldn't find it.

Could you tell me rough schedule of the fix if possible ?

Thank you,
Satoshi Asara 

                   ** NO RESTRICTIONS FOR DISTRIBUTION **

                          ---------CUT HERE--------

_______________________________________________________________________
  PRODUCT:  DIGITAL UNIX[TM] V4.0, V4.0A, V4.0B		MARCH 6, 1997

  TITLE:  Division of Privilege (DoP) - Potential Security Vulnerability
  SOURCE: Digital Equipment Corporation
          Software Security Response Team/Colorado Springs USA


----------------------------------------------------------------------
IMPACT:

  Digital has discovered a potential vulnerability with the
  Division of Privilege (DoP), "/usr/sbin/dop" for DIGITAL UNIX
  V4.0, V4.0A and V4.0B, where under certain circumstances,
  an unauthorized user may gain unauthorized privileges.  Digital
  strongly recommends that the workaround be implemented
  immediately for any version affected, and that the
  appropriate patch kit be installed as soon as it becomes
  available.
 

----------------------------------------------------------------------
RESOLUTION:

  This potential security issue has been resolved and an
  official fix for this problem will be made available
  beginning the 13th of March 1997. As the patches become
  available per affected version, Digital will provide them
  through:
  
  o the World Wide Web at the following FTP address:

    ftp://ftp.service.digital.com/public/
	the sub directory Digital_UNIX, key identifier SSRT0435U


  Note: [1]The patch kits mentioned above will be replaced in
        the near future through normal patch release
        procedures.

  	[2]The appropriate patch kit must be reinstalled
  	following any upgrade beginning with V4.0 
        up to and including V4.0b.
  	

----------------------------------------------------------------------
TEMPORARY WORKAROUND:

  Prior to receiving the official patch for this fix, a
  temporary workaround for this problem is to clear the
  setuid bit from the /usr/sbin/dop command as follows:

		# chmod 0 /usr/sbin/dop

  This temporary workaround will resolve the security issue,
  but will also defeat DoP's purpose.  See "ADDITIONAL
  COMMENTS" below for the purpose of DoP, the effect of
  using this temporary workaround, and what to do as a
  solution while using this temporary workaround.

----------------------------------------------------------------------
ADDITIONAL COMMENTS:

  The DoP command is used to provide non-root users with the
  ability to enter the root password to access the graphical
  system management applications via the CDE application
  manager or the Host Manager.  When a non-root user
  attempts to execute a system management application
  through one of these applications, the user will be
  prompted with a password dialog.  If the user enters the
  correct root password, they will gain root privilege while
  running the given application.

  If the setuid bit is cleared from /usr/sbin/dop, then
  users will not be able to access the system management
  applications from either the CDE application manager or
  the Host Manager.

  The following are workarounds to allow users to run the
  graphical system management applications with DoP
  disabled:

  [1] Log into a CDE session as root and access the system
  management applications.

  [2] If logged in as a normal user, become root in your
  preferred X-based terminal emulator (xterm, dxterm, dtterm,
  etc.) and run the graphical system management application
  via the command line.

  If you need further information, please contact your
  normal DIGITAL support channel.

  DIGITAL appreciates your cooperation and patience. We
  regret any inconvenience applying this information may cause.

  __________________________________________________________________
  Copyright (c) Digital Equipment Corporation, 1995 All
  Rights Reserved.  Unpublished Rights Reserved Under The Copyright 
  Laws Of The United States.
  __________________________________________________________________

    RE: .8
    
>    Btw, the comment from University of Oslo who reported the bug was "the
>    error is probably caused by using the C-routines system(3) or popen(3),
>    both of which is completely forbidden in setuid programs". 
    
    I don't see that in the man pages.  There is no securiry related note
    in at all.
    
    - Vikas

> using the C-routines system(3) or popen(3), both of which is completely 
> forbidden in setuid programs

I don't know of any reason why their use should be forbidden.  However, the
developer of the setuid program has to understand that the command they will
invoke will be run with the effective ID of the setuid program and not the real
ID of the user, and thus there is the possibility here for a trojan horse
attack.  Nevertheless, if this is properly guarded against then there should be
no problem.

Right?  (:-)


				Webb

Thye are clearly not forbidden, but you have to be careful. Specifically
in the case of system(), you have to make absolutely sure you have a
fully qualified path to the executable. Dop didn't so it was trivial
to trick it into system()'ing a command of your choosing. 

			pete

In article <[email protected]_unix>, [email protected] (I'm going to huff, and puff, and blow your house down) writes:
|> Thye are clearly not forbidden, but you have to be careful. Specifically
|> in the case of system(), you have to make absolutely sure you have a
|> fully qualified path to the executable. Dop didn't so it was trivial
|> to trick it into system()'ing a command of your choosing. 

Amplifying that: I think it would be a good idea if someone wrote
a simple script to
	find all the setuid programs installed on DUNIX system
		with all subsets loaded
	check the symbol tables of these programs to see if they
		use system() or popen()

Then this list should be used to drive a security audit of all
such programs.  I.e., for each such program, ask the maintainer
to inspect it, using the "absolutely sure you have an absolute
path" rule, plus a check that any arguments are being carefully
controlled.

I strongly suspect that the people who discovered the hole in dop
did something like this.  It seems like a good idea for us to do
it first.

With perhaps a lot more work, someone could write a checking
program, somewhat like Third Degree, that would be able to trace
the arguments to system() and popen() to find out if they came
from an external source (and hence would be subject to hacker
manipulation).

-Jeff
[posted by Notes-News gateway]

                re; Note 9029.13 -< **A CUSTOMER MESSAGE** >-
                                      
....08.mar.1997
    The kits are available for customers under the parameters noted in the
    previous message.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  	
>  Note: [1]The patch kits mentioned above will be replaced in
>        the near future through normal patch release
>        procedures.
>
>  	[2]The appropriate patch kit must be reinstalled
>   	following any upgrade beginning with V4.0 
>        up to and including V4.0b.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  	
    
Current directory is ...../public/Digital_UNIX/SSRT0435U

  SSRT0435U.README           4 Kb    Fri Mar  7 05:55:00 1997
  V40A_SSRT0435U.README      1 Kb    Fri Mar  8 03:36:00 1996
  V40A_SSRT0435U.tar        70 Kb    Fri Mar  8 03:36:00 1996 Unix Tape Archive
  V40B_SSRT0435U.README      1 Kb    Fri Mar  8 03:36:00 1996
  V40B_SSRT0435U.tar        70 Kb    Fri Mar  8 03:36:00 1996 Unix Tape Archive
  V40_SSRT0435U.README       1 Kb    Fri Mar  8 03:36:00 1996
  V40_SSRT0435U.tar         70 Kb    Fri Mar  8 03:36:00 1996 Unix Tape Archive
    

    Re .14, .15.
    
    Rik Farrow in some training material from october 1990 lists some
    golden rules on SUID programs. Among these are the following:
    
    "If you use the system() or popen() calls, always set the IFS (input
    field separator) and use full pathnames for commands."
    
    "Don't pass user specified arguments to system() or popen() calls."
    
    "The execlp() and execvp() system calls are also a problem (because
    they will execute shells to interpret their command arguments)"
    
    There are a few others, but what was done to 'dop' was definitely not a
    NEW type of attack.
    
    Bj�rn