WARNING: SOMEWHAT UNPROFESSIONAL RANT FOLLOWS

This is quickly devolving into basically us having to trust your word,
Patrick. You're saying that you know something that we don't that makes
the
System i vulnerable.

Joe, once again you are twisting what other say in an attempt to prove a
point of yours that it flat out wrong. I didn't say "I know about
vulnerabilities in i5/OS that no else knows about". I said I know about
incidents (which, by the way, I am not at liberty to speak about and you
know that to be true based on the way IBM handles integrity PTFs) that
definitely shows that your statement -- which was, as is so often the
case, one of your overreaching, head in the sand, "I know better than
anyone else is possibly capable of understanding" statements and which I
quoted in my last append -- to be absolutely FALSE, WRONG, INVALID, and
just plain dumb.

Anybody who would take any of my statements on this forum and claim that
it is a negative attack against i5/OS or that would construe the statement
to mean that Windows or *nix provides the same value with respect to
security that i5/OS does, is someone who doesn't understand security well
enough -- or has their head buried too far in the sand -- to be making
the comment.

END WARNING, END COMMENTS ON THIS SUBJECT, END CAREER AT IBM


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/23/2007 05:48:08 PM:

From: Patrick Botz

The word "documented" is what makes the statement meaningless.

I know for a fact that the statement "has never been a case of any
sort of
buffer overrun, virus, or indeed anything else on a native i5/Os
system..." (not the lack of the word "documented" in this
statement....
It is this statement that I know for a fact is not true.

Thanks.

This is quickly devolving into basically us having to trust your word,
Patrick. You're saying that you know something that we don't that makes
the
System i vulnerable.

I personally think that's bunk.

So let's try one last time, shall we? Is there currently an existing
vulnerability in V5R4M5 of i5/OS wherein an external agent can via
TCP/IP
gain access to data or execute a program to which they are not
authorized?

If the answer is no, then i5/OS is more secure than Windows, and this is
just a semantic digression. If the answer is yes, then I demand you
prove
it, because it is a vulnerability in my system.

If the answer is "there was one, but we fixed it" then when was it
fixed?

If the answer is no, is there a vulnerability other than TCP/IP by which
an
external agent can gain access to data or programs to which they are not
authorized?

Again, if the answer is no, then I don't know what we're discussing. If
it's yes, then what is the route? I don't need to know specifics, just
the
communication point. SNA? TELNET? Remember, it has to be external,
meaning it can't involve physical access to the System i. If it's
command-line access, then that's a completely different animal.

Really, Patrick, your argument boils down to, "The System i is
vulnerable
and I know it." Whereas my argument is that Windows is vulnerable, and
the
whole world knows it.

Joe

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This thread ...

Follow-Ups:
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].