Subject: RE: script extensibility I-D

From: "Wallis, David" <[email-masked]>
Date: Thu, 21 Jun 2001 11:52:00 -0500

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.

Presumably, even if these scripts are not envisioned to run in a root
environment, they are still envisioned to do something significant from a
system management perspective (else why write this RFC?), and therefore are
envisioned to have some level of privilege beyond "nobody". But whether
envisioned or not, the RFC allows this use by what it leaves unspecified. 

The level of privilege need not necessarily be "root" in order to be
dangerous. It is sufficient merely to gain access to a user account that an
intruder would not normally have access to. Particularly in modern systems
which support auditing of administrative actions, individual user accounts
now have privileges that might have been restricted to "root" in the past,
or even the ability to switch to the "root" security profile is restricted
to individual user accounts.

David Wallis

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 6:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: script extensibility I-D

>>>>> Wallis, David writes:

>> David Wallis replies:

Davis> The principle that must be adhered to is that no decision as to
Davis> the privilege level a script should run at should be made until
Davis> the file is physically open (i.e. the physical location within
Davis> the filesystem has been identified) and there is no chance of a
Davis> substitution being made by an outside process.

Davis> As I read the proposal, two security profiles will specify what
Davis> the script is allowed to do, one of which is at the operating
Davis> system level. Since the proposal does not specify limitations
Davis> on the privileges the operating system profile may confer,
Davis> setuid root is possible. The proposal also explicitly leaves
Davis> unspecified the way that security profiles are selected; merely
Davis> suggesting that smLaunchOwner might be used as a key. Given
Davis> this undefinition, anything is possible.

The script files have no special rights associated with them. They do
not have any setuid bits. The script files are just plain input data
which is loaded into runtime engines (Java, Tcl, ...) for execution.
These files exists in a part of the file system which only allows the
script MIB agent to write these files.

The operating system profile defines the rights under which the
runtime engine is executing which will later read and execute the
script. So you can define an operating system profile which executes a
runtime in a chroot() environment under a special unprivileged account
if you will. The runtime security profiles define the runtime security
checks made by the runtime engine, which allows for fine-grained
control of what a script is allowed to do at runtime (e.g. you can
send SNMP messages only to a restricted set of IP addresses). The
runtime security profiles parameterize the security portion of the
runtime engines and they are not associated with the file which
contains the script to be executed.

I still fail to understand the problem. It would be useful for me to
have a clear description how someone can exploit the fact that file
names are passed in the SMX protocol.

/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 11:56:04 +0200

>>>>> Wallis, David writes:

David> The principle is really quite simple. You have a byte stream
David> which you wish to be interpreted as a script. You create a file
David> containing that byte stream, and then pass the name of the
David> resulting file to the interpreter, along with some indication
David> of a security profile you expect to be used.  Uncontrolled by
David> you (possibly because of filesystem misconfiguration) another
David> process changes the filesystem so that the name you give now
David> points to another file, one of an intruder's choice. The result
David> is that the intruder's script, not yours, will be executed with
David> the profile you indicate. If the profile you indicate happens
David> to confer privileges of any kind, the intruder has gained
David> access to privileges he/she should not have.

So it all boils down to protecting the script files from 
unauthorized access, right? Would the following addition 
to the security considerations section make you happy?

+The SMX protocol assumes a local script storage area which is used to
+pass script code from the SNMP agent to the runtime systems. The SMX
+protocol passes file names from the agent to the runtime engines. It
+is necessary that the script files in the local script storage area
+are properly protected so that only the SNMP agent has write access.
+Failure to properly protect write access to the local script storage
+area can allow attackers to execute arbitrary code in runtime systems
+that might have special privileges.

/js