Subject: Fwd: script extensibility I-D

From: Randy Presuhn <[email-masked]>
Date: Mon, 11 Jun 2001 10:29:35 -0700 (PDT)

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: Randy Presuhn <[email-masked]>
Date: Fri, 22 Jun 2001 10:06:38 -0700 (PDT)

Hi -

I'm forwarding a posting from Eamonn McManus.  I've added
the new address to the disman "posters" list.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

Sender: [email-masked]
Date: Fri, 22 Jun 2001 14:58:28 +0200
>From: Eamonn McManus <[email-masked]>
Organization: Sun Microsystems, Grenoble, France
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: ga, fr, en
MIME-Version: 1.0
To: "Wallis, David" <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>, [email-masked]
Subject: Re: script extensibility I-D
References: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA14913

"Wallis, David" wrote:
> The principle is really quite simple. You have a byte stream which you wish
> to be interpreted as a script. You create a file containing that byte
> stream, and then pass the name of the resulting file to the interpreter,
> along with some indication of a security profile you expect to be used.
> Uncontrolled by you (possibly because of filesystem misconfiguration)
> another process changes the filesystem so that the name you give now points
> to another file, one of an intruder's choice. The result is that the
> intruder's script, not yours, will be executed with the profile you
> indicate. If the profile you indicate happens to confer privileges of any
> kind, the intruder has gained access to privileges he/she should not have.
> 
> Admittedly the intruder must be adroit in the timing of his/her filesystem
> change to hit the window of time between when you create the file and when
> the interpreter opens it, and admittedly the intruder must first find a
> filesystem in a state of misconfiguration so that he/she can make a crucial
> change at will, but these conditions are exactly those that were exploited
> in the prior alert relating to setuid scripts.

It seems to me that the Unix exploits on which you base your argument used
symbolic links.  I have not been following SMX closely, but I don't think
there is any equivalent there.  In the absence of links, the security
requirement on Unix is just to say that the scripts must be stored in a
directory that ordinary users cannot write to.  This is so obvious that it
hardly seems necessary to state it.

Éamonn

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 25 Jun 2001 13:59:23 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Wallis, David" <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: [email-masked]
> Subject: RE: script extensibility I-D
> Date: Mon, 25 Jun 2001 14:48:43 -0500
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
...
> insecurities of setuid scripts are discussed. Note that it is you as a
> proposer of a new standard who has the obligation to convince me, a possible
> user of that standard, that you have examined the security implications of
> what you propose and can vouch that the standard is safe. It is not my
> obligation to convince you that it is unsafe.
...

A process note from the WG chair:

    The script MIB extensibility work is NOT standards track.
    Its status is "Experimental".  See RFC 2026 for details.

    Nonetheless, I do believe that this mailing list is
    an appropriate venue for discussion of this work, and
    that discussions like this can be useful.  However,
    there has not been consensus to request that the script
    MIB extensibility work be added it to our charter, even
    though I have taken pains to ensure that the working
    group at large is aware of this work.

    So, remember RFC 1796, and please don't call the script
    MIB extensibility I-Ds or RFC a standard!

Now I have a question as a technical contributor:

    To what extent do these same concerns apply to
    draft-ietf-snmpconf-pm-06.txt?  That document is
    going on the standards track.  Follow-up on the
    snmpconf WG mailing list.

---

From: "Ayers, Mike" <[email-masked]>
Date: Mon, 25 Jun 2001 16:06:26 -0500

> From: Wallis, David [mailto:[email-masked]] 
> 
> >From: Juergen Schoenwaelder [mailto:[email-masked]]:
> >(a) I still do not believe there is an insecurity of storing scripts
> >    in the filesystem.
> 
> In that case, I suggest you contact the Unix security expert 
> of your choice,
> and ask him/her to study the possible security problems in what your
> propose. I only know that it has similarities to the "setuid script"
> problem. See Question 11 at
> http://www.geocities.com/SiliconValley/Bay/9952/alt_sec.txt 
> where the known
> insecurities of setuid scripts are discussed.

	You're pretty vociferous for someone who isn't sure...

> Note that it is you as a

	Wrong.  It is the responsibility of the designer to make a system as
safe, reliable, secure, etc. as possible.  It is the responsibility of the
implementor to verify the safety, reliability, security, etc., in the
implementatation, and the responsibility of the end user to verify these
traits in its end use.  This is not written down somewhere so much as it is
the way things work out.  People often try to use a model where all the
responsibility is in one pair of hands, but such attempts tend to end badly.

	Also, I should point out that by participating here you become part
of the proposing body.  Welcome to the IETF.

	Therefore, if you think that there is a real security hole, please
let us know exactly what it is.  Trepidations carry little technical merit.

> >(b) We did not propose to send the script code over standard input.
> >    I just said the SMX is carried over a POSIX pipe.
> 
> Then may I humbly suggest that you consider the possibility 
> of sending the
> script over standard input to the runtime engine.

	Okay - why?

/|/|ike

---

From: "Wallis, David" <[email-masked]>
Date: Tue, 26 Jun 2001 13:23:56 -0500

>From Juergen Schoenwaelder [mailto:[email-masked]]:
>Sorry, I still do not understand the problem David Wallis has with the
>fact that SMX passes file names around. If you understand it, can you
>please try to paraphrase it so that I can understand it as well?

The problem I have is this: 

1) A filename does not point directly to a file. It is, in fact, a path that
must be followed from the root directory through any number of intermediate
directories, mount points, and symbolic links to an inode that represents
the file.

2) Contrary to appearances, these directories, mount points, and symbolic
links are not static, or at least cannot be depended upon to remain static.
Other processes may or may not have permission to make changes at any level
of the directory hierarchy. Your process has no control over this fact.

3) If you make decisions based upon the assumption that a given file will be
executed (as for example choosing a security profile, or in this case two
security profiles) and then the filesystem structure is changed so that the
filename is now pointing at a different file, you have in fact created a
security hole because the new file will get executed with a security profile
that it should not have. It doesn't matter whether or not the security
profile confers root privilege or not, all that matters is that it grants
some authority that the intruder would not ordinarily have.

I don't know how to say it any more simply than this. Is it that you truly
don't understand, or is it that you can't believe that someone would try to
exploit such an insignificant window of opportunity? The history of Unix is
that just such windows of opportunity were exploited.

David Wallis

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 26 Jun 2001 11:50:56 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>, [email-masked]
> Date: Tue, 26 Jun 2001 13:23:56 -0500
...
...

WG chair: I think we need to tone down the rhetoric just a bit.

Technical contributor:
This argument says that stuff retrieved from file systems
can't be trusted unless one can trust every single node in
the path.  The proposal to ship the script via stdin just
shifts the worry about the integrity of all the nodes in the
path from the execution engines to the "agent".  Those scripts
eventually reside on some file system somewhere.  Whether it's
the "agent" reading them or the execution engines doesn't
really change the problem.

If the agent sends a path, it should only send paths it trusts.
If the agent ships a file image, it should only send images of
files it has retrieved using paths it trusts.

Seems like six of one, half-dozen of the other.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 26 Jun 2001 13:02:14 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Date: Tue, 26 Jun 2001 14:59:31 -0500
> 
> The important point is that the file must be identified by location or
> content, not just by name *before* making decisions as to the security
> profile it should enjoy. The agent can store the script somewhere in the
> filesystem if necessary, but it needs to record not just the name of the
> temporary file, but the inode as well. Then when it goes to pass the file to
> the runtime engine, it should pass the open filehandle or the actual bytes
> of the file (via stdin) to the runtime engine. (Presumably, if the inode
> doesn't match, the agent will refuse to pass it to the runtime engine,
> because it's not the same file the agent stored.)
...

"temporary file"???

I sense a serious disconnect...

---

From: "Wallis, David" <[email-masked]>
Date: Tue, 26 Jun 2001 18:52:27 -0500

I'm sorry--I hate to come into the middle of a conversation like this. But
the draft doesn't make clear that one of the capabilities to be provided is
to store scripts on a distributed manager for future execution. (I suggest
adding it to the list in 3. Overview.)

-----Original Message-----
"temporary file"???

>From: Randy Presuhn [mailto:[email-masked]]

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 26 Jun 2001 18:03:33 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 26 Jun 2001 18:52:27 -0500
> 

That part of the puzzle is in RFC 2592, whose update is in
the queue as <draft-ietf-disman-script-mib-v2-03.txt>

The SMX work is part of one possible implementation strategy
for RFC 2592.  (That's one of the reasons why its experimental
- there's been no drive to agree on a single standardized
implementation approach for 2592.)

Note that any questions of relying on file names also apply
there, where things may be passed around by URL references.
The working assumption has been that if someone tells a
script MIB implementation to execute a script that is to be
retrieved using a particular URL, then they have some level
of confidence that what that URL references is what they
intend it to reference.  If someone tells their script MIB
implementation to retrieve scripts from an untrusted source or
using an untrusted protocol, they'll get what they deserve.
The last paragraph in RFC 2592's Security Considerations
section raises this point.

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 27 Jun 2001 13:20:13 -0700 (PDT)

Hi -

I'm forwarding a non-subscriber posting to the disman WG
mailing list.  Subscription instructions are available at
http://www.ietf.org/html.charters/disman-charter.html

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA21051
> 	for <[email-masked]>; Wed, 27 Jun 2001 12:25:32 -0700 (PDT)
> Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f5RJQ6n26801
> 	for <[email-masked]>; Wed, 27 Jun 2001 14:26:06 -0500 (CDT)
> Received: from patan.sun.com (unknown [192.18.98.43])
> 	by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 035D220EFC4
> 	for <[email-masked]>; Wed, 27 Jun 2001 19:22:46 -0500 (CDT)
> Received: from phys-ha2mtva.Eng.Sun.COM ([129.144.1.3])
> 	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28261;
> 	Wed, 27 Jun 2001 13:26:36 -0600 (MDT)
> Received: from pluto (pluto [129.144.143.180])
> 	by phys-ha2mtva.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id MAA10005;
> 	Wed, 27 Jun 2001 12:26:37 -0700 (PDT)
> Message-Id: <[email-masked]>
> Date: Wed, 27 Jun 2001 12:22:11 -0700 (PDT)
> From: "S.R. Venkatramanan" <[email-masked]>
> Reply-To: "S.R. Venkatramanan" <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> MIME-Version: 1.0
> Content-Type: TEXT/plain; charset=us-ascii
> Content-MD5: 12cf2CM9/uSUKSzEaYZmJQ==
> X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
> 
> 
> Hi,
> 
> I have been a passive oberver of this discussion for some time now.
> Having written security guidelines for SunTone, a certification
> program by Sun for ASP hosted applications here is my observation
> for whatever it is worth.
> 
> Considering the two scenerios i.e, 1) to send t he script over the
> wire in clear as stdin and 2) depositing it on the remote and let
> the engine pick it up at run time, I would agree with Frank and
> argue in favor of latter, with reliability and availabilty also
> taken into consideration.
> 
> The remote host being a trusted one, you also trust on its
> administration environment.  Whereas, when it is sent over
> stdin, who gurantees against the corruption by the network?
> What if it is intercepted by some other untrusted administrator
> (read, hacker) before it reached the engine.  Of course, you
> can argue how did the script land on the remote machine in the
> first place in the other scenerio. I would imagine that
> checksumming or something similar is done to confirm data
> integrity, to counter that.  So, not being able to trust
> the operating environment (file system and the administrator)
> cannot be the reason for not deopositing script on the remote
> host prior to runtime.
> 
> The best thing would then be a mechanism where you encript
> the script, whether sent to engine at run time or at the time
> of depositing it on the remote host, and have the key exchanged.
> This scheme is not overly complex either.
> 
> Of course, we all know that you ahve to consider the cost of
> security over what is the value of content that is being secured.
> 
> rgds,
> S.R.
> 
> S.R. Venkatramanan
> [email-masked]
> Senior Staff Engineer
> Systems Software Group
> Sun Microsystems, Inc.
> 
> 
> > From: Frank Strauss <[email-masked]>
> > Date: 27 Jun 2001 12:44:19 +0200
> >
> > Hi!
> > 
> > >> You are saying that there is a possibilty that some third foreign
> > >> process could intervene by modifying the script file or its file
> > >> system meta data after it was put in the file system by the agent and
> > >> before the runtime engine opens it. Is this correct?
> > >> If yes, let me argue why I think this is not true: As almost any
> > >> program on a UNIX system the agent and the runtime system rely on the
> > >> file access permission attributes that are supported by the file
> > >> system. Of course, the directory where the scripts are stored for
> > >> passing them to the runtime system and all parent directories have to
> > 
> > 
> > Heiko> What about the following scenario:
> > 
> > Heiko> 1) agent writes the file
> > Heiko> 2) root unmounts the disk where the file is on
> > Heiko> 3) the runtime opens a file that was hidden by the mountpoint, with a
> > Heiko> totally different content
> > 
> > Heiko> Here, all permissions are ok and still the result is not as desired.
> > 
> > The superuser has always permissions to do things that cause a
> > behaviour that is not expected by others. That's life. I don't regard
> > things that the superuser does as an attack or their consequences as a
> > security problem.
> > 
> >  -frank
> 
> _______________________________________________________
> 
> "We learn from experience that men never learn anything
> from experience." - George Bernard Shaw
> 
> 
>

---

From: Frank Strauss <[email-masked]>
Date: 28 Jun 2001 09:55:24 +0200

Hi!

Note that there is no wire, no remote, no network. The problem is
as simple as starting a child process on the _local_ host and making
it read and execute a given script.

So, your argumentation is out of scope. ;-)

 -frank

---

From: "Wallis, David" <[email-masked]>
Date: Fri, 29 Jun 2001 20:26:10 -0500

>the queue as <draft-ietf-disman-script-mib-v2-03.txt>

I didn't find such a draft. But I did find
http://www.ietf.org/rfc/rfc2592.txt
which answers some questions, but generates some as well.

1) I notice that the principal updating smLaunchStart is not required to be
the same as smLaunchOwner. Assuming this is deliberate, in effect all
scripts are run setuid as smLaunchOwner. I.e. they run with the security
profile associated not with the person that pushed the launch button, but
the person who defined the launch button. This seems undesirable in that it
is unexpected behavior.

2) The principal performing the set operation (on smLaunchStart) must have
read access to the script. This too seems undesirable. In a production
environment there are many vendors who would desire if at all possible that
their scripts be stored such that they may be executed but not read. This
coupling of execute access with read privilege means that snmp does not
support such a concept as execute-only scripts. 

3) The implementation is made further awkward in that all columnar objects
in the smScriptTable (except `not-accessible') must be checked for read
access rather than having a single column serve as a surrogate for the
entire row, or having a row-oriented operation.

4) "A compliant implementation does not have to support script suspension
and the smRunState `suspended'. Such an implementation will change into the
`suspending' state when the smRunControl is set to `suspend' and remain in
this state until smRunControl is set to `resume' or the script terminates."
This is bad design because you get the same response whether suspend is
supported or not, therefore you don't know whether the `suspending' state
actually means that a suspension is imminent or it is not imminent. It would
seem better design to require that an implementation not supporting suspend
should say so with an appropriate error code in response to the suspend
command.

5) In section 5.3 there is an apparent typo in "The Script MIB
implementation reloads the modified script code once the smScriptOperStatus
changes to `enabled' again." I believe it should reload in response to
smScriptAdminStatus being set, not smScriptOperStatus which should be set
once the reload is complete.

6) The design decouples the ownership of a script from the principal under
whos security profile it will execute, as well as the one actually
requesting this particular run. Is this really desirable? How can effective
control over the use of your security profile be maintained when you are not
in control of either the script to be executed or the timing of the
execution? There are no controls that say, for example, if the script
changes then the launch button is invalidated, or the launch button is valid
for a limited time period only, and then expires.

7) There is also the interesting problem of what to do when the principal
who updates a script is not the one who originally created it. Because of
the requirement that managers be able to name their scripts without clashes,
the owner is made a qualifier of the name. Thus, when ownership changes
hands, all script names change, and all launch buttons must be updated. If a
team of sysadmins all need to make changes to a large body of scripts as a
joint effort, this becomes a nightmare.

David Wallis