Internet Article on Security Hole in OBIEE

[Mark Rittman]

See here : http://everythingoracle.com/obieeesla.htm

From the introduction : "In this article we’ll discuss a major
security loophole in OBIEE, one that Oracle is aware of, but which it
has done next to nothing to publicise. The upshot is a lack of
awareness of this issue amongst OBIEE project managers, with the
consequence that many production implementations of OBIEE are open to
abuse. "

A couple of questions:

(1) Were other people aware of this? I think internally we had noticed
it and separately contacted Oracle to let them know, I don't know the
outcome of this though
(2) Do people think it's a major issue?
(3) What mitigation have other people taken (or plan to take)?

[Christian]

ad (1) Yes, very much so. I mean (implicitly) you could throw the
EVALUATE in with the direct database requests which aren't necessarily
secure either. Granted, there's some more warning there and you can
control it more precisely by activating and deactivating functions in
the connection pools you expose for direct DB requests.

ad (2) I think there's two extremes. On the one side there are a lot
of projects which have this chalice pass by them thanks to blissful
ignorance. On the other side there's the projects where pretty eager
hacks are concentrated and the EVALUATE is used to make OBIEE do the
impossible.

In the long run the first category is the really endangered one. More
and more SRs appear on MOS and questions on OTN which are answered
with hints including EVALUATE. Unfortunately the implications are not
explained in 99.8% of the cases. A lot of people jump on it as the
McGyver/swiss-army-knife/duct-tape (choose one depending on your
age ;-)) function since they feel comfortable with it - hey, it's
coding; yay!

And since it's a rather geeky thing it won't pop up on the radars of
most responsible managers (speaking from own experience, but please do
contradict me on that), hence no guidelines, no control in pre-
deployment reviews etc.

ad (3) Ask Oracle for a privilege controlling this. Must be a two-
pronged attack though: Answers and RPD so we still retain the
flexibility. Apart from that I tend not to tell (fresh) people about
it unless I'm have made sure they understand exactly what I'm handing
them there - with all its implications.

One special case I'd like to mention for (3) especially is working
with MDX sources. I have yet to see a single initiative that didn't
use EVALUATE; simply because quite some functionality is unavailable
in the 10g releases and some requirements just can't be met without
it. More on that in the other thread.

Cheers!

[chet justice]

1.  Didn't know about it.  It's funny though, I was just using it for something else (see Christian's #3)
2.  Absolutely it's a major issue, but that's mitigated, possibly, that not everyone is out there knows how to "Hack the Gibson"
3.  None yet.

Not sure how to go about limiting it's use.  I think Christian's idea of creating a role or some other mechanism is a good one.  Ultimately, how do you know it's being used responsibly though?  You can't.  Comes down to trust mostly. 

Currently I have EXECUTE ANY PROCEDURE in the development environment as part of my default privileges in the database...but I'm not going to do anything with it.  I've learned that lesson once before.

I would like this hole as similar to having said privilege.  Bad, very bad.

chet

[Stewart Bryson]

Just properly manage database permissions, and this loophole is not
much of a threat. Make sure that OBIEE is not logging in as the schema
owner, and then make sure that the privileges of whatever account
OBIEE is using are minimal.

On Mar 12, 1:51 pm, chet justice <chet.just...@gmail.com> wrote:
> 1.  Didn't know about it.  It's funny though, I was just using it for
> something else (see Christian's #3)
> 2.  Absolutely it's a major issue, but that's mitigated, possibly, that not
> everyone is out there knows how to "Hack the Gibson"
> 3.  None yet.
>
> Not sure how to go about limiting it's use.  I think Christian's idea of
> creating a role or some other mechanism is a good one.  Ultimately, how do
> you know it's being used responsibly though?  You can't.  Comes down to
> trust mostly.
>
> Currently I have EXECUTE ANY PROCEDURE in the development environment as
> part of my default privileges in the database...but I'm not going to do
> anything with it.  I've learned that lesson once before.
>
> I would like this hole as similar to having said privilege.  Bad, very bad.
>
> chet
>