Subject: RE: script extensibility I-D

From: "Wallis, David" <[email-masked]>
Date: Tue, 12 Jun 2001 14:14:46 -0500

The protocol described in the referenced document is insecure in the
following details:

1) Scripts passed as ordinary files may be insecure.

On pages 3 and 4 it states:
   The SMX protocol uses a local storage device (usually implemented on
   top of the local file system) to transfer scripts from the SNMP agent
   to the runtime systems. The SNMP agent has read and write access to
   the script storage device while the runtime systems only need read
   access. The SMX protocol passes the location of a script in the local
   storage device to the runtime engines. It is then the responsibility
   of the runtime engines to load the script from the specified
   location.
A well-known Unix security hole required recoding the kernel in order to
securely support setuid scripts because the name of the script was passed to
the runtime engine, not a location. In certain cases it was found possible
to exploit the situation by causing a filesystem directory to point to a
different file than the one rightfully given setuid privilege by the kernel
in the small window of time between when the setuid privilege was granted by
the kernel and the runtime engine opened the file to execute the script. For
those Unix kernels which still support setuid scripts; the kernel now opens
the script, makes the runtime engine process setuid, and passes the open
filehandle of the script to the runtime engine.

I believe the SMX procedure described above may introduce similar problems
without careful consideration to avoid them. While the text noted above may
be interpreted to avoid the problem by passing an open filehandle to the
runtime engine, in the absense of clarification a naive interpretation would
be to consider a filename to be a "location of a script in the local storage
device" and so would permit insecure implementation.

2) Environment variables are not access protected.

On the bottom of page 5 it states:
   The security assumption here is that access to the process
   environment is protected by the operating system.
This assumption is invalid on many (most?) operating systems. The statement
on page 23 that "well maintained UNIX operating systems have this property."
is erroneous, unless "well maintained" means removal/replacement of the BSD
ps command (try "/usr/ucb/ps eaww" on Solaris).

David Wallis

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Monday, June 11, 2001 10:30 AM
To: [email-masked]
Subject: Fwd: script extensibility I-D

Hi -

I'm forwarding this announcement, which may be of interest to
Script MIB implementors.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> From [email-masked] Mon Jun 11 06:00:59 PDT 2001
> Message-Id: <[email-masked]>
> To: IETF-Announce: ;
> From: [email-masked]
> Reply-to: [email-masked]
> Subject: I-D ACTION:draft-schoenw-rfc-2593-update-03.txt
> Date: Mon, 11 Jun 2001 07:07:53 -0400
> 
> --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title		: Script MIB Extensibility Protocol Version 1.1
> 	Author(s)	: J. Schoenwaelder, J. Quittek
> 	Filename	: draft-schoenw-rfc-2593-update-03.txt
> 	Pages		: 25
> 	Date		: 08-Jun-01
> 	
> The IETF Script MIB defines an interface for the delegation of
> management functions based on the Internet management framework. A
> management script is a set of instructions that are executed by a
> language specific runtime system. The Script MIB extensibility
> protocol (SMX) defined in this memo separates language specific
> runtime systems from language independent Script MIB implementations
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-schoenw-rfc-2593-update-03.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-schoenw-rfc-2593-update-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-schoenw-rfc-2593-update-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-schoenw-rfc-2593-update-03.txt
> 
> --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-schoenw-rfc-2593-update-03.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> --OtherAccess--
> 
> --NextPart--
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Jun 2001 17:34:05 +0200

>>>>> Wallis, David writes:

David> The protocol described in the referenced document is insecure
David> in the following details:

David> 1) Scripts passed as ordinary files may be insecure.

David> On pages 3 and 4 it states: The SMX protocol uses a local
David> storage device (usually implemented on top of the local file
David> system) to transfer scripts from the SNMP agent to the runtime
David> systems. The SNMP agent has read and write access to the script
David> storage device while the runtime systems only need read
David> access. The SMX protocol passes the location of a script in the
David> local storage device to the runtime engines. It is then the
David> responsibility of the runtime engines to load the script from
David> the specified location.  A well-known Unix security hole
David> required recoding the kernel in order to securely support
David> setuid scripts because the name of the script was passed to the
David> runtime engine, not a location. In certain cases it was found
David> possible to exploit the situation by causing a filesystem
David> directory to point to a different file than the one rightfully
David> given setuid privilege by the kernel in the small window of
David> time between when the setuid privilege was granted by the
David> kernel and the runtime engine opened the file to execute the
David> script. For those Unix kernels which still support setuid
David> scripts; the kernel now opens the script, makes the runtime
David> engine process setuid, and passes the open filehandle of the
David> script to the runtime engine.

David> I believe the SMX procedure described above may introduce
David> similar problems without careful consideration to avoid
David> them. While the text noted above may be interpreted to avoid
David> the problem by passing an open filehandle to the runtime
David> engine, in the absense of clarification a naive interpretation
David> would be to consider a filename to be a "location of a script
David> in the local storage device" and so would permit insecure
David> implementation.

I am not yet convinced that this is an issue for the SMX protocol.
The directory where the agent stores files only requires read/write
permissions by the agent. The runtime engines and everybody else on
the system does not need write permissions to this directory. How
should someone be able to build an attack in this case? (Note that the
scripts are just ordinary files and there is no setuid stuff involved
here.)

Can you please explain how you think someone can exploit this
mechanism?

David> 2) Environment variables are not access protected.

David> On the bottom of page 5 it states: The security assumption here
David> is that access to the process environment is protected by the
David> operating system.  This assumption is invalid on many (most?)
David> operating systems. The statement on page 23 that "well
David> maintained UNIX operating systems have this property."  is
David> erroneous, unless "well maintained" means removal/replacement
David> of the BSD ps command (try "/usr/ucb/ps eaww" on Solaris).

I have not been aware of this behaviour (which really looks more like
a bug rather than a feature to me). Thanks for raising this issue. We
are looking at this right now and most likely add an alternate
transport for SMX messages which addresses this problem.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jun 2001 17:02:03 +0200

Our current thinking on this problem is to drop the TCP transport
altogether. Instead, we will specify that SMX 1.1 is being run over
POSIX pipes. Runtime engines talk SMX over stdin/stdout and the agent
is responsible to setup appropriate pipes before creating runtime
engines. Runtime engines are not required anymore to connect back to
the agent and hence there is no need anymore to pass cookies around.

/js