RE: DB2UDB hack

Joe,

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.

Can you imagine any situation where you would want to have a PASE

program

running with *ALLOBJ authority? I'm not being argumentative, I'm simply
saying that anything running inside of PASE should follow stringent
authority rules, and should only have access to the minimum objects it

needs

to do its job.

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.

But again, this is only an issue if the PASE profile has too much

authority.

If the PASE profile is limited to a specific IFS folder, then that issue
goes away.

First, the issue doesn't go away, it is just a matter of how large the
issue is. How big thie issue is depends on the sensitivity of the data
that can be accessed by the userID under which the attacked application is
running. Given the way most i5/OS machines are managed (e.g. with PUBLIC
*ALL or *CHANGE, or *USE), this puts all of the data at risk. Now, I
don't want to get into an argument about whether systems SHOULD be managed
this way, I'm just stating a fact. 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.

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. Telling
people there is nothing to worry about is the wrong message. Telling
people they are horribly exposed is also the wrong message.

You can avoid many potential security issues on any platform by avoiding
running with too much authority. This applies equally to *nix and Windows
environments as it does to i5/OS.

The bottom line, there is something to be aware of and to account for with
respect to buffer overflow attacks. Most will not have any consequences
for i5/OS systems. Some will and HAVE had consequences in the past (the
DNS server BIND 8 is the most readily avilable example I have).

Thanks.

Patrick Botz
IBM STG Lab Services Security Practice
botz@xxxxxxxxxx
work: 507 253 0917 mobile: 507 250 5644
http://www.ibm.com/systems/services/labservices