On Wed, Aug 01, 2001 at 07:14:07PM +0200, Ismael Briones wrote: > Probed in Oracle 8.1.5. > Oracle 8.1.6 is not vulnerable > SOLUTION: > Maybe a chmod -s Here's what I found on my servers (note, I'm not a DBA): -rwxr-xr-x 1 oracle dba 1586992 Jun 23 2000 ./8.0.6/bin/dbsnmp -rwsr-sr-x 1 root oinstall 1384992 May 12 2000 ./8.1.5/bin/dbsnmp -rwsr-s--- 1 root oinstall 1432800 Feb 2 16:33 ./8.1.6/bin/dbsnmp -rwsr-s--- 1 root system 11907760 Jul 13 17:20 ./8.1.7/bin/dbsnmp So judging by the 8.1.6 and later versions, world doesn't need access. Looking at the Oracle docs I have available, it looks like the listener (running as user "oracle") would be the one to actually call dbsnmp to run. The Oracle docs go on and say that to check whether or not the dbsnmp agent is running, login as oracle on the appropriate server, and run the following: ##### $ <path to oracle bin>/lsnrctl LSNRCTL for Solaris: Version 8.1.5.0.0 - Production on 01-AUG-01 15:46:30 (c) Copyright 1998 Oracle Corporation. All rights reserved. Welcome to LSNRCTL, type "help" for information. LSNRCTL> dbsnmp_status The db subagent is not started. ##### I would say that if you're not running it, go ahead and change the perms to remove the setuid/setgid bits, or uninstall it completely if possible. If the agent is being used, change the permissions so that only user "oracle" can execute the binary. A quick search on Google brought up a bunch of dbsnmp-related compromises from 1999. Those seem to be related to implicitly trusting ORACLE_HOME and various other environment variables. The following URL has a workaround for dbsnmp which may help. (again, I'm not a DBA) http://xforce.iss.net/alerts/advise36.php -- Randomly Generated Tagline: "Cloning and the reprogramming of DNA is the first serious step in becoming one with God." - Scientist G. Richard Seed
