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

["James Shanks" <jshanks@us.ibm.com>]

Todd -

I'd be very surprised if this worked.  The EXEC causes trapd to pass the command and the trap over to ovactiond.  There is code in ovactiond (and in nvcorrd for user exits, and in actionsvr for actions from rulesets) to read the AdditionalLegalTrapVariables and allow them, but replace all the other non-alphanumerics with underscores.  Then when the substitution is complete, ovactiond forks the process.  See what I am saying?  I think your variables will be altered before the su takes place.  

Before you tell me how unhappy you are with the way the fix works, let me tell you that I am no more happy, but because there was a CERT warning issued about this, that meant that the IBM corporate security folks got a say in the design, and they ordered that the variables be altered before any command was issued to prevent any way around the fix.  Note that if they are wrong, and you do find one, I would advise you to keep it to yourself, because otherwise we will be ordered to plug it.     

 I see no alternative to either disabling it or changing your scripts.   Have you tried using the sed mechanism suggested in the notes that went out with the patch (and incorporated into the Release Notes for 6.0.3 and 7.1)?   You will have to eventually because this is how the product now works.  It used to be easy to write  a script to launch from a trap or a ruleset.  Now it is rather hard unless you are good at string manipulation.

Perhaps I can better explain the sample code we put in the notes.  If you were using $2 (the hostname) in a NetView trap in a line in script like this:
        $2 is down
and now this comes out as
        myhost\.mynet\.mydomain.\com (e.g. jshanks\.raleigh\.tivoli\.com)
where there are three escapes to worry about, then you could do this in the script first:
        host=`echo $2 |  sed -n "s:\\\\\\::gp `    (those are backticks around that command so that it executes)
and change the line you had before to
        $host is down

This should remove all the escapes from the varbind.  Notice how it works?  For every escape in your input, your sed needs a pair of them after the "s :"

Sorry but that is the best I can offer you.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group

netview@toddh.net (Todd H.) Sent by: tdh@k2.onsight.com 01/25/2002 11:18 AM

To:        nv-l@lists.tivoli.com         cc:                 Subject:        [nv-l] [NV-L] security, trap data, and external scripts

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/

---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)