RE: DB2UDB hack

From: Patrick Botz

Just like ODBC or FTP or whatever, user profiles exposed to the outside
world (which I consider PASE to be) should be strictly limited.

No, Not just like ODBC or FTP, because these run in native i5/OS and for
the most part are written in PLMI, not C code. PLMI manages string-length
implicitly, unlike C.

What does that have to do with whether or not profiles should be limited? I
don't care what they're written in... you give FTP access to somebody with
an uber-profile and you're screwed. I don't get it, Patrick.

The point is that parts of i5/OS ITSELF rusn in PASE. You don't get a
choice for the parts of the OS that run in PASE.

True, but you do get a choice for some things. For example, if you're
running some vendor tool in PASE, you ought to be able to control the user
profile.

I understand your point on i5/OS pieces. But let's get specific. Let's
take DNS. Does the DNS server implicitly run with *ALLOBJ authority? What
profile does DNS run under? If DNS opens up my machine to AIX exploits, AND
I have no way to control its access, then that's a really good argument not
to use DNS on my System i.

It's also a huge hole in the DNS implementation, and one which needs to be
plugged.

First, the issue doesn't go away, it is just a matter of how large the
issue is.

Your claim that the entire system is vulnerable GOES AWAY if the user
profile is limited to only those objects it needs.

I am not saying there aren't vulnerabilities, but when you start snarping
about that the entire system is vulnerable, you're removing focus from the
important bit, which is that properly applied object security on i5/OS
removes nearly all vulnerabilities.

Now, I don't want to get into an argument about whether systems
SHOULD be managed this way, I'm just stating a fact.

That's the point. If you use i5/OS security properly, your i5/OS data is
secure even from hacker exploits, unlike Windows systems where the hacker
can raise their security level.

And even if the system was managed
the way it needs to be, the data which is accessible by the userID is
still at risk.

Yes it is. So make sure the data accessible is limited to only that
necessary.

In any case, your statements immediately above are still roof that your
original statement "buffer overflows cannot happen on i5/OS" is too broad
and (arguably too dangerous) too much of a generalization.

It is not.

i5/OS has no buffer overflows.

AIX has holes. PASE inherits them. Don't use PASE unless you understand
what it's doing to your security. Now, IBM ought to be very clear on what
parts of i5/OS use PASE under the covers, and as far as I know those are
still very limited.

If it continues down that road, then we need to know.

Telling
people there is nothing to worry about is the wrong message. Telling
people they are horribly exposed is also the wrong message.

This started with DB2 UDB. I contend that my original assertion still
stands: DB2 buffer overruns are not an issue on i5/OS. Bitch all you want,
that's the case. I also contend that your arm waving about how an unsecured
machine is ... well, unsecured ... is dangerous because it removes focus
from the real point: PASE is dangerous.

The bottom line, there is something to be aware of and to account for with
respect to buffer overflow attacks.

Not on DB2, and not in i5/OS. Only in PASE, and so you better damned well
know what you're running in PASE.

You've made a clear and compelling argument that PASE opens the machine up.
Thank you for that.

Joe