Re: exec STATSPACK.SNAP renders ORA-03113

Rick Denoire <100.17706_at_germanynet.de> wrote in message news:<osflqvslti39nfk60rnfq44jlq0eacv7t0_at_4ax.com>...
> drak0nian_at_yahoo.com (Paul Drake) wrote:
>
>
> >Rick,
> >
> >spend a little time here:
> >
> >http://otn.oracle.com/deploy/security/alerts.htm
> >
> >and then read some more over on metalink.
> >
> >There is absolutely no excuse for running unpatched software, even on
> >your laptop.
>
> You don't need to convince me about applying patchsets. But your
> arguments ignore plain reality:
> - No platform to test applying the patchset. Last time I did so I was
> surprised that it failed because some option was not installed which
> never installs by default.
> - No way to explain bosses the benefit of this actions (they have no
> benefit, although lack of their implementations has potential
> disadvantages) so it is seen as waste of time.
> - After all, we are not on the Internet. Best solutions are always a
> compromise, and too much effort on security is not adequate to the
> situation.
> - Priorities: People demanding things to be done immediately, while
> applying patchsets can always be postponed - so it never takes place.
> - Applying patchsets as often as they appear is not feasible. Can you
> afford to go out of service every two weeks, apart from doint it due
> to other reasons?
>
> >If you were to file an iTAR, what do you think that the odds would be
> >that the support analyst would not recommend applying the most recent
> >patchset?
>
> It is my every day experience, that support personal from companies
> always try to AVOID spending their time with your issue in the first
> place. They demand to have the last patch installed because it is
> highly improbable that anyone is up-to-date and so they have an
> excellent excuse not to try to help you. Dealing with Hotline cases,
> TARs etc. is UTTERLY time consuming (which is why we hired a guy four
> weeks ago only to do this, related to a big misbehaving tape library).
>
> And it almost always turns out that the patch won't help at all.
>
> >how funny would it be to find out that statspack had nothing to do
> >with it, but someone running loadphp with a long username wash
> >crashing your instance?
>
> You won't believe how serious I am about security. We are planing to
> go public with a database and I am supposed to compile appropriate
> recomendations. My recommendation will be: Don't do it. We can't
> afford the time and effort to take care of security issues. Plain and
> simple.
>
> Exciting statements, yours are.
>
> Rick Denoire
> (2 years experience as Firewall Administrator / Checkpoint One)

Rick,

I've hit issues in testing patchsets (on test systems) whereby we could not roll them out into production (cursor_sharing=FORCE in 8.1.7.4.11 threw lots of ORA-600s). You're probably better off not applying the patchsets than to just apply them without testing. Tough to say.

Pete's book is well worth the read, I'd highly recommend it. Then again, he recommends testing out configuration changes prior to applying them to production, so it might be a waste of your time.

regarding the cost of not applying patchsets, mention the SQL Slammer worm. I'll bet that still sticks in your manager's minds. All it would take is one such vulnerability with an exploit in the wild for damagement (and the world) to realize the cost of not properly maintaining Oracle Servers. All of those downloads from otn, for users that don't have metalink accounts and can't get patchsets - would provide for lots of hosts for spreading such an attack.

good luck with the go-live.

hope you have a firewall outside of the app/web server, and one between the app/web server and the oracle server. the 8.1.7.0.x oracle.exe and tnslsnr.exe processes are vulnerable to multiple attacks.

Paul Received on Sat Nov 08 2003 - 00:09:51 CST