[15248] in bugtraq
Re: [ Hackerslab bug_paper ] HP-UX SNMP daemon vulnerability
daemon@ATHENA.MIT.EDU (Chris Calabrese)
Thu Jun 8 13:43:00 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000608131659.21665.qmail@web205.mail.yahoo.com>
Date: Thu, 8 Jun 2000 06:16:59 -0700
Reply-To: Chris Calabrese <chris_calabrese@YAHOO.COM>
From: Chris Calabrese <chris_calabrese@YAHOO.COM>
X-To: loveyou@HACKERSLAB.ORG
To: BUGTRAQ@SECURITYFOCUS.COM
> 1. The creation of temporary file of SNMP daemon
As far as I can tell, the worst thing you can do
with this is modify the log entries.
Not a good thing, but not like you can become
root or anything. Of course, even if the file
permissions problem were fixed, I'm guessing
the thing would still follow sym-links, re-use
existing files owned by other users, etc.
The right thing to do is log to syslog and not
use a file in /tmp.
> 2. The permission for the set-up file of SNMP daemon
Actually, there's an HP patch for this
problem already. The trouble is that they
never put out a security advisory, so very
few people know about it. (I even searched
on their web page in case I had missed
it some how).
The base patches are PHSS_20543 (10.20)
and PHSS_20544 (11.00).
They're also in the OV EMANATE14.2
Agent Consolidated Patch (HP speak for
an snmpd jumbo patch) PHSS_20543 (10.20)
and PHSS_21046 (11.00)
The patch doesn't actually chmod
the file, so you still need to do a
chmod 700 /etc/SnmpAgent.d/snmpd.conf
after you install it.
And...the file still gets recreated on
startup, so if you're running Tripwire
you'll see the file inode, mtime, and ctime
change and the directory mtime change.
You can handle it with something like this:
/etc/SnmpAgent.d R-imc
--
chris_calabrese@yahoo.com
__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
