RE: DB2UDB hack

Whenever you see the terms mentioned above (and/or "remote code

execution")

you can be assured that it's yet another LUW-only exploit, and that

i5/OS as

usual is completely safe (and thus needs no fixes).

This is mostly true, but not universally true. Anything that runs in the
PASE environment under i5/OS is susceptible to a buffer overflow attack
just like a standard LUW. So you can't just assume that no matter what it
is, it won't affect i5/OS.

For example, the DNS server on i5/OS runs in PASE. If you see a buffer
overflow vulnerability for the version of the DNS server supported by
i5/OS AND you see that AIX has the same vulnerability, then you need to
update the same AIX binary in PASE on i5/OS. I believe Rochester will make
a PTF for i5/OS customers so they don't have to get the AIX fix and figure
out what to change on i5/OS side of the house.

Another example is PHP. The PHP engine runs in PASE. Buffer overflow
attacks against the engine itself (rather than security issues with poorly
written PHP scripts) would also be something that you would want to fix on
i5/OS.

Any 3rd party applications that run in PASE would also be candidates to
patch for buffer overflow attach type fixes.

The good news is that most of the OS still runs in native i5/OS mode.


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

midrange-l-bounces@xxxxxxxxxxxx wrote on 10/18/2007 11:35:34 AM:

From: rob@xxxxxxxxx

This link points to a hack for DB2 UDB on Unix, Linux and Windows.

Hey,

if it was only Windows I would leave it at that, but is there a

matching

apar for i5/os?
http://www-1.ibm.com/support/docview.wss?uid=swg1IY97750

Can't happen on i5/OS. The key words are "specially crafted" and "stack
overflow" which signify a standard LUW (Linux/Unix/Windows) exploit of
sending your own code in a data buffer and then tricking the server into
executing it. In order to accomplish this, you have to be able to set

the

program execution pointer to a data space, and that basically isn't

possible

in i5/OS.

Whenever you see the terms mentioned above (and/or "remote code

execution")

you can be assured that it's yet another LUW-only exploit, and that

i5/OS as

usual is completely safe (and thus needs no fixes).

Joe