---------------------------------------<snip>---------------------------------------
Rick brings up a good point: "/But as these types of problems grow,
I'm sure that IBM and REPUTABLE vendors are working to close any holes
that might exist./" As I see it there are two parts to this. Vendor
testing prior to shipping code and Vendor response when problems are
reported in the field. I can't really address what Vendors are doing
for testing prior to shipping code but I do have experience with
reporting zero day vulnerabilities to Vendors when their code is in
the field. Zero day vulnerabilities means the Vendor was not aware of
the problem before it was reported. The number of vulnerabilities in
the latest releases of z/OS (this would include the ISV code) is much
higher than most people realize. This implies that whatever testing
being done by Vendors is not identifying these problems. When
reporting these problems to a Vendor you better hope that they have
some policy about repairing these types of problems. IBM has a written
policy on integrity (See IBM statement of integrity) and when this
type of problem is reported to IBM they have to date fixed or are
working on fixing the problem in my experience. Some other Vendors
also fall into this category. However, I have had some "less than
enthusiastic" responses from some other Vendors.
Rick also makes a couple of other points: "/as good sysprogs get
scarcer, so do the numbers of people capable of compromising the code.
As the systems get more and more complex, it's harder and harder to
devise the mechanisms to compromise those systems/." I think it is
true that there are less people today who have this type of expertise
than in the past (in the US at least). However I don't think that it
is getting harder to compromise z/OS. For example, I recently (z/OS
1.9 time frame) came up an 11 line rexx exec that exploited a
vulnerability with some ISV code. In this case the rexx exec was able
to dynamically give any TSO user the RACF privileged authority. This
means that access to any RACF protected resource would be allowed with
no RACF logging (Note that I could have developed an exploit for
CA-TSS or CA-ACF2 instead of RACF if required. These types of exploits
are independent of the ESM (external security manager)).While it is
true that a higher level of expertise was required to initially
develop the exploit if the exploit was published (for example on the
internet) the level of expertise required to use the exploit would be
much less. I think most, if not all z/OS installations have people
that can type in an 11 line rexx exec and execute it.
----------------------------------------<unsnip>--------------------------------------
Ray, I won't ask you for the REXX code but I hope you've reported this
to IBM. Just in case the ISV is exploiting a hole they've found and
haven't reported. I firmly believe that ANY integrity exposure should be
reported to IBM, as the primary software provider, as well as to any ISV
that might be involved, however periphally.
Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
