Subject: RE: script extensibility I-D

From: "Wallis, David" <[email-masked]>
Date: Wed, 20 Jun 2001 21:57:26 -0500

> Juergen Schoenwaelder writes regarding issue 1:

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 Wallis replies:

I don't think that the original setuid script problem was exploitable if the
file itself and all directories in the hierarchy were properly configured,
but nevertheless, since misconfiguration is so easy, an alert was issued and
the code was changed. (Note that proper configuration depends upon all
levels of the directory hierarchy from the root downward in the given path,
including any detours taken by symbolic links, mount points, etc.)

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

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

> Juergen Schoenwaelder writes regarding issue 2:

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.

> David Wallis replies:

It was an unwelcome feature to me when I came across it as well.
Nevertheless, it apparently is long-standing code from "Bezerkley". But when
you think about it, there never has been any promise of confidentiality in
environment variable data. They are automatically copied from parent to
child, and child creation in Unix is extremely common. A process would have
to explicitly provide an impoverished environment to all its children in
order to keep its environment data even semi-private.

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

>>>>> 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: Thu, 21 Jun 2001 15:22:58 +0200

>> 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