RE: DB2UDB hack

[Patrick Botz <botz@xxxxxxxxxx>]

> 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