From: Walden H. Leverich

This is simply untrue.
The buffer overrun exploits that allow you to raise your security level
and
thus take over a machine are not possible in i5/OS.

I'll say it, since Patrick is probably too nice to do so...

Joe, taking on Patrick Botz, IBM's lead security architect for i5/OS and
the IBM Virtualization Engine, about what's possible and not possible in
i5/OS security is probably a losing battle. IF, and I stress, IF, there
are possible exploits for i5/OS, he's the one to know!

Oh bullcrap, Walden. We're all experts in our various areas, and we're all
mistaken at times. Just because someone is the lead ANYTHING doesn't make
them infallible; quite the opposite, it sometimes makes them more fallible,
especially when they lose sight of their own fallibility.

In fact, when experts start yammering, sometimes what you get is a bunch of
opinion with no substance to back it up.

I'm not saying that's the case here, of course, but it doesn't really matter
anyway, because the good news is that security doesn't give a crap what you
or I say. Security is not some arcane science, it's simple facts, and
obfuscation does nobody any good.

I challenge you or indeed anyone to write a buffer exploit via a native
i5/OS service. I've made this challenge many times over the years, and
nobody has ever tried to take me up on it.

Feel free.

Compared to the FACT that there has NEVER been a buffer overrun exploit on
i5/OS (your esteem for Mr. Botz notwithstanding), his opinion is simply an
opinion.

I'm sorry, computers aren't mystical. They're binary, and you either can
exploit them or you can't. Windows - you can. i5/OS - you can't. Get over
it.

Joe


This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].