× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Anybody else feel like they need to take a shower after reading this thread?


------------------------------

message: 6
date: Thu, 25 Oct 2007 08:16:08 -0500
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: DB2UDB hack

From: rob@xxxxxxxxx

Hey Joe. First you try to limit the term "hack" by restricting it to
buffer overruns in an attempt to prove that a, properly secured, iSeries
is immune to hacks.

Hey Rob. I'm going to go on the assumption that you can't read, although if
this thread continues, I'll simply assume that you're yanking my chain on
purpose.

My initial comment, the one that started all this ruckus, was that DB2 on
the System i is immune to any exploits on DB2 LUW. Please go back in the
lists, find that post, read it.

Decide whether it's true or not. If you can find anything not true about
the statement, please post here.


Then when someone figures out how to do that, you restrict it to anyone
not running something in PASE.

My next comment was that i5/OS is (practically) invulnerable to buffer
overrun exploits. This is because, unlike most machines, it's not easy to
convince i5/OS to execute an arbitrary part of memory as code. With normal
architectures, program code and data code are no different, and thus a
buffer overrun can effectively overwrite program space.

Can't be done on i5/OS, at least not so easily. However, PASE is an
emulation environment that emulates a standard architecture, and as such is
vulnerable to the same exploits. That's why it's a bad idea to run anything
that requires PASE without knowing its vulnerabilities.

Anyway, once again read the post. If you can find anything not true about
the statement, please post here.


You also combine that by limiting out people like Leif Svalgaard.

Finally, I stated the obvious truth that no system is unhackable, but that
to hack native i5/OS would require not a script kiddie or public knowledge,
but someone with BOTH the skill of Leif Svalgaard AND the internal knowledge
of i5/OS systems, not to mention the knowledge of a specific bug. In this
case, the bug would be the incredibly bad programming that would allow a
buffer exploit in the first place.

Make no mistake: only a third-rate programmer would write code that was
vulnerable to a buffer overrun. You know how long your buffer is, you know
how many bytes you've put into it. So you've either not checked the number
of bytes, or you've incorrectly told another API the wrong size for your
buffer.

Unlike the folks at Redmond, who seem incapable of this basic level of
programming, it's rare to see bugs of this type out of the i5/OS developers.


What's next, if some recent PIE grad figures out how to do it in RPGLE or
C then you're going to restrict it to RPG II?

This sort of hyperbole wastes everyone's time, Rob. In the first place, an
exploit by definition isn't a program that somebody wrote on your system.
If you have a black hat with programming rights, your system is as
vulnerable as it gets.

In the second place, you imply that a PIE grad could exploit i5/OS the way
I've described. So then, Rob, put up or shut up. I'll bet you a thousand
dollars and even give you five-to-one odds that no PIE graduate will be able
to invoke a buffer overrun exploit on i5/OS.

Otherwise, you really ought to drop it. Instead of wasting time, just get a
Joe Pluta voodoo doll and stick pins in it when you're feeling cranky.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.