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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]