nv-l
[Top] [All Lists]

[nv-l] [NV-L] security, trap data, and external scripts

To: nv-l@lists.tivoli.com
Subject: [nv-l] [NV-L] security, trap data, and external scripts
From: netview@toddh.net (Todd H.)
Date: 25 Jan 2002 10:18:49 -0600
Is anyone using an "su" to a "safe" userid when running a Command For
Automatic Action from trapd?  Might it work?  For example, instead of
an automatic action being in trapd.conf directly:

    ENTERPRISE6 {1.3.6.1.4.1} 6 0 ? 1 0 "Status Events"
    Enterprise specific trap ($S) from $E: args($#):\n$*\n community:$C 
enterprise:$e\n AgentAddr:$A generic-trap:$G time:$T
    SDESC
    EDESC
    Vendor_Process_Status {1.3.6.1.4.1} 6 2 A 3 0 "Status Events"
    Device at $A reports $1 
    EXEC send_tec_event.ksh 'Process_Status trap' $E $G $S $2 'FATAL'
    EVENT_CLASS Nvserverd_Event
    BEGIN_SLOT_MAPPING
    .....

what if this were changed to be...
    EXEC su A_BENIGN_USERID  send_tec_event.ksh 'Process_Status trap' $E $G $S 
$2 'FATAL'


What I don't know is whether you could craft the permissions of such a
userid to let it run postemsg and fork ksh, yet not allow shell
escapes embeded in varbind $2 from leading to execution programs other
than postemsg, or awk. 


In NV 6.02 for Unix there is a security efix that closes the
vulerability in which a malicious user could embed shell
metacharacters and commands into trap varbinds that may be passed to a
script via trapd's Command For Automatic Action.  By default, this
efix will prepend a backslash (\) in front of the period (.)
character, and replaces all other non-alphanumeric characters with an
underscore (_).  You can specify other characters to be backslashed
instead of replaced with the AdditionalLegalTrapCharacters global
environment variable.

The problem is, this security fix breaks a couple of scripts in my
environment in ways that I can't work around without having the vendor
completely overhaul their trap format.  I'd like to avoid this if
possible. 

I can work around the problem for these traps by adding a large number
of characters to the AdditionalLegalTrapCharacters, but that
essentially "undoes" the security fix. Hence my search for a way to
gain back some security in the event we need some of these
metacharacters in our legitimate trap data for delimiting purposes.
For example, one trap sent by a given vendor embeds a few items into a
single varbind, and each of these items is delimited by the pipe (|)
character--a character that in a shell-escaped context can be used to
execute another command.

Sorry for the long post, but it's a tough one to explain...  :-)

Thanks in advance for any insight or advice! 

Best Regards, 
-- 
Todd H.
http://www.toddh.net/

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web