Re: Mainframe hacking?

2010-10-16 Thread Rick Fochtman


And, what can you do about 20 year old code with no comments?
-
That depends on how much time you can spend researching 20-year-old 
interfaces  :-)


My inclination would be to chuck it into the nearest bit-bucket and 
redesign/recode as needed. WITH DOCUMENTATION!


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


Re: Mainframe hacking?

2010-10-16 Thread Clark Morris
On 15 Oct 2010 21:58:31 -0700, in bit.listserv.ibm-main you wrote:

>Actually a lot of the old user and system modification code that is still
>around was not where we normally exploited things.  Mostly it was the newer
>systems that were shipped with a lot of theoretically unused products, code
>and other appendages that had for the most part never been installed or was
>quickly uninstalled in the "old" days.  Installed (and for the most part
>unused) access and always authorized technology programs in LPA and Linklist
>were always our goto method.
I know that I had a hard time figuring out what was on the system and
did we really need it in the 1980s when I was doing Virtual Storage
Constraint Relief and that was with a lot fewer products.  As Brian
says elsewhere in this message there is a lot of dead code (IBM
products not activated, etc.) that may well be on our systems.
Websphere and other web related systems have a whole new host of
vulnerabilities.  We have gone from hundreds or thousands of allowed
users to possibly millions (large banks, various governments, large
retailers, etc.) of users who can sign in and access something on our
systems.  Think about your credit card provider for example.  

How vulnerable are the applications?  Would compromising Websphere
give benefit to those who want to make money?  Are we vulnerable to
such things as SQL injection and buffer overruns in some of the newer
packages?  

Clark Morris  
>
>I think that it may be that the newer systems programmers were not as
>concerned about the stuff that was there because I don't think they ever
>really took the time to think about what was out there and what impact it
>had/has and what exposures it can cause.  
>
>A lot of people seem to feel that the technical people of the current age
>cannot compare to what came before, but that's not really a fair assumption.
> If you think about it, z/OS is much more complex than what came before.  We
>used to know what everything did because there was not really that much
>involved.  Sure it was millions of lines of code, but compare that to now.
>
>Having met a large number of the old and new systems programmers, I can
>honestly say that there are many that were very bright, and there still are
>many new ones that are just as bright.  I can remember being at sites that
>personnel were in charge of  subsets of the code (modules IEF to IJK for
>instance).  You just can't do that any more today, and thankfully no one has
>to.  If you were to talk about the requirements of establishing and running
>a sysplex with some of the old people, you would completely blow their
>minds, just as if you were to try to explain to the systems people today how
>important the lights on the front of the 370 were to fixing a system problem
>and getting things going again.
>
>The problems are not the personnel, it's the sloppy code and the excess code
>that is shipped with every installed base.  There are many ways into the
>system with or without RACF.  
>
>Luckily we with the keys are trust-able.
>
>Brian
>
>--
>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

--
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


Re: Mainframe hacking?

2010-10-16 Thread Bill Godfrey
On Sat, 16 Oct 2010 01:43:40 +, Ted MacNEIL  
wrote:

>>Copy to tape or to DASD sequential datasets with appropriate conversion.
>
>Since it's designed strictly for ISPF, under TSO, isn't that asking a little 
much?
>
>That's like saying a compare utility doesn't copy files.

The TSO TRANSMIT command needs that function of IEBCOPY when a PDS is 
involved, and RECEIVE needs the reverse function.

Bill

--
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


Re: Mainframe hacking?

2010-10-15 Thread Brian Westerman
Actually a lot of the old user and system modification code that is still
around was not where we normally exploited things.  Mostly it was the newer
systems that were shipped with a lot of theoretically unused products, code
and other appendages that had for the most part never been installed or was
quickly uninstalled in the "old" days.  Installed (and for the most part
unused) access and always authorized technology programs in LPA and Linklist
were always our goto method.

I think that it may be that the newer systems programmers were not as
concerned about the stuff that was there because I don't think they ever
really took the time to think about what was out there and what impact it
had/has and what exposures it can cause.  

A lot of people seem to feel that the technical people of the current age
cannot compare to what came before, but that's not really a fair assumption.
 If you think about it, z/OS is much more complex than what came before.  We
used to know what everything did because there was not really that much
involved.  Sure it was millions of lines of code, but compare that to now.

Having met a large number of the old and new systems programmers, I can
honestly say that there are many that were very bright, and there still are
many new ones that are just as bright.  I can remember being at sites that
personnel were in charge of  subsets of the code (modules IEF to IJK for
instance).  You just can't do that any more today, and thankfully no one has
to.  If you were to talk about the requirements of establishing and running
a sysplex with some of the old people, you would completely blow their
minds, just as if you were to try to explain to the systems people today how
important the lights on the front of the 370 were to fixing a system problem
and getting things going again.

The problems are not the personnel, it's the sloppy code and the excess code
that is shipped with every installed base.  There are many ways into the
system with or without RACF.  

Luckily we with the keys are trust-able.

Brian

--
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


Re: Mainframe hacking?

2010-10-15 Thread Mike Schwab
On Fri, Oct 15, 2010 at 6:02 PM, Rick Fochtman  wrote:
> --
>
>> On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote:
>>
>> But why, when hit by a Windows exploit, don't they likewise say,
>> "It's time to move off Windows._
>
> 
> I once had a guy explain it to me this way: when a manager has complete
> control over the computer on his desktop, including the power on/off
> functions, he feels much less vulnerable to outside malevolence. In short,
> he feels much more "in control", never mind that it's a false sense of
> security.
>
> Rick

Go into his office, shrink his C drive by 10GB, install Grub and
Ubuntu or another Linux desktop, and let him try it.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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


Re: Mainframe hacking?

2010-10-15 Thread Chris Mason
Frank

The issue - the word used correctly for once! - with exits - or perhaps just 
one of the issues with exits - is that they, in effect, become part of the 
executing code of the "product". And the issue - still using the word in one of 
its correct meanings - with executing code is that somebody has to maintain 
it. When you buy a product, you buy a promise that it will do what the 
salesman said it can do. I presume - although it's not a situation I have 
encountered in my sheltered existence - that if a product happens actually to 
exploit an exit provided by another product - presumably with some sort of 
provision in the implementation that other products can also exploit the same 
exit - starting to get tricky isn't it? - the "promise" extends to the exit 
code.

If your installation considers implementing an exit, just as with any 
"in-house" 
code, a responsible function within the installation needs to "own" the exit 
code so that, even if the author is "let go", there will always be someone 
among the "suits" who takes care that the knowledge needed to support that 
little exit is also not lost - just as I would expect applies to massive 
application suites.

It's because needing to establish that responsibility in an installation can 
become rather tricky that some installation do not even contemplate trying to 
deal with it - your installation seeming to be one.

Actually this is an issue with which I - as I mentioned having had a sheltered 
existence - have not had to deal with directly but it's what I have picked up 
from those who have and I hope I picked it up more or less correctly.

Incidentally, you may be a *new* z/OS application developer but are you not 
an *old* VSE application developer and isn't there a similar issue in the VSE 
world?

-

Interestingly enough regarding exits, VTAM offers some exits as documented 
in the SNA Customization manual, What's really interesting is that VTAM 
development has somewhat "muddied the water" by providing "sample" exits 
which become so popular that VTAM development actually committed to 
maintenance of the supplied "sample" exits. Two such exits are the ISTEXCCS 
and ISTEXCSD, essentially dynamic connection definitions - to some extent a 
function available without needing support from the exit since the exit was 
introduced - and dynamic LU definitions.

There is even some sort of session management exit out there upon which I 
believe VTAM development smiles benevolently!

-

On review, I noticed you mentioned CICS. Didn't the CICS autoinstall function 
start as an exit for customers to use as they thought fit which got 
transformed into some standard code provided by CICS development - or 
something like that - not unlike what happened to those VTAM exits?

Chris Mason

On Fri, 15 Oct 2010 12:28:20 -0600, Frank Swarbrick 
 wrote:

>As a new z/OS applications developer I'm curious as to what types of things 
use custom user exits et al for.  From what I've heard from our sysprogs, our 
philosophy is to "never" use inhouse written user exits.  Of course there are 
vendor supplied user exits, but the only inhouse user exit I know of that we 
use is CICS XDLIPRE, and that's only in our test regions.  (And interestingly 
we 
just this week ran in to issues with XDLIPRE cause AUEP abends!)
>
>Frank

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ted MacNEIL
>I was trained, and will always maintain, that there is no possible excuse for 
>not inserting meaningful comments into my code. After all, I 
might be the guy who has to unbutton it and fix it sometime in the future.

I agree with you.
But, obviously, not everybody did.
That was my point.
And, what can you do about 20 year old code with no comments?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ted MacNEIL
>Copy to tape or to DASD sequential datasets with appropriate conversion.

Since it's designed strictly for ISPF, under TSO, isn't that asking a little 
much?

That's like saying a compare utility doesn't copy files.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ray Overby
 I agree that notification of the code owner (ISV or IBM) is the right 
thing to do for integrity based vulnerabilities.  Unlike vulnerabilities 
that are based upon configuration, IPL parameters or security settings 
integrity vulnerabilities cannot be remediated by the installation. You 
have to go back to the code owner in order to fix the problem.


For the rexx exec example:

-The vulnerability that the rexx exec exploited was the result of a 
poor design choice by a Vendor. Once the Vendor followed standards as 
defined by IBM the vulnerability was eliminated. IBM was not notified in 
this case because 1) It was not IBM code 2) We verified the original 
vulnerability was eliminated after applying Vendor provided remediation.


-Hypothetically speaking, if code was identified that takes 
advantage of an integrity based vulnerability in order to gain 
authorization instead of using documented interfaces under installation 
control, then yes, I think that both code owners should be notified.


On 10/15/2010 17:55 PM, Rick Fochtman wrote:
-- 



 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.


-- 

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



--
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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

--

I would say that the first step should be to have ALL customization, exits, etc. very well documented, both their action and the reasons for 
   


their actions.

That would have been great 20-30 years ago, but what do you do with the lack of 
existing doc?

Many times it's missing, or the coder didn't think it was important.

I don't document code!
It was hard to write; it should be hard to read!
 


--
I was trained, and will always maintain, that there is no possible 
excuse for not inserting meaningful comments into my code. After all, I 
might be the guy who has to unbutton it and fix it sometime in the 
future. I might not remember the details that I had in mind when I 
originally coded it.  :-)


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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

-


In my experience, SPFCOPY lacks some of the functions of IEBCOPY.
   



Since it just does copies under the '3' utilities, which of these missing 
functions are needed?
 


-
Copy to tape or to DASD sequential datasets with appropriate conversion.

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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

-


As a new z/OS applications developer I'm curious as to what types of things use custom 
user exits et al for.  From what I've heard from our sysprogs, our philosophy is to 
"never" use inhouse written user exits.  Of course there are vendor supplied 
user exits, but the only inhouse user exit I know of that we use is CICS XDLIPRE, and 
that's only in our test regions.  (And interestingly we just this week ran in to issues 
with XDLIPRE cause AUEP abends!)
 


---
Frank, I've used exits to enforce JCL standards, (JES2 and TSO),  
display information on SYSLOG and JOBLOGs (IEFAACTRT and IEFU8x) and 
impose a more restrictive set of rules on password formation in RACF. My 
use was by no means exhaustive but those are a few of the things that 
exits can do for your shop. We also used an exits to automatically strt 
SMFDUMP whenever the SMV datasets switched because the current one got 
full, or the operator issued a SWITCH command.


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


Re: Mainframe hacking?

2010-10-15 Thread Ted MacNEIL
>I would say that the first step should be to have ALL customization, exits, 
>etc. very well documented, both their action and the reasons for 
their actions.

That would have been great 20-30 years ago, but what do you do with the lack of 
existing doc?

Many times it's missing, or the coder didn't think it was important.

I don't document code!
It was hard to write; it should be hard to read!

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

--


On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote:

 


On 10/15/2010 7:20 AM, Lindy Mayfield wrote:
   


I say heavily customized but that's only a few of my customers.
Just about every mainframe shop I've seen, especially those that
have been around a while, have enough customization, exits, etc.
to be in trouble soon.  And, honestly, who will they call?
 


Most management will ignore it until it's too late and
then declare "it's time to move off the mainframe".

   


But why, when hit by a Windows exploit, don't they likewise say,
"It's time to move off Windows._
 



I once had a guy explain it to me this way: when a manager has complete 
control over the computer on his desktop, including the power on/off 
functions, he feels much less vulnerable to outside malevolence. In 
short, he feels much more "in control", never mind that it's a false 
sense of security.


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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

--

 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.


--
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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman

--


I say heavily customized but that's only a few of my customers.  Just about 
every mainframe shop I've seen, especially those that have been around a while, 
have enough customization, exits, etc. to be in trouble soon.  And, honestly, 
who will they call?  Serious question.  Who, consulting companies, IBM 
consultants or partners?
 


-
I would say that the first step should be to have ALL customization, 
exits, etc. very well documented, both their action and the reasons for 
their actions. The more detail, the better. Given that information at 
your site, you should be able to choose whatever technical assistance 
you might require from any of the three groups you've named.


Documentation is rather like sex; any is goodness; when it's really 
good, it's GREAT!. :-)


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


Re: Mainframe hacking?

2010-10-15 Thread Ted MacNEIL
>In my experience, SPFCOPY lacks some of the functions of IEBCOPY.

Since it just does copies under the '3' utilities, which of these missing 
functions are needed?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman
Since the 360/44 emulator broke in during the PSW-swap, it did require 
hardware modification. How other emulators, simulators, etc. get into 
action is information I don't have, or have any experience with, so I 
can't comment. YMMV.


Rick
---


I don't think we can call it hacking if IBM uses such techniques to implement 
simulators, emulators, virtualization, etc.  But other vendors' using the same 
techniques in order to make it easier for their products to achieve 
authorization is a different matter, IMHO.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Thursday, October 14, 2010 6:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

Even earlier than that, IBM used a comnination of hardware and software 
intercepts based around Program Interrupts to implement the Commercial 
Feature on the 360/44. I still have a copy of the "Emulator" that was 
loaded into special areas of 360/44 core that finished the process of 
implementing thie Commercial Feature, as well as a few other 
instructions in the General Instruction Set. :-)

--
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

--
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
.

 



--
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


Re: Mainframe hacking?

2010-10-15 Thread Rick Fochtman
 




Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they 
are loaded from SYS1.SVCLIB.
   



Yes. That's true.
But, what about the fact that work-alikes (eg: SPFCOPY) don't need them?
 



In my experience, SPFCOPY lacks some of the functions of IEBCOPY.

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


Re: Mainframe hacking?

2010-10-15 Thread Clark Morris
On 15 Oct 2010 05:28:21 -0700, in bit.listserv.ibm-main you wrote:

>IEBCOPY was developed in the early- to mid-1960s, when EXCP appendages were 
>the leading edge way to do cruel and unusual things in low-level I/O.  Such 
>has not been the case since the advent of MVS/XA and a redesigned IOS in 1983. 
> New, or older and still strategic, products typically use the latest and 
>greatest techniques.  It would appear that IBM does not yet consider 
>redesigning the 45-year-old IEBCOPY as strategic.

I am more interested in the idea that we should be urging the
reduction of need to run authorized as reducing security exposures.
Also what security exposures have been added by the way ziip and zap
work?

Clark Morris
>
>Bill Fairchild
>Rocket Software
>
>> rest snipped

--
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


Re: Mainframe hacking?

2010-10-15 Thread Frank Swarbrick
As a new z/OS applications developer I'm curious as to what types of things use 
custom user exits et al for.  From what I've heard from our sysprogs, our 
philosophy is to "never" use inhouse written user exits.  Of course there are 
vendor supplied user exits, but the only inhouse user exit I know of that we 
use is CICS XDLIPRE, and that's only in our test regions.  (And interestingly 
we just this week ran in to issues with XDLIPRE cause AUEP abends!)

Frank
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 10/15/2010 at 7:20 AM, in message
<0377b9a583fd0e4aacd676ee33ee994b345e5...@sdkmail13.emea.sas.com>, Lindy
Mayfield  wrote:
> I say heavily customized but that's only a few of my customers.  Just about 
> every mainframe shop I've seen, especially those that have been around a 
> while, have enough customization, exits, etc. to be in trouble soon.  And, 
> honestly, who will they call?  Serious question.  Who, consulting companies, 
> IBM consultants or partners?
> 
> Lindy
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of Ray Overby
> Sent: Friday, October 15, 2010 3:43 PM
> To: IBM-MAIN@bama.ua.edu 
> Subject: Re: Mainframe hacking?
> 
>   Barry,
> 
> What do you think of contacting Lindy off list to see if we can't get into 
> contact with "heavily customized systems with lots of system exits". KRI 
> could help them with their technical expertise...
> 
> Ray 
> 
> --
> 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

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
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


Re: Mainframe hacking? (IEBCOPY)

2010-10-15 Thread Knutson, Sam
Customers who are need to pay for CA-PDSMAN or SEA PDSFAST just to get 
acceptable performance when supporting large environments may disagree about 
IEBCOPY not being broken.

    Best Regards, 

    Sam Knutson, GEICO 
    System z Team Leader 
    mailto:sknut...@geico.com 
    (office)  301.986.3574 
    (cell) 301.996.1318
  
"Think big, act bold, start simple, grow fast..." 

-Original Message-
When IEBCOPY was converted from MVT to MVS, the developers at the 
time wanted to make it run "as fast as possible". Also, IEBCOPY might 
have been a good vehicle for testing/experimenting with those 
wonderful new interfaces.

Certainly, there is no technical reason in the world (at least I 
don't know of one) why a functionally identical could not be written 
that did not require authorization...

It's probably a matter of "It ain't broke, so for god's sake don't fix it!"

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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


Re: Mainframe hacking?

2010-10-15 Thread Paul Gilmartin
On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote:

>On 10/15/2010 7:20 AM, Lindy Mayfield wrote:
>> I say heavily customized but that's only a few of my customers.
>> Just about every mainframe shop I've seen, especially those that
>> have been around a while, have enough customization, exits, etc.
>> to be in trouble soon.  And, honestly, who will they call?
>
>Most management will ignore it until it's too late and
>then declare "it's time to move off the mainframe".
>
But why, when hit by a Windows exploit, don't they likewise say,
"It's time to move off Windows._

-- gil

--
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


Re: Mainframe hacking?

2010-10-15 Thread Paul Gilmartin
On Fri, 15 Oct 2010 09:48:01 -0600, Steve Comstock wrote:
>
>Don't hate EBCDIC, be amazed at the ability
>to work with EBCDIC, ASCII, and Unicode all on one
>system.
>
EBCDIC is easy enough to use.  It's just too difficult to
avoid.  The OS is biased.  A fair operating system would
let me NFS mount my Solaris data sets xlat(N) and live
in ASCII, with no funky tagging of files or autoconversion.
Let me tag and autocovert my Legacy data sets when I need
the facility.

Even as programmers can operate on the Legacy side and deal
with ASCII only when necessary, I'd like to operate in
ASCII and deal with EBCDIC only when necessary.

-- gil

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ricc Harding
SPFCopy's "magic" SVC went thru several iterations to make it secure too. It
was one of those SVC's that was written to be "serially secure" but in a
multi-tasking environment when two or more tasks could be set up to run
concurrently, then a "serially secure" task, doing what it did in a secure
manner (if it was the only thing running) allowed everyone running in the
address space to participate in the authorization.  STATUS STOP became very
much a requirement for those serially secure tasks to remain such.

--
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


Re: Mainframe hacking?

2010-10-15 Thread Tom Marchant
On Fri, 15 Oct 2010 10:28:21 -0500, Paul Gilmartin  

>On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote:
>>
>>Most management will ignore it until it's too late and
>>then declare "it's time to move off the mainframe".
>>
>But why, when hit by a Windows exploit, don't they likewise say,
>"It's time to move off Windows._

The Redmond propaganda machine has been quite effective.

-- 
Tom Marchant

--
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


Re: Mainframe hacking?

2010-10-15 Thread John McKown
Each and every time I try to point out new or good points about the z, Iget
the same response: "It is simply not cost effective!" or more simply: "It
costs too much!". This despite the __documented fact__ that the z does over
80% or the production work at less than 50% of the IT budget. Of course,
part of the budget goes for things which cannot be done on the z. Such as
desktop PCs running Windows. But they won't consider Linux instead. It would
cost too much to retrain. And, they say, it won't work seamlessly with MS
Exchange. Which is "locked in" because management is convinced that it is
uniquely irreplaceable. Also, a Linux desktop won't .

John McKown
Maranatha! <><

On Oct 15, 2010 10:48 AM, "Steve Comstock"  wrote:

On 10/15/2010 9:28 AM, Paul Gilmartin wrote:
>
> On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock ...
Because most managers today "know" windows and they
accept poor security and performance as inevitable;
they aren't even aware of alternatives.

Why?

Because IBM is not telling the story.

And, sad to say, neither are we. We are not bragging
about the amazing features of z/OS (of course, you
gotta' do this in a style of "is this cool, or what?"
as opposed to "squatty boxes stink, look at what we
do under z/OS").

So, take some time to reflect on how this would best
be done in your shop. For example, Paul, you would
probably not want to extol JCL; on the other hand
you would praise the ability to run both z/OS and
UNIX (in the guise of z/OS UNIX System Services) on
one box. Don't hate EBCDIC, be amazed at the ability
to work with EBCDIC, ASCII, and Unicode all on one
system.


Caveat: of course, there are exceptions to all of
the above assertions, and I don't want to belittle
those IBM'ers and IBM-main residents who are telling
the story inside their companies; nor do I want to
disparage those managers who understand the role
the mainframe has in their organization.




-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersf...

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu w...

--
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


Re: Mainframe hacking?

2010-10-15 Thread Steve Comstock

On 10/15/2010 9:28 AM, Paul Gilmartin wrote:

On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote:


On 10/15/2010 7:20 AM, Lindy Mayfield wrote:

I say heavily customized but that's only a few of my customers.
Just about every mainframe shop I've seen, especially those that
have been around a while, have enough customization, exits, etc.
to be in trouble soon.  And, honestly, who will they call?


Most management will ignore it until it's too late and
then declare "it's time to move off the mainframe".


But why, when hit by a Windows exploit, don't they likewise say,
"It's time to move off Windows._

-- gil


Because most managers today "know" windows and they
accept poor security and performance as inevitable;
they aren't even aware of alternatives.

Why?

Because IBM is not telling the story.

And, sad to say, neither are we. We are not bragging
about the amazing features of z/OS (of course, you
gotta' do this in a style of "is this cool, or what?"
as opposed to "squatty boxes stink, look at what we
do under z/OS").

So, take some time to reflect on how this would best
be done in your shop. For example, Paul, you would
probably not want to extol JCL; on the other hand
you would praise the ability to run both z/OS and
UNIX (in the guise of z/OS UNIX System Services) on
one box. Don't hate EBCDIC, be amazed at the ability
to work with EBCDIC, ASCII, and Unicode all on one
system.


Caveat: of course, there are exceptions to all of
the above assertions, and I don't want to belittle
those IBM'ers and IBM-main residents who are telling
the story inside their companies; nor do I want to
disparage those managers who understand the role
the mainframe has in their organization.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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


Re: Mainframe hacking?

2010-10-15 Thread Eric Bielefeld
I don't think there is shortages in systems programmers yet.  I know the last 4 
years, there has been maybe 3 or 4 jobs open in the Milwaukee area, out of I 
figure about 10 z/OS shops.  Each opening had plenty of applicants, as far as I 
can figure.  

In 5 to 10 years, that could all change, but by then I'll be retired and won't 
care!  There probably are shortages in some areas, and places that most people 
don't want to move to. 

--
Eric Bielefeld
Systems Programmer


 Lindy Mayfield  wrote: 
> I say heavily customized but that's only a few of my customers.  Just about 
> every mainframe shop I've seen, especially those that have been around a 
> while, have enough customization, exits, etc. to be in trouble soon.  And, 
> honestly, who will they call?  Serious question.  Who, consulting companies, 
> IBM consultants or partners?
> 
> Lindy

--
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


Re: Mainframe hacking?

2010-10-15 Thread Chris Craddock
On Fri, Oct 15, 2010 at 10:43 AM, Ricc Harding wrote:

> SPFCopy's "magic" SVC went thru several iterations to make it secure too.
> It
> was one of those SVC's that was written to be "serially secure" but in
> a
> multi-tasking environment when two or more tasks could be set up to run
> concurrently, then a "serially secure" task, doing what it did in a secure
> manner (if it was the only thing running) allowed everyone running in the
> address space to participate in the authorization.  STATUS STOP became very
> much a requirement for those serially secure tasks to remain such.
>



The truth is that there is no such thing as a secure magic SVC (or PC) no
matter how creative its authors are.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: Mainframe hacking?

2010-10-15 Thread David Cole

At 10/14/2010 07:54 PM, Rick Fochtman wrote:



For example, why do IDCAMS and IEBCOPY have to be authorized?  The
IEBCOPY replacement doesn't have to be authorized.  Would it be
worthwhile for both vendors and users to see what they can do to
reduce the amount of code that has to be authorized?


[snip]

Also, IIRC, IEBCOPY uses I/O appendages that require authorization, 
since they are loaded from SYS1.SVCLIB.


When IEBCOPY was converted from MVT to MVS, the developers at the 
time wanted to make it run "as fast as possible". Also, IEBCOPY might 
have been a good vehicle for testing/experimenting with those 
wonderful new interfaces.


Certainly, there is no technical reason in the world (at least I 
don't know of one) why a functionally identical could not be written 
that did not require authorization...


It's probably a matter of "It ain't broke, so for god's sake don't fix it!"

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ray Overby
 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.



On 10/14/2010 18:48 PM, Rick Fochtman wrote:
- 



The whole point, I think, is to get it by the system's guys.  Not 
sure how to do that.  So much easier on Windows.  Still there are 
coming more and more "freeware" MVS utilities, like showmvs.  (It can 
run authorized I think, yes?)  I don't think that it is that 
carefully audited, somebody could slip something into there.  Or some 
ported tool like TSOCMD.
It would be very unlikely that something like that would get by you 
guys, but good sysprogs are getting fewer and fewer, and, as an 
inside job perhaps, someone may easily trick an admin into installing 
some useful utility that has been compromised.



-- 

Lindy, you're correct but I think you forgot the corrolary: 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. True, we see less and less suspect SVC code and more and more 
PC code that might be suspect. But as these types of problems grow, 
I'm sure that IBM and REPUTABLE vendors are working to close any holes 
that might exist.


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




--
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


Re: Mainframe hacking?

2010-10-15 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield
> Sent: Friday, October 15, 2010 8:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe hacking?
> 
> I say heavily customized but that's only a few of my 
> customers.  Just about every mainframe shop I've seen, 
> especially those that have been around a while, have enough 
> customization, exits, etc. to be in trouble soon.  And, 
> honestly, who will they call?  Serious question.  Who, 
> consulting companies, IBM consultants or partners?
> 
> Lindy

My manager has already been addressing this. We have greatly reduced the number 
of exits. And we try to use products to do work instead of in-house. As an 
example, we use CA-OPS/MVS's ability to do IEFUTL functionality for our UTL 
work instead of a hand coded IEFUTL exit. We also use it to trap the SMF switch 
to issue the START SMFDUMP command instead of IEFU29. We have a JES2 exit 20; 
IKJEFF10 (in-house written by me); IKJEFF53 (IBM example); IEFACTRT (IBM 
example); ARCTVEXT (CA1 example); FTCHKCMD (example modified to make IBM's ftp 
server respond to some of RUNTCP's commands).

But "who will do this?" - I'd be open to helping sometime. But only for enough 
pay to make it worth my while to mess with 1099 income reporting. I did the 
consultant thing some time ago and did not enjoy the paperwork with the IRS. 
But I don't want to be too successful! Don't want to reach the "magic" 
$250,000/yr income and be classified as "rich".

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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


Re: Mainframe hacking?

2010-10-15 Thread Steve Comstock

On 10/15/2010 7:20 AM, Lindy Mayfield wrote:

I say heavily customized but that's only a few of my customers.
Just about every mainframe shop I've seen, especially those that
have been around a while, have enough customization, exits, etc.
to be in trouble soon.  And, honestly, who will they call?




Serious question.  Who, consulting companies, IBM consultants or partners?

Lindy



Most management will ignore it until it's too late and
then declare "it's time to move off the mainframe".


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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


Re: Mainframe hacking?

2010-10-15 Thread Lindy Mayfield
I say heavily customized but that's only a few of my customers.  Just about 
every mainframe shop I've seen, especially those that have been around a while, 
have enough customization, exits, etc. to be in trouble soon.  And, honestly, 
who will they call?  Serious question.  Who, consulting companies, IBM 
consultants or partners?

Lindy


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: Friday, October 15, 2010 3:43 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

  Barry,

What do you think of contacting Lindy off list to see if we can't get into 
contact with "heavily customized systems with lots of system exits". KRI could 
help them with their technical expertise...

Ray 

--
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


Re: Mainframe hacking?

2010-10-15 Thread Elardus Engelbrecht
Ray Overby wrote:

>  My apologies to this the list. I did not mean for this email to be sent 
there..

Apology accepted of course. For three and half nanoseconds, it seemed you 
want to 'hack' into this very discussion list... ;-D ;-D ;-D

Groete / Greetings
Elardus Engelbrecht

--
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


Re: Mainframe hacking?

2010-10-15 Thread Shane
Really   ?
Would never have guessed.

Been there, done that.

Shane ...

On Fri, 15 Oct 2010 08:05:39 -0500
Ray Overby wrote:

>   My apologies to this the list. I did not mean for this email to be 
> sent there..

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ray Overby
 My apologies to this the list. I did not mean for this email to be 
sent there..


On 10/15/2010 07:42 AM, Ray Overby wrote:

 Barry,

What do you think of contacting Lindy off list to see if we can't get 
into contact with "heavily customized systems with lots of system 
exits". KRI could help them with their technical expertise...


Ray

On 10/15/2010 06:46 AM, Lindy Mayfield wrote:

I think that there is another bit of wisdom there.

First, I don't think mainframe hacking would be very profitable.  In 
my opinion information would be the most valuable, and an inside job 
would be easiest.  Give someone, perhaps disgruntled, a large sum of 
money and the information might be bought.


The thing that interests me is the fact that both user and system 
people are becoming less and less experienced.  I'm even seeing that 
happen now in most of the places I visit.  Some places have heavily 
customized systems, with lots of system exits.  They will soon be in 
serious horse hockey, and many already are.


So if someone should make use of certain resources, some of the most 
valuable coming from people with the most experience on these lists, 
and learn the internals, there may be gold in them thar hills.


So to speak.  :-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf Of Rick Fochtman

Sent: Friday, October 15, 2010 2:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

-- 

Lindy, you're correct but I think you forgot the corrolary: 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.
True, we see less and less suspect SVC code and more and more PC code 
that might be suspect. But as these types of problems grow, I'm sure 
that IBM and REPUTABLE vendors are working to close any holes that 
might exist.


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


--
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



--
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



--
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


Re: Mainframe hacking?

2010-10-15 Thread Steve Comstock

On 10/15/2010 5:46 AM, Lindy Mayfield wrote:

I think that there is another bit of wisdom there.

First, I don't think mainframe hacking would be very profitable.  In my opinion 
information would be the most valuable, and an inside job would be easiest.  
Give someone, perhaps disgruntled, a large sum of money and the information 
might be bought.

The thing that interests me is the fact that both user and system people are 
becoming less and less experienced.  I'm even seeing that happen now in most of 
the places I visit.  Some places have heavily customized systems, with lots of 
system exits.  They will soon be in serious horse hockey, and many already are.

So if someone should make use of certain resources, some of the most valuable 
coming from people with the most experience on these lists, and learn the 
internals, there may be gold in them thar hills.

So to speak.  :-)

Lindy



Go for it, Lindy!

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

--
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


Re: Mainframe hacking?

2010-10-15 Thread Ray Overby

 Barry,

What do you think of contacting Lindy off list to see if we can't get 
into contact with "heavily customized systems with lots of system 
exits". KRI could help them with their technical expertise...


Ray

On 10/15/2010 06:46 AM, Lindy Mayfield wrote:

I think that there is another bit of wisdom there.

First, I don't think mainframe hacking would be very profitable.  In my opinion 
information would be the most valuable, and an inside job would be easiest.  
Give someone, perhaps disgruntled, a large sum of money and the information 
might be bought.

The thing that interests me is the fact that both user and system people are 
becoming less and less experienced.  I'm even seeing that happen now in most of 
the places I visit.  Some places have heavily customized systems, with lots of 
system exits.  They will soon be in serious horse hockey, and many already are.

So if someone should make use of certain resources, some of the most valuable 
coming from people with the most experience on these lists, and learn the 
internals, there may be gold in them thar hills.

So to speak.  :-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Friday, October 15, 2010 2:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

--
Lindy, you're correct but I think you forgot the corrolary: 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.
True, we see less and less suspect SVC code and more and more PC code that 
might be suspect. But as these types of problems grow, I'm sure that IBM and 
REPUTABLE vendors are working to close any holes that might exist.

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

--
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



--
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


Re: Mainframe hacking?

2010-10-15 Thread Bill Fairchild
IEBCOPY was developed in the early- to mid-1960s, when EXCP appendages were the 
leading edge way to do cruel and unusual things in low-level I/O.  Such has not 
been the case since the advent of MVS/XA and a redesigned IOS in 1983.  New, or 
older and still strategic, products typically use the latest and greatest 
techniques.  It would appear that IBM does not yet consider redesigning the 
45-year-old IEBCOPY as strategic.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ted MacNEIL
Sent: Thursday, October 14, 2010 7:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

>Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they 
>are loaded from SYS1.SVCLIB.

Yes. That's true.
But, what about the fact that work-alikes (eg: SPFCOPY) don't need them?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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

--
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


Re: Mainframe hacking?

2010-10-15 Thread Bill Fairchild
I don't think we can call it hacking if IBM uses such techniques to implement 
simulators, emulators, virtualization, etc.  But other vendors' using the same 
techniques in order to make it easier for their products to achieve 
authorization is a different matter, IMHO.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Thursday, October 14, 2010 6:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

Even earlier than that, IBM used a comnination of hardware and software 
intercepts based around Program Interrupts to implement the Commercial 
Feature on the 360/44. I still have a copy of the "Emulator" that was 
loaded into special areas of 360/44 core that finished the process of 
implementing thie Commercial Feature, as well as a few other 
instructions in the General Instruction Set. :-)
--
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

--
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


Re: Mainframe hacking?

2010-10-15 Thread Lindy Mayfield
I think that there is another bit of wisdom there.

First, I don't think mainframe hacking would be very profitable.  In my opinion 
information would be the most valuable, and an inside job would be easiest.  
Give someone, perhaps disgruntled, a large sum of money and the information 
might be bought.

The thing that interests me is the fact that both user and system people are 
becoming less and less experienced.  I'm even seeing that happen now in most of 
the places I visit.  Some places have heavily customized systems, with lots of 
system exits.  They will soon be in serious horse hockey, and many already are.

So if someone should make use of certain resources, some of the most valuable 
coming from people with the most experience on these lists, and learn the 
internals, there may be gold in them thar hills.

So to speak.  :-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Friday, October 15, 2010 2:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

--
Lindy, you're correct but I think you forgot the corrolary: 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. 
True, we see less and less suspect SVC code and more and more PC code that 
might be suspect. But as these types of problems grow, I'm sure that IBM and 
REPUTABLE vendors are working to close any holes that might exist.

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

--
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


Re: Mainframe hacking?

2010-10-14 Thread Paul Gilmartin
On Thu, 14 Oct 2010 18:38:45 -0500, Rick Fochtman wrote:
>
>Even earlier than that, IBM used a comnination of hardware and software
>intercepts based around Program Interrupts to implement the Commercial
>Feature on the 360/44. I still have a copy of the "Emulator" that was
>loaded into special areas of 360/44 core that finished the process of
>implementing thie Commercial Feature, as well as a few other
>instructions in the General Instruction Set. :-)
>
Millicode!  As Shmuel would say, ObQoheleth.

-- gil

--
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


Re: Mainframe hacking?

2010-10-14 Thread Paul Gilmartin
On Thu, 14 Oct 2010 23:58:25 +, Linda Mooney wrote:
>
>I always ask them for THEIR information.  Usually, they can't get off the 
>phone fast enough!  Then I pass the word around to the co-workers that 
>another phisher is lurking. 
>
"Give me your number; I'll have someone get back to you."

""

-- gil

--
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


Re: Mainframe hacking?

2010-10-14 Thread John McKown
The SPFCOPY that I remember simply used a "magic" SVC to set the APF on
before calling IEBCOPY and back off afterwards.

Did PDSFAST require APF authorization?

Sent from my Android/Vibrant phone. And much of the text was spoken and
transcribed, with some post editing.

John McKown
Maranatha! <><

On Oct 14, 2010 7:23 PM, "Ted MacNEIL"  wrote:

>Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since
they are loaded from SYS1...
Yes. That's true.
But, what about the fact that work-alikes (eg: SPFCOPY) don't need them?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu w...

--
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


Re: Mainframe hacking?

2010-10-14 Thread Ted MacNEIL
>Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they 
>are loaded from SYS1.SVCLIB.

Yes. That's true.
But, what about the fact that work-alikes (eg: SPFCOPY) don't need them?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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


Re: Mainframe hacking?

2010-10-14 Thread Linda Mooney
Hi Lindy, 



Oh yeah, social engineering is one that does get tried often.  If I only had a 
few nickels for every time somebody has cold called saying that they are from 
IBM, or one of our ISVs, or even someone claiming to be from big name companies 
that we may or may not do business with.  They are always friendly, and very 
persistant.  They always want to "verify account information" or talk to the 
boss, or  promise the results of a survey, or prizes, or whatever to get 
information.  Lots of time they will try to find out info about the 
configuration of the shop - both hardware and software.  I always ask them for 
THEIR information.  Usually, they can't get off the phone fast enough!  Then I 
pass the word around to the co-workers that another phisher is lurking. 



Linda    


- Original Message - 
From: "Lindy Mayfield"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, October 14, 2010 5:55:01 AM 
Subject: Re: Mainframe hacking? 

I didn't see anyone explicitly mention "social engineering".  IMO this may be 
an easier way to get a not-very-technical user's id, but then you are back to 
how to hack with a "normal" user TSO account.  But if a system guy gave out a 
password for an reason then, well, you know. 

What about digging through the trash?  Dropping some USB sticks around with 
interesting programs on them?   

A few people mentioned some few months back how to get a program authorized 
from a non-authorized library (or something like that), but nobody gave any 
details. 

For sure no script kiddies should ever get in, and if they did they wouldn't 
know what to do. 

One thing I didn't see in this thread, was what is the purpose of this hacking. 
  What is to be gained?  Sensitive information would be one thing I can think 
of. 

Lindy 

-- 
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 

--
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


Re: Mainframe hacking?

2010-10-14 Thread Rick Fochtman




For example, why do IDCAMS and IEBCOPY have to be authorized?  The
IEBCOPY replacement doesn't have to be authorized.  Would it be
worthwhile for both vendors and users to see what they can do to
reduce the amount of code that has to be authorized?
 


-
IIRC, IDCAMS uses s select few functions that require system 
authorization, for integrity protection.


Also, IIRC, IEBCOPY uses I/O appendages that require authorization, 
since they are loaded from SYS1.SVCLIB.


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


Re: Mainframe hacking?

2010-10-14 Thread Rick Fochtman

-

The whole point, I think, is to get it by the system's guys.  Not sure how to do that.  So much easier on Windows.  Still there are coming more and more "freeware" MVS utilities, like showmvs.  (It can run authorized I think, yes?)  I don't think that it is that carefully audited, somebody could slip something into there.  Or some ported tool like TSOCMD.  


It would be very unlikely that something like that would get by you guys, but 
good sysprogs are getting fewer and fewer, and, as an inside job perhaps, 
someone may easily trick an admin into installing some useful utility that has 
been compromised.
 


--
Lindy, you're correct but I think you forgot the corrolary: 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. 
True, we see less and less suspect SVC code and more and more PC code 
that might be suspect. But as these types of problems grow, I'm sure 
that IBM and REPUTABLE vendors are working to close any holes that might 
exist.


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


Re: Mainframe hacking?

2010-10-14 Thread Rick Fochtman
 




I would think it means code that front-ends one of the First Level Interrupt 
Handlers
   



That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to 
implement the IEEE floating point instructions so that they would work on 
processors that lacked the hardware. Of course these were not malicious 
implementations.

Bob Shannon
Rocket Software
 



Even earlier than that, IBM used a comnination of hardware and software 
intercepts based around Program Interrupts to implement the Commercial 
Feature on the 360/44. I still have a copy of the "Emulator" that was 
loaded into special areas of 360/44 core that finished the process of 
implementing thie Commercial Feature, as well as a few other 
instructions in the General Instruction Set. :-)


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


Re: Mainframe hacking?

2010-10-14 Thread Chase, John
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Lindy Mayfield
> 
> The whole point, I think, is to get it by the system's guys.  Not sure
how to do that.  So much easier
> on Windows.  Still there are coming more and more "freeware" MVS
utilities, like showmvs.  (It can run
> authorized I think, yes?)  I don't think that it is that carefully
audited, somebody could slip
> something into there.

One thing that might be argued in its defense is that you get all of the
source code for it

   -jc-

--
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


Re: Mainframe hacking?

2010-10-14 Thread Clark Morris
On 14 Oct 2010 07:24:01 -0700, in bit.listserv.ibm-main you wrote:

>At 10/13/2010 10:26 AM, Greg Shirey wrote:
>>I liked this article, and it's fairly recent.  (Jan 2010)
>>
>>http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1
>>
>>Greg
>
>I read that article, and it is a good one. Interestingly (to me at 
>least), on the article's third web page, there is an excerpt from a 
>post I made here in 2006. It's nice to know that someone is paying attention.
>
>My entire post can be found at: 
>http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com
>
>I think the information in that post are highly relevant to the 
>current thread.

For example, why do IDCAMS and IEBCOPY have to be authorized?  The
IEBCOPY replacement doesn't have to be authorized.  Would it be
worthwhile for both vendors and users to see what they can do to
reduce the amount of code that has to be authorized?

Clark Morris
>
>Dave Cole  REPLY TO: dbc...@colesoft.com
>ColeSoft Marketing WEB PAGE: http://www.colesoft.com
>736 Fox Hollow RoadVOICE:540-456-8536
>Afton, VA 22920FAX:  540-456-6658
>

--
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


Re: Mainframe hacking?

2010-10-14 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield
> Sent: Thursday, October 14, 2010 12:25 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe hacking?
> 
> The whole point, I think, is to get it by the system's guys.  
> Not sure how to do that.  So much easier on Windows.  Still 
> there are coming more and more "freeware" MVS utilities, like 
> showmvs.  (It can run authorized I think, yes?)  I don't 
> think that it is that carefully audited, somebody could slip 
> something into there.  Or some ported tool like TSOCMD.  
> 
> It would be very unlikely that something like that would get 
> by you guys, but good sysprogs are getting fewer and fewer, 
> and, as an inside job perhaps, someone may easily trick an 
> admin into installing some useful utility that has been compromised.

And much easier in the UNIX environment where there is even more ignorance 
about why to not do:

exattr +ap -F BIN myEvilProgram

which could be hidden in the installation script. Or even in the compiled 
program where it couldn't be seen. And installed with SMP/E when running with 
SUPERUSER authority.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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


Re: Mainframe hacking?

2010-10-14 Thread Wayne Driscoll
Ricc,
Yes, APF authorization still allows the keys to the kingdom.  That is why 
installations are expected to severely limit update access to APF 
authorized load libraries, the SETPROG MVS command, all datasets in the 
PARMLIB concatenation and all libraries defined as system level PROCLIBS. 
If a general user has write auth to an APF authorized dataset, your 
system, by definition, is unsecure.  That is why IBM and ISV's provide 
integrity statements and take seriously all reports of integrity holes. 
This is also why IBM refuses to provide any sort of details on integrity 
APAR's, so that shops without the appropriate PTF's applied are less 
likely to be compromised. 

===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===



From:
Ricc Harding 
To:
IBM-MAIN@bama.ua.edu
Date:
10/14/2010 12:10 PM
Subject:
Re: Mainframe hacking?
Sent by:
IBM Mainframe Discussion List 



Yes Ed, these sites all had RACF installed and yes, it still required the
VTOC "data set is RACF protected bit" to be flipped for the data set
protection call to even be made. The needed resource manager calls became
more apparent as the resources which were being protected grew.  The ACF2
"protectall" vs RACF "protectnone" philosophy soon became the guiding 
light
to making RACF actually usable as a security system by also implementing
"protectall". 

However APF authorization still allows the keys to the kingdom with no 
trace
for the clever programmer. And vendor PC calls are now the new point of
entry for system penetration attempts since they have all but replaced 
most
of the user written SVC's.

The landscape changes but the dirt is still the same.  The new hacker's
lament might be "so many entry points to choose from and so little time to
play". Vigilance and automation in security checking are the keys to
catching the silly things but the "clever programmer" still must have the
integrity and character to NOT do what they have both the ability and
opportunity to do.

Quis custodiet ipsos custodes

--
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



--
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


Re: Mainframe hacking?

2010-10-14 Thread Clark Morris
On 14 Oct 2010 05:56:48 -0700, in bit.listserv.ibm-main you wrote:

>I didn't see anyone explicitly mention "social engineering".  IMO this may be 
>an easier way to get a not-very-technical user's id, but then you are back to 
>how to hack with a "normal" user TSO account.  But if a system guy gave out a 
>password for an reason then, well, you know.
>
>What about digging through the trash?  Dropping some USB sticks around with 
>interesting programs on them?  
>
>A few people mentioned some few months back how to get a program authorized 
>from a non-authorized library (or something like that), but nobody gave any 
>details.
>
>For sure no script kiddies should ever get in, and if they did they wouldn't 
>know what to do.

Someone who understands WebSphere/Eclipse/etc. might be able to get
information they shouldn't.  What vulnerabilities are set up by use of
ziip and zap?  My vague understanding is that use of either involves
running in SRB mode but I admit I am out of my depth.  

>
>One thing I didn't see in this thread, was what is the purpose of this 
>hacking.   What is to be gained?  Sensitive information would be one thing I 
>can think of.

Think like a criminal out to make money.  Then think banks, on-line
order sites, etc.  
>
>Lindy
>
Clark Morris

--
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


Re: Mainframe hacking?

2010-10-14 Thread Ray Overby
 -The sad news is that integrity exposures exist today in every 
z/OS system. There is no need to install anything other than what you 
already have installed.

-These integrity exposures have already gotten past the "system's guys".
- Current systems programmers (in general) do not have the expertise 
required to identify these problems. There are exceptions of course. :-)
-Yes, installing shareware code can lead to introducing integrity 
exposures if you are not careful.



On 10/14/2010 12:24 PM, Lindy Mayfield wrote:

The whole point, I think, is to get it by the system's guys.  Not sure how to do that.  
So much easier on Windows.  Still there are coming more and more "freeware" MVS 
utilities, like showmvs.  (It can run authorized I think, yes?)  I don't think that it is 
that carefully audited, somebody could slip something into there.  Or some ported tool 
like TSOCMD.

It would be very unlikely that something like that would get by you guys, but 
good sysprogs are getting fewer and fewer, and, as an inside job perhaps, 
someone may easily trick an admin into installing some useful utility that has 
been compromised.



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Cole
Sent: Thursday, October 14, 2010 7:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

At 10/14/2010 12:24 PM, Chris Craddock wrote:

(as Bob knows) it is impossible to create/install a malicious FLIH or
SVC or PC without already having the keys to the kingdom anyway.
That is the foundation of integrity and the reason why the installation
has to appropriately protect system datasets and APF libraries.

Well that's just the problem, Chris, isn't it... The keys to the kingdom really 
are not well guarded. That's what my 2006 post was all about.

--
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



--
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


Re: Mainframe hacking?

2010-10-14 Thread Dr. Stephen Fedtke
hi,

if you are interested in details on this concern refer to

http://www.fedtke.com/download.htm
-> select  english
-> select the "IT SECURITY FORUM"

best
stephen


---
Dr. Stephen Fedtke
Enterprise-IT-Security.com

Seestrasse 3a
CH-6300  Zug
Switzerland
Tel. ++41-(0)41-710-4005
www.enterprise-it-security.com


++NEWS++ SF-LoginHood provides state-of-the-art password, phrase and login
security for z/OS ++NEWS++

--
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


Re: Mainframe hacking?

2010-10-14 Thread Bob Shannon
> I would think it means code that front-ends one of the First Level Interrupt 
> Handlers

That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to 
implement the IEEE floating point instructions so that they would work on 
processors that lacked the hardware. Of course these were not malicious 
implementations.

Bob Shannon
Rocket Software

--
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


Re: Mainframe hacking?

2010-10-14 Thread Phil Smith
Lindy Mayfield wrote:
>What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
>functionality?

Long ago and far away, a friend was looking at the VSE microfiche and found an 
undocumented SVC that stored the top half of a register value in the address 
contained in the bottom half of the register. He promptly wrote a program that 
used that SVC to gain control of the system. (He was working at IBM, so this 
was an internal thing.)
-- 
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com

--
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


Re: Mainframe hacking?

2010-10-14 Thread Chris Craddock
On Thu, Oct 14, 2010 at 11:13 AM, Bob Shannon
wrote:

> > I would think it means code that front-ends one of the First Level
> Interrupt Handlers
>
> That's how Amdahl implemented SE and SP assist years ago. I think IBM did
> it to implement the IEEE floating point instructions so that they would work
> on processors that lacked the hardware. Of course these were not malicious
> implementations.



(as Bob knows) it is impossible to create/install a malicious FLIH or SVC or
PC without already having the keys to the kingdom anyway. That is the
foundation of integrity and the reason why the installation has to
appropriately protect system datasets and APF libraries.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: Mainframe hacking?

2010-10-14 Thread Anne & Lynn Wheeler
p...@voltage.com (Phil Smith) writes:
> Long ago and far away, a friend was looking at the VSE microfiche and
> found an undocumented SVC that stored the top half of a register value
> in the address contained in the bottom half of the register. He
> promptly wrote a program that used that SVC to gain control of the
> system. (He was working at IBM, so this was an internal thing.)

re:
http://www.garlic.com/~lynn/2010n.html#73 Mainframe hacking?
http://www.garlic.com/~lynn/2010n.html#76 Mainframe hacking?

at the end of last century there is infamous case of large financial
institution (with large number of ATM machines) outsourcing the Y2K
remediation of their backend financial transaction processing system to
a software company ... which they found out much later was a front for a
criminal organization (eventually tripping across some very peculiar
pieces of code that would do some stealthy transactions, that could be
triggered by very specific combination of entries from ATM machine).

oh, and pieces of relative recent linkedin mainframe discussion
http://www.garlic.com/~lynn/2010l.html#28 Mainframe Hacking -- Fact or Fiction
http://www.garlic.com/~lynn/2010l.html#37 Mainframe Hacking -- Fact or Fiction
http://www.garlic.com/~lynn/2010l.html#51 Mainframe Hacking -- Fact or Fiction
http://www.garlic.com/~lynn/2010l.html#55 Mainframe Hacking -- Fact or Fiction

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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


Re: Mainframe hacking?

2010-10-14 Thread Lindy Mayfield
The whole point, I think, is to get it by the system's guys.  Not sure how to 
do that.  So much easier on Windows.  Still there are coming more and more 
"freeware" MVS utilities, like showmvs.  (It can run authorized I think, yes?)  
I don't think that it is that carefully audited, somebody could slip something 
into there.  Or some ported tool like TSOCMD.  

It would be very unlikely that something like that would get by you guys, but 
good sysprogs are getting fewer and fewer, and, as an inside job perhaps, 
someone may easily trick an admin into installing some useful utility that has 
been compromised.



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Cole
Sent: Thursday, October 14, 2010 7:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

At 10/14/2010 12:24 PM, Chris Craddock wrote:
>(as Bob knows) it is impossible to create/install a malicious FLIH or 
>SVC or PC without already having the keys to the kingdom anyway.
>That is the foundation of integrity and the reason why the installation 
>has to appropriately protect system datasets and APF libraries.

Well that's just the problem, Chris, isn't it... The keys to the kingdom really 
are not well guarded. That's what my 2006 post was all about.

--
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


Re: Mainframe hacking?

2010-10-14 Thread David Cole

At 10/14/2010 12:24 PM, Chris Craddock wrote:
(as Bob knows) it is impossible to create/install a malicious FLIH 
or SVC or PC without already having the keys to the kingdom anyway. 
That is the foundation of integrity and the reason why the 
installation has to appropriately protect system datasets and APF libraries.


Well that's just the problem, Chris, isn't it... The keys to the 
kingdom really are not well guarded. That's what my 2006 post was all about.




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
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


Re: Mainframe hacking?

2010-10-14 Thread Anne & Lynn Wheeler
... oh, and the software company (front for criminal organization)
apparently was selected on the basis of being the low bidder.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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


Re: Mainframe hacking?

2010-10-14 Thread Ricc Harding
Yes Ed, these sites all had RACF installed and yes, it still required the
VTOC "data set is RACF protected bit" to be flipped for the data set
protection call to even be made. The needed resource manager calls became
more apparent as the resources which were being protected grew.  The ACF2
"protectall" vs RACF "protectnone" philosophy soon became the guiding light
to making RACF actually usable as a security system by also implementing
"protectall". 

However APF authorization still allows the keys to the kingdom with no trace
for the clever programmer. And vendor PC calls are now the new point of
entry for system penetration attempts since they have all but replaced most
of the user written SVC's.

The landscape changes but the dirt is still the same.  The new hacker's
lament might be "so many entry points to choose from and so little time to
play". Vigilance and automation in security checking are the keys to
catching the silly things but the "clever programmer" still must have the
integrity and character to NOT do what they have both the ability and
opportunity to do.

Quis custodiet ipsos custodes

--
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


Re: Mainframe hacking?

2010-10-14 Thread Ray Overby
 The "returning in an authorized state" ones are exactly that. The 
others are typically the result of poor coding and/or design.

On 10/14/2010 11:43 AM, Lindy Mayfield wrote:

Some of this sounds like the "magic svcs" that I've seen people use for 
"testing".

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: Thursday, October 14, 2010 6:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

   -Some code that is executing in an authorized state
  - Supervisor state
  - PSW key 0-7
  - Ability to issue MODESET SVC (APF authorized)

-This code would have one of the following flaws:
  - Store into requester provided storage address while in an 
authorized state (usually means running in a system psw key (0-7))
  - Branch to a requester provided storage address
  - Returning control to the requester in an authorized state

SVCs, PC routines, and system exits all would have this potential.

On 10/14/2010 10:43 AM, Lindy Mayfield wrote:

What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
functionality?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of David Cole
Sent: Thursday, October 14, 2010 5:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?


I read that article, and it is a good one. Interestingly (to me at least), on 
the article's third web page, there is an excerpt from a post I made here in 
2006. It's nice to know that someone is paying attention.

My entire post can be found at:
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F2
3465267AA41&Y=dbcole%40colesoft.com

I think the information in that post are highly relevant to the current thread.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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


--
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

--
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



--
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


Re: Mainframe hacking?

2010-10-14 Thread Lindy Mayfield
Some of this sounds like the "magic svcs" that I've seen people use for 
"testing".

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: Thursday, October 14, 2010 6:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

  -Some code that is executing in an authorized state
 - Supervisor state
 - PSW key 0-7
 - Ability to issue MODESET SVC (APF authorized)

-This code would have one of the following flaws:
 - Store into requester provided storage address while in an authorized 
state (usually means running in a system psw key (0-7))
 - Branch to a requester provided storage address
 - Returning control to the requester in an authorized state

SVCs, PC routines, and system exits all would have this potential.

On 10/14/2010 10:43 AM, Lindy Mayfield wrote:
> What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
> functionality?
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
> Behalf Of David Cole
> Sent: Thursday, October 14, 2010 5:08 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe hacking?
>
>
> I read that article, and it is a good one. Interestingly (to me at least), on 
> the article's third web page, there is an excerpt from a post I made here in 
> 2006. It's nice to know that someone is paying attention.
>
> My entire post can be found at:
> http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F2
> 3465267AA41&Y=dbcole%40colesoft.com
>
> I think the information in that post are highly relevant to the current 
> thread.
>
> Dave Cole  REPLY TO: dbc...@colesoft.com
> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow RoadVOICE:540-456-8536
> Afton, VA 22920FAX:  540-456-6658
>
> --
> 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
>

--
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

--
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


Re: Mainframe hacking?

2010-10-14 Thread Bill Fairchild
I would think it means code that front-ends one of the First Level Interrupt 
Handlers, rather like the one that CA was using in 1996 (are they still using 
it?) to front-end program interrupts so that various CA products could easily 
become authorized by merely executing a particular invalid operation code.  
Doing this in the program FLIH made disassembling their code a little tricky, 
because the program new interrupt routine runs with DAT off, so it was not a 
no-brainer to find and display their code in storage.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Lindy Mayfield
Sent: Thursday, October 14, 2010 10:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?

What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
functionality?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Cole
Sent: Thursday, October 14, 2010 5:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?


I read that article, and it is a good one. Interestingly (to me at least), on 
the article's third web page, there is an excerpt from a post I made here in 
2006. It's nice to know that someone is paying attention.

My entire post can be found at: 
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com

I think the information in that post are highly relevant to the current thread.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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

--
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


Re: Mainframe hacking?

2010-10-14 Thread Anne & Lynn Wheeler
d...@lists.duda.com (David Andrews) writes:
> You could stay up all night typing in random subscriber IDs to see what
> you would get.  It didn't take long to discover that the first three
> digits of a subscriber ID was the telephone area code of the subscriber.
> That cut down on the search space quite a bit.  Area code 212 (New York
> City) was a target-rich environment!

re:
http://www.garlic.com/~lynn/2010n.html#73 Mainframe hacking

in 90s and there were summaries of wardialing ... dialing every number
in an area code/region ... looking for modems ... and then taking
signatures of the modems & the connected systems (some areas had 3% of
numbers with some sort of modem connection).

in the late 90s, with the PDD-63
http://en.wikipedia.org/wiki/Critical_Infrastructure_Protection

there was some amount spent in the financial industry meetings (in the
white house annex) about Y2K remediation ... but a really hot topic was
the ISACs (information sharing database of vulnerabilities and exploits)
... which had bunch of stuff ... a lot with mainframe dataprocessing
... since a lot of financial industry is mainframe based.  Of major
concern (and a lot of discussion) was constructing the ISAC in such a
way that it wouldn't be subject to FOIA
http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29

Financial ISAC website
http://www.fsisac.com/

launced in 1999
http://www.fsisac.com/faq/

since 9/11 ... public facing tends to be much more about terrorists

I was tangentially involved with the (original) cal. data breach
notification act ... having been brought in to help wordsmith the
electronic signature legislation. Several of the participants were
heavily involved with consumer privacy issues and had done detailed,
indepth surveys and found that the NO.1 issue was "identity theft",
namely the "accound fraud" form where cardholder details from data
breach was being used by criminals for fraudulent financial
transactions.

The issue at the time was that little or nothing appeared to being done
about the problem (not even being publicized) ... so they seemed to
think that the publicity from databreach notifications might motivate
the institutions to provide corrective actions and countermeasures.

A major issue was that institutions will put in place security measures
to counteract bad things (risks) happending to the institutions. The
problem with the "account fraud" scenario ... is that typically the
"fraudulent financial transactions" were against consumer accounts
... not against the institution ... and therefor the institutions had
nothing at risk and therefor little motivation to provide security.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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


Re: Mainframe hacking?

2010-10-14 Thread Ray Overby

 -Some code that is executing in an authorized state
- Supervisor state
- PSW key 0-7
- Ability to issue MODESET SVC (APF authorized)

-This code would have one of the following flaws:
- Store into requester provided storage address while in an 
authorized state (usually means running in a system psw key (0-7))

- Branch to a requester provided storage address
- Returning control to the requester in an authorized state

SVCs, PC routines, and system exits all would have this potential.

On 10/14/2010 10:43 AM, Lindy Mayfield wrote:

What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
functionality?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Cole
Sent: Thursday, October 14, 2010 5:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?


I read that article, and it is a good one. Interestingly (to me at least), on 
the article's third web page, there is an excerpt from a post I made here in 
2006. It's nice to know that someone is paying attention.

My entire post can be found at:
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com

I think the information in that post are highly relevant to the current thread.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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



--
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


Re: Mainframe hacking?

2010-10-14 Thread Lindy Mayfield
What would constitute a "root kit" for MVS?  Perhaps an SVC with some hidden 
functionality?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Cole
Sent: Thursday, October 14, 2010 5:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Mainframe hacking?


I read that article, and it is a good one. Interestingly (to me at least), on 
the article's third web page, there is an excerpt from a post I made here in 
2006. It's nice to know that someone is paying attention.

My entire post can be found at: 
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com

I think the information in that post are highly relevant to the current thread.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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


Re: Mainframe hacking?

2010-10-14 Thread David Cole

At 10/13/2010 10:26 AM, Greg Shirey wrote:

I liked this article, and it's fairly recent.  (Jan 2010)

http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1

Greg


I read that article, and it is a good one. Interestingly (to me at 
least), on the article's third web page, there is an excerpt from a 
post I made here in 2006. It's nice to know that someone is paying attention.


My entire post can be found at: 
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com


I think the information in that post are highly relevant to the 
current thread.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
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


Re: Mainframe hacking?

2010-10-14 Thread David Andrews
On Wed, 2010-10-13 at 18:38 -0400, Rick Fochtman wrote:
> I ALWAYS left the IBMUSER active on the system but the first thing I 
> also did was to change to password to some very obscure value.

A *very* long time ago, before a few ibm-mainers were born, there was an
early public-access packet switching network named "Telenet".  You could
point your modem at a local phone number, type in the five-or-six digit
number of a Telenet subscriber, and be connected to their system
wherever it may be.

You could stay up all night typing in random subscriber IDs to see what
you would get.  It didn't take long to discover that the first three
digits of a subscriber ID was the telephone area code of the subscriber.
That cut down on the search space quite a bit.  Area code 212 (New York
City) was a target-rich environment!

There were a fair number of TSO systems that were Telenet-attached, and
some of those had IBMUSER accounts with default or stupid passwords.

(That particular complacency wasn't limited to MVS administrators.
There were other systems, foreign to me, which permitted easy access.)

No, I never stayed long; got the heck OUT of there in fact.  Login...
holy $#!+... logoff.  What were they thinking?

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

--
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


Re: Mainframe hacking?

2010-10-14 Thread Lindy Mayfield
I didn't see anyone explicitly mention "social engineering".  IMO this may be 
an easier way to get a not-very-technical user's id, but then you are back to 
how to hack with a "normal" user TSO account.  But if a system guy gave out a 
password for an reason then, well, you know.

What about digging through the trash?  Dropping some USB sticks around with 
interesting programs on them?  

A few people mentioned some few months back how to get a program authorized 
from a non-authorized library (or something like that), but nobody gave any 
details.

For sure no script kiddies should ever get in, and if they did they wouldn't 
know what to do.

One thing I didn't see in this thread, was what is the purpose of this hacking. 
  What is to be gained?  Sensitive information would be one thing I can think 
of.

Lindy

--
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


Re: Mainframe hacking?

2010-10-14 Thread Itschak Mugzach
Done that many times during security assessments at customers sites. for
example, Look at your SYS1.UADS dataset and compare it to RACF. You probably
will find users that are defined in your UADS dataset, but not in RACF. More
then that, IBM's ships UADS dataset with few users that probably not defined
in your racf... There are many other ways we use, but this is not the proper
place to discuss them ;-)

ITschak



On Thu, Oct 14, 2010 at 7:14 AM, Ron Hawkins
wrote:

> Ed,
>
> Your dates may be a little out. The site where I was an Operator turned on
> RACF in 1983. I remember because we were able to browse SYS1.UADS and get
> everyone's passwords after the conversion.
>
> Ron
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of
> > Ed Gould
> > Sent: Wednesday, October 13, 2010 9:17 PM
> > To: IBM-MAIN@bama.ua.edu
>  > Subject: Re: [IBM-MAIN] Mainframe hacking?
> >
> > --- On Wed, 10/13/10, Ricc Harding  wrote:
> >
> > From: Ricc Harding 
> > Subject: Re: Mainframe hacking?
> > To: IBM-MAIN@bama.ua.edu
> > Date: Wednesday, October 13, 2010, 3:56 PM
> >
> > When I worked for a large computer manufacturing company in 1984, I would
> go
> >
> > ---SNIP-
> > Were the shops using any security product ie RACF/ACF2/Top Secret ?I
> suspect
> > at that point in time they probably did not. I certainly did not know of
> any
> > installations that were using them, except perhaps 1 and I think that one
> got
> > the ACF/2 free (UIC). Also I think at that time from my rather poor
> memory
> was
> > that even with a security package the systems were just not locked as
> they
> > should have been. Somewhere in the late 80's (if memory serves me)
> companies
> > really got serious about security.
> > Of course if people posted the passwords with stickem notes then all bets
> are
> > off on any security package. My vague recollection is that the first few
> years
> > of RACF were pretty bad (for security) I just remember hearing people
> saying
> > RACF can't ddo this or that and * could. My impression of these
> complaints
> > were at best poor as even the product that claimed to be able to do the
> > requested item was at best iffy and was very prone PTF retrofits and zaps
> on
> > top of IBM modules. I am not so much as defending RACF (or any of the
> other
> > products) as saying IBM had not put in SAF entirely every where it needed
> to
> > go. I guess I would make this statement as far as any security product.
> If
> IBM
> > doesn't make the insertion of the SAF call trying to insert any vendors
> codes
> > is doomed to failue.
> > Ed
> >
> >
> >
> >
> >
> > --
> > 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
>
> --
> 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
>

--
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


Re: Mainframe hacking?

2010-10-14 Thread Brian Westerman
Yes.  Like one of the previous posters to this thread the company I work for
used to offer a "service" of "testing the site's defenses" that we called a
"System Access Security Audit" (SASA).  

This audit was completely unlike our normal System Audit which we still
perform.  The current System Audit checks the entire system (including
security) for problems, performance issues, etc. and offers a lot of advice
on what can be done to make things better, but the SASA's weren't concerned
with fixing anything, just getting in and obtaining physical proof that we
were there.  I think we performed a little over 100 of them, and we were
NEVER unsuccessful.  

As you can imagine, we didn't always/ever play by the "Marquis of Queensbury
rules", actually there were NO rules, but as I said, we were ALWAYS
successful.  After we had the first few under our belt, we even offered the
sites a "deal" up front where they could choose and option that would get
them the audit for free if we were unsuccessful, but pay a "premium price"
for the SASA if we were successful.  No sites ever took us up on the "double
or nothing" option.

I'm not saying that it was always easy to gain access, but I can't really
say that it was overly difficult either.  The easiest ones were those that
we were allowed (or obtained) physical access to the site.

On the other hand, a good portion of the code for VTAM, NCP, SNA and TCP
(and several of the main subsystems (CICS, IMS, etc.)) was developed with
the help of the people on the team.  My expertise came into play once we got
access to the hardware via one of the installed teleprocessing systems.  

Does what we did constitute hacking?  I guess it depends on how you look at
it.  We never destroyed anything (at least not something that we couldn't
fix).  We didn't do it for free, and no small animals were harmed in the
process.  Several people were VERY unhappy with finding out they were
vulnerable but I don't think anyone was ever fired for it.  

I think what may have upset people most was that we had to tell them that
(except for the places that were really screwed up and did something really
dumb like left terminals already signed on and open for us) there was almost
nothing they could do about making it COMPLETELY secure in the future.  No
one wants to pay that much, find out they really ARE vulnerable and then be
told that, short of shutting off their network and just running BATCH jobs,
(although depending on their hardware service vendor and options even that
would get us access to their physical tape and DASD hardware), that we would
have gotten in and exposed their data regardless of what they did, or will
do, in the future.  It's not that we didn't show a huge number of places
that they COULD make significant changes and improvements that would make it
less vulnerable, but time and resources were always on our side.  

Remember, it's not like the casual teenage kid with a modem and Wii or a
PS/3 is going to have a chance of getting in.

I was happy when we finally stopped (in 2008) offering the "service", it was
not exactly what one would term "exciting". 

Brian

--
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


Re: Mainframe hacking?

2010-10-13 Thread Ron Hawkins
Ed,

Your dates may be a little out. The site where I was an Operator turned on
RACF in 1983. I remember because we were able to browse SYS1.UADS and get
everyone's passwords after the conversion.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Ed Gould
> Sent: Wednesday, October 13, 2010 9:17 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Mainframe hacking?
> 
> --- On Wed, 10/13/10, Ricc Harding  wrote:
> 
> From: Ricc Harding 
> Subject: Re: Mainframe hacking?
> To: IBM-MAIN@bama.ua.edu
> Date: Wednesday, October 13, 2010, 3:56 PM
> 
> When I worked for a large computer manufacturing company in 1984, I would
go
> 
> ---SNIP-
> Were the shops using any security product ie RACF/ACF2/Top Secret ?I
suspect
> at that point in time they probably did not. I certainly did not know of
any
> installations that were using them, except perhaps 1 and I think that one
got
> the ACF/2 free (UIC). Also I think at that time from my rather poor memory
was
> that even with a security package the systems were just not locked as they
> should have been. Somewhere in the late 80's (if memory serves me)
companies
> really got serious about security.
> Of course if people posted the passwords with stickem notes then all bets
are
> off on any security package. My vague recollection is that the first few
years
> of RACF were pretty bad (for security) I just remember hearing people
saying
> RACF can't ddo this or that and * could. My impression of these
complaints
> were at best poor as even the product that claimed to be able to do the
> requested item was at best iffy and was very prone PTF retrofits and zaps
on
> top of IBM modules. I am not so much as defending RACF (or any of the
other
> products) as saying IBM had not put in SAF entirely every where it needed
to
> go. I guess I would make this statement as far as any security product. If
IBM
> doesn't make the insertion of the SAF call trying to insert any vendors
codes
> is doomed to failue.
> Ed
> 
> 
> 
> 
> 
> --
> 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

--
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


Re: Mainframe hacking?

2010-10-13 Thread Ed Gould
--- On Wed, 10/13/10, Ricc Harding  wrote:

From: Ricc Harding 
Subject: Re: Mainframe hacking?
To: IBM-MAIN@bama.ua.edu
Date: Wednesday, October 13, 2010, 3:56 PM

When I worked for a large computer manufacturing company in 1984, I would go

---SNIP-
Were the shops using any security product ie RACF/ACF2/Top Secret ?I suspect at 
that point in time they probably did not. I certainly did not know of any 
installations that were using them, except perhaps 1 and I think that one got 
the ACF/2 free (UIC). Also I think at that time from my rather poor memory was 
that even with a security package the systems were just not locked as they 
should have been. Somewhere in the late 80's (if memory serves me) companies 
really got serious about security. 
Of course if people posted the passwords with stickem notes then all bets are 
off on any security package. My vague recollection is that the first few years 
of RACF were pretty bad (for security) I just remember hearing people saying 
RACF can't ddo this or that and * could. My impression of these complaints 
were at best poor as even the product that claimed to be able to do the 
requested item was at best iffy and was very prone PTF retrofits and zaps on 
top of IBM modules. I am not so much as defending RACF (or any of the other 
products) as saying IBM had not put in SAF entirely every where it needed to 
go. I guess I would make this statement as far as any security product. If IBM 
doesn't make the insertion of the SAF call trying to insert any vendors codes 
is doomed to failue.
Ed





--
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


Re: Mainframe hacking?

2010-10-13 Thread Rick Fochtman

-

I'm getting into a rather heated argument with a non mainframe colleague  about 
whether the mainframe has been hacked or not. Legitimate hacking,  not a 
disgruntled employee doing something illegal and not loss of tapes or other 
media. I'm talking the mainframe platform. Thoughts?


M. McHenry
Pittsburgh, Pa.
 


-
I've never seen an actual illicit entry into a mainframe z/OS, MVS or 
OS/390 system, although I've seen several "Denial of Service" attacks.


They didn't actually get into the system but they prevented legitimate 
entry.


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


Re: Mainframe hacking?

2010-10-13 Thread Rick Fochtman

--

In the old days some shops left the IBMUSER Id active on the system. I'm sure that such incompetence still exists. With TCP/IP, USS, Java, and a billion or so hackers worldwide, the risks are higher than ever. 
 


-
I ALWAYS left the IBMUSER active on the system but the first thing I 
also did was to change to password to some very obscure value. Which was 
never revealed to ANYONE.


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


Re: Mainframe hacking?

2010-10-13 Thread Ricc Harding
When I worked for a large computer manufacturing company in 1984, I would go
with their corporate audit team to attempt to penetrate their in house MVS
systems. We would, depending on the site managers wishes, either attempt to
access critical data from normal TSO userid's, or we would attempt to access
the mainframe without any TSO id's given to us. In the case of working
without any TSO id's we still had physical access to terminals and
programmers offices, so unlocked desks and trash cans were fair game. In 8
audits of sites all over the world, we never failed to gain access to
critical data.  The ways in which we penetrated the systems lead to many of
the changes implemented in the way RACF was suggested to be used. We also
had lists of hundreds of ways to penetrate the system from unauthorized
userids, using "clever" attacks and unprotected control elements or
restricted utilities. Since 1984 the list of areas that can be exploited to
gain access to data, both protected and unprotected,  has grown
proportionally and though the systems can be secured much more tightly now,
any system that is accessible by users who are not inside a secured area, in
my humble opinion, can be hacked, if you define hacked as gaining
unauthorized access to sensitive data. We sometimes sat down with dumps and
disassembled user written SVC's and exit modules to exploit programming
errors. A patient hacker can gain access eventually. I think, the time,
knowledge, and effort to do this today, is simply not worth the potential
penalties when caught after the fact IMHO. Those who have the knowledge to
do the break in's are usually employed in positions to stop the break in's.
but with zIIP's and IFL's and zAAP's there are just getting to be so many
places to keep track of

--
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


Re: Mainframe hacking?

2010-10-13 Thread Ray Overby
- I am aware of integrity exposures (violations of the IBM statement of 
integrity) on the latest release(s) of z/OS, in fact, the software I use 
has found many on the latest releases of z/OS and ISV products.


- Exploits based upon these integrity exposures would be successful 
(i.e. - access allowed, no audit trail of activity)


- This would require access to z/OS (inside attack), and would take some 
sophistication to develop an exploit, but the use of the exploit would 
not take any sophisticated knowledge. In one case, for a vulnerability 
my software found in an ISV product, I was able to develop an 11 line 
REXX Exec that could be executed from TSO and give the user RACF 
Privileged access. That is access to any dataset on the system with no 
security system SMF records being generated.


- The fact that this exploit would require "insider" status is not 
something that should be dismissed because a 2008 Strategic Counsel 
survey, commissioned by CA, found that the percentage of internal 
attacks is increasing -- from 15% of all breaches in 2003, to 42% in 
2006, to 44% in 2008. And in a 2010 PacketMotion Survey of US Government 
Agency Representatives, 59% felt that employees were the biggest threat!


- The fact that the "successful hacks" were not publicized does not 
surprise me. My experience is that "successful hack" information is 
closely guarded and not disclosed. Organizations do not want it known 
that they have been successfully attacked.


- I have a lot more information on my website: www.vatsecurity.com 
 and information on the software I have 
developed, the Vulnerability Analysis Tool, which does a vulnerability 
scan on z/OS systems and finds many, many z/OS and ISV system integrity 
vulnerabilities.


Ray Overby
Key Resources, Inc.
Ray.Overby.kr-inc.com


On 10/13/2010 09:26 AM, Greg Shirey wrote:

I liked this article, and it's fairly recent.  (Jan 2010)

http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1

Greg


Joe Mc wrote:


I'm getting into a rather heated argument with a non mainframe
colleague

about whether the mainframe has been hacked or not. Legitimate hacking,
not a disgruntled employee doing something illegal and not loss of tapes
or other media. I'm talking the mainframe platform. Thoughts?

--
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




--
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


Re: Mainframe hacking?

2010-10-13 Thread Anne & Lynn Wheeler
joe.m...@yahoo.com (Joe Mc) writes:
> I'm getting into a rather heated argument with a non mainframe
> colleague about whether the mainframe has been hacked or
> not. Legitimate hacking, not a disgruntled employee doing something
> illegal and not loss of tapes or other media. I'm talking the
> mainframe platform. Thoughts?

once I took the bait on such a taunt

prior to virtual memory being announced for 370 ... an internal document
found its way into the hands of somebody from the press (sort of a
corporate pentagon papers thing). there was big investigation and
afterwards all the corporate copiers were retrofitted with an
(unique) ID-tag that would show up on every page copied. for an
example see the bottom of each of these scanned pages from
gray presentation
http://www.garlic.com/~lynn/grayft84.pdf

somewhat as a result, the future system project (was going to replace
all 370, as different from 360/370 as 360 had been different from prior
generations) went to vm370-based software copy documents ... with some
additional security features added to vm370s that hosted the future
system documents. misc. past posts mentioning future system
http://www.garlic.com/~lynn/submain.html#futuresys

One weekend I had some benchmark time in machine room that contained one
such vm370 ... and some of the people responsible (for special security
addons supporting super-secure softcopy future system documents) taunted
that even if I was left alone in the machine room ... I still wouldn't
be able to access the documents. I countered that it would take less
than five minutes ... most of the time was making sure the system was
disabled from any access external to the machine room ... and then I
flipped a bit in storage ... so anything/everything entered was accepted
as valid password.

old reference to use of virtual machine systems for security ... of
course, I didn't learn about these guys until much later:
http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

as to virus ... there is xmas that occured on bitnet almost exactly a
year before morris worm on internet. bitnet was corporate sponsored
higher educational network ... using similar technology to that
used in the (mostly vm370 based) internal network (which was larger
than the arpanet/internet from just about the beginning until possibly
late 85 or early 86) ... misc. past posts mentioning bitnet (&/or EARN)
http://www.garlic.com/~lynn/subnetwork.html#bitnet
misc. past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

reference from vmshare archives
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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


Re: Mainframe hacking?

2010-10-13 Thread John P. Baker
Joe,

I am not aware of any successful attack on a mainframe system as a result of
a software defect.

I am aware of some cases where access was gained to a system by virtue of
not changing the default password on a system-supplied userid.

I am also aware of some cases where an employee / former employee divulged
information permitting an unauthorized person to gain access to a system.

John P. Baker
Chief Software Architect
HFD Technologies

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Joe Mc
Sent: Wednesday, October 13, 2010 8:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Mainframe hacking?

I'm getting into a rather heated argument with a non mainframe colleague
about whether the mainframe has been hacked or not. Legitimate hacking,  not
a disgruntled employee doing something illegal and not loss of tapes or
other media. I'm talking the mainframe platform. Thoughts?

M. McHenry
Pittsburgh, Pa. 

--
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


Re: Mainframe hacking?

2010-10-13 Thread Greg Shirey
I liked this article, and it's fairly recent.  (Jan 2010)  

http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1

Greg 


Joe Mc wrote:

>I'm getting into a rather heated argument with a non mainframe 
>colleague
about whether the mainframe has been hacked or not. Legitimate hacking,
not a disgruntled employee doing something illegal and not loss of tapes
or other media. I'm talking the mainframe platform. Thoughts?

--
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


Re: Mainframe hacking?

2010-10-13 Thread Ken Porowski
"I am told that intrusion reporting has been mandated by law for several
years."

Of the specifics or just the result?

I would think that if there had been a successful crack due to software
limitations (i.e. bug) we would have seen a fix via "Red Alert".

A successful crack via a configuration lapse (incorrect/incomplete setup
etc.) is another thing and IIRC there is/were RedBooks/White
Papers/SHARE sessions and the ever popular consulting firms that may
address/specify the most likely issues. 

-Original Message-
Hal Merritt

If you mean gaining access to sensitive MF data, then yes there have
been several reports. 

The successful attack vectors were (trusted?) Windows servers.  

If you mean gaining access directly, then I personally have not seen any
credible reports. I am told that intrusion reporting has been mandated
by law for several years. 
 
-Original Message-
Joe Mc

I'm getting into a rather heated argument with a non mainframe colleague
about whether the mainframe has been hacked or not. Legitimate hacking,
not a disgruntled employee doing something illegal and not loss of tapes
or other media. I'm talking the mainframe platform. Thoughts?

M. McHenry
Pittsburgh, Pa.

--
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


Re: Mainframe hacking?

2010-10-13 Thread Ken Porowski
Although it is an intrusion (with serious consequences) I wouldn't count
guessing a userid/password a crack.  Likewise gaining access by cracking
an attached squatty box. 

Gaining access programmatically/directly is another issue. 

-Original Message-
Elardus Engelbrecht

Joe Mc wrote:

>I'm getting into a rather heated argument with a non mainframe 
>colleague
about whether the mainframe has been hacked or not. Legitimate hacking,
not a disgruntled employee doing something illegal and not loss of tapes
or other media. I'm talking the mainframe platform. Thoughts?

What mainframe platform? I'm serious, because 'mainframe' is ambigious.

For z/OS, *cracking* into it may be difficult. But see [1] below.

With 3270 emulator, 'hacking' *could* be possible by installing 'screen
scraper' 
and/or keystroke logger software.

Did that happened? Hmmm, good question.

If you do bad design on your web pages hosted by, for example WebSphere,
some bad*ss could overwrite your page(s) with some nasty message(s) like
this one: 'A L33T was here.'

So in theory, it is possible, but if you can get me real practical
incident(s) [2], I would really like to find out about it.

[1] - There are 'tiger team' companies who can *hack* or *crack* upon
request and after paying a fee.

[2] - Real incidents, not some rotten fruits from lame bored reporter.

Groete / Greetings
Elardus Engelbrecht

--
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


Re: Mainframe hacking?

2010-10-13 Thread Hal Merritt
If you mean gaining access to sensitive MF data, then yes there have been 
several reports. 

The successful attack vectors were (trusted?) Windows servers.  

If you mean gaining access directly, then I personally have not seen any 
credible reports. I am told that intrusion reporting has been mandated by law 
for several years. 


 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe Mc
Sent: Wednesday, October 13, 2010 7:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Mainframe hacking?

I'm getting into a rather heated argument with a non mainframe colleague  about 
whether the mainframe has been hacked or not. Legitimate hacking,  not a 
disgruntled employee doing something illegal and not loss of tapes or other 
media. I'm talking the mainframe platform. Thoughts?

M. McHenry
Pittsburgh, Pa.


 
  
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
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


Re: Mainframe hacking?

2010-10-13 Thread Elardus Engelbrecht
Joe Mc wrote:

>I'm getting into a rather heated argument with a non mainframe colleague  
about whether the mainframe has been hacked or not. Legitimate hacking,  
not a disgruntled employee doing something illegal and not loss of tapes or 
other media. I'm talking the mainframe platform. Thoughts?

What mainframe platform? I'm serious, because 'mainframe' is ambigious.

For z/OS, *cracking* into it may be difficult. But see [1] below.

With 3270 emulator, 'hacking' *could* be possible by installing 'screen 
scraper' 
and/or keystroke logger software.

Did that happened? Hmmm, good question.

If you do bad design on your web pages hosted by, for example WebSphere, 
some bad*ss could overwrite your page(s) with some nasty message(s) like 
this one: 'A L33T was here.'

So in theory, it is possible, but if you can get me real practical incident(s) 
[2], 
I would really like to find out about it.

[1] - There are 'tiger team' companies who can *hack* or *crack* upon 
request and after paying a fee.

[2] - Real incidents, not some rotten fruits from lame bored reporter.

Groete / Greetings
Elardus Engelbrecht

--
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


Re: Mainframe hacking?

2010-10-13 Thread George Rodriguez
I can say that someone has tried to hack us, but has been unsuccessful.
Here's what happens, the hacker gets an IP address and a userid, but as of
today the most that has happened is that the userid being used is  revoked.
We see the messages on SYSLOG and the IP address coming in is then blocked
at the firewall.

*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Six Consecutive Years*



On Wed, Oct 13, 2010 at 8:18 AM, Joe Mc  wrote:

> I'm getting into a rather heated argument with a non mainframe colleague
>  about
> whether the mainframe has been hacked or not. Legitimate hacking,  not a
> disgruntled employee doing something illegal and not loss of tapes or other
> media. I'm talking the mainframe platform. Thoughts?
>
> M. McHenry
> Pittsburgh, Pa.
>
>
>
> --
> 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
>
>

Home of Florida's first LEED Gold Certified School

Under Florida law, e-mail addresses are public records. If you do not want your 
e-mail address
released in response to a public records request, do not send electronic mail 
to this entity. 
Instead, contact this office by phone or in writing.

--
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


Re: Mainframe hacking?

2010-10-13 Thread Bob Shannon
> whether the mainframe has been hacked or not

Well, do you really think either IBM or a customer would admit that a mainframe 
system had been hacked? 

In the old days some shops left the IBMUSER Id active on the system. I'm sure 
that such incompetence still exists. With TCP/IP, USS, Java, and a billion or 
so hackers worldwide, the risks are higher than ever. 

Bob Shannon
Rocket Software 

--
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


Re: Mainframe hacking?

2010-10-13 Thread McKown, John
If you mean a total outsider, __cracking__ into a z/OS or z/VM or z/VSE system 
using some sort of Internet connection, then I've not heard of such a thing. 
However, given that the vast majority of successful cracking attacks are never 
reported, the likelihood of a company telling the world that their z mainframe 
was cracked makes winning the PowerBall look like a cinch.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Mc
> Sent: Wednesday, October 13, 2010 7:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Mainframe hacking?
> 
> I'm getting into a rather heated argument with a non 
> mainframe colleague  about 
> whether the mainframe has been hacked or not. Legitimate 
> hacking,  not a 
> disgruntled employee doing something illegal and not loss of 
> tapes or other 
> media. I'm talking the mainframe platform. Thoughts?
> 
> M. McHenry
> Pittsburgh, Pa.
> 
> 
> 
> --
> 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
>   
> 
> 

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Mark Zelden
On Fri, 7 Aug 2009 16:08:39 -0500, Chris Mason  wrote:

>Mark
>
>If you enter IBMTEST when the SNA LU is in the SSCP-LU - as opposed to the
>LU-LU state - and the LU is supported by Unformatted System Services
>(USS), the SSCP (VTAM) will "echo" back to you whatever you have specified
>as the second positional operand the number of times you specify as the first
>positional operand on the IBMTEST command.
>


Really?  




>
>>>And if nobody but Chris understands what I just said, well, that's
>>>fine.
>>>
>>>Pat O'Keefe
>>>
>>
>>
>>I have no idea what you are talking about.
>>
>>Regards,
>>
>>IBMECHO ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
>

It was a joke!   Of course I knew exactly what Pat was talking about otherwise
why would I written my "regards" the way I did.

I guess I could have used a smiley face but I thought it was obvious to anyone
who did understand.

BTW, when I wrote "why can't uss all get along" in the other thread (or was
it part of this one), that was a joke too.  But I did include the smiley face
with that post.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Patrick O'Keefe
On Fri, 7 Aug 2009 17:26:54 -0400, Thompson, Steve 
 wrote:

>...
>It is also a problem that some time after 1991, the IBM internal
>standards were apparently discarded (apparently with management
>blessing). There were specific naming standards, specific requirements
>for program directories (and their very specific formatting), etc.
>...  

I'm afraid you are right.  There was a time when unexpected 
behavior could be flagged INCORROUT and a design could be just 
as defective as code.  (I don't know if that was ever an official
policy, but it seemed to be the way Service worked.)  But that
was back when IBM had people around to fix problems.  A lot of
those people have retired, moved to other positions, become 
"suits", etc.
 
In the past I've argued myself blue in the face of Broken as
Designed issues.  (Not "problems".  Just ask IBM.  Can't be a 
"problem" if it's working as designed.)   But now that all the
development, change, and level 2 support teams have evaporated,
and now that my technical relationships with some of  those left 
have been replaced by friendships,  I tend to take less strident
tone.

Submit a Requirement.  No, you shouldn't have to, but the lone 
developer where there used to be 10 is going to be working on 
high priority changes (when he's not stolen by Service to work 
on a Sev 1 bug).   Even if you get them to accept a PMR it's going
to a Sev 3; your grand children may see the PTF.  So submit a
Requirement for it.  (I'm  a lot more comfortable  saying that now
that I'm no longer the Requirements Coordinator for SHARE's 
Networking program.)

Pat O'Keefe

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Chris Mason
Ted

I suspect you don't think it's carelessness because some IBMers - and some 
list participants - imagine they are entitled to misuse USS for UNIX System 
Services. That - as the reason this whole (set of) threads got started 
demonstrates - betrays another type of carelessness, the type indeed that 
gave rise to the unnecessary comment in the post with dateline "Wed, 15 Jul 
2009 22:33:38 -0700" and which set the mood.

Chris Mason

On Fri, 7 Aug 2009 21:12:03 +, Ted MacNEIL  
wrote:

>>Ted
>
>>> Even IBM used USS ...
>
>>Sadly, some IBMers are as careless as some list participants.
>
>I DON'T think it's carelessness!

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Thompson, Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Friday, August 07, 2009 4:12 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: USS misuse (was Re: Mainframe hacking)

>Ted

>> Even IBM used USS ...

>Sadly, some IBMers are as careless as some list participants.

I DON'T think it's carelessness!n
-
Too busy driving to stop for gas!



It either is, or they are at best, not competent (here is where I have
to explain this: Not competent does not imply you can't be only that you
need some training, Incompetent means you may have been but now
definitely aren't).

It is also a problem that some time after 1991, the IBM internal
standards were apparently discarded (apparently with management
blessing). There were specific naming standards, specific requirements
for program directories (and their very specific formatting), etc. 

Even the keywords to be used for ETR/PMR and APAR/PTF are being sluffed,
which is making it difficult to find HIPERs at times. 

A recent example: any one *directly* affected by the recent double
writes within TCPIP. If you had searched using INCORROUT you came up
empty. Yet that is what was happening - In Correct Output. This is but
one formerly STANDARD keyword. The rules are changing w/o equivalent buy
in or announcement of the changes. Rather like the non-mainframe
platforms, the Whatever boxen (example of the Whatever is given by
Shania Twain in That Don't Impress me). 

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those of poster's
employer --

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Ted MacNEIL
>Ted

>> Even IBM used USS ...

>Sadly, some IBMers are as careless as some list participants.

I DON'T think it's carelessness!n
-
Too busy driving to stop for gas!

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Chris Mason
Ken

Unless I've misunderstood, I would not expect the early Monday morning 
terminal user to much bothered by the IBMTEST command. It's one of those 
things to which the famous phrase attributed to Michael Caine by Peter 
Sellers, "Not a lot of people know that!", applies.

Chris Mason

On Tue, 28 Jul 2009 08:09:01 -0400, Klein, Kenneth 
 wrote:

> I understand, Pat. You probably got a lot of confused callers when you
>came in Monday morning.
>
>
>Ken Klein
>Sr. Systems Programmer
>Kentucky Farm Bureau Insurance - Louisville
>kenneth.kl...@kyfb.com
>502-495-5000 x7011
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Mark Zelden
>Sent: Monday, July 27, 2009 4:10 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: USS misuse (was Re: Mainframe hacking)
>
>On Mon, 27 Jul 2009 15:03:34 -0500, Patrick O'Keefe
> wrote:
>
>>On Mon, 27 Jul 2009 09:26:33 -0400, Thompson, Steve
>> wrote:
>>
>>>...
>>>The picture and last laugh came from one who had been rebuffed for
>>>pointing out the confusion caused by using USS instead of OE or OMVS,
>>>or some such.
>>>...
>>
>>I admit I could not tell who got the last laugh and who or what was
>>being laughed at, but suspected I might be in the "laughed at"
>>catagory.  I guess Chris felt that a bit more strongly than I did.
>>I think we were both wrong.
>>
>>And to show how deeply entrenched I am in the old (real :-) ) def of
>>USS, when I saw the subject I thought, Oh oh.  I misused USS once.  I
>>replaced the default IBMTEST with something that displayed a whole buch
>
>>of diagnostic stuff.
>>
>>And if nobody but Chris understands what I just said, well, that's
>>fine.
>>
>>Pat O'Keefe
>>
>
>
>I have no idea what you are talking about.
>
>Regards,
>
>IBMECHO ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

--
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


Re: USS misuse (was Re: Mainframe hacking)

2009-08-07 Thread Chris Mason
Mark

If you enter IBMTEST when the SNA LU is in the SSCP-LU - as opposed to the 
LU-LU state - and the LU is supported by Unformatted System Services 
(USS), the SSCP (VTAM) will "echo" back to you whatever you have specified 
as the second positional operand the number of times you specify as the first 
positional operand on the IBMTEST command.

According to the manual, the defaults are the string you posted and 10 
respectively. However, if you write your own USS module, you can change the 
defaults to whatever seems sensible. Perhaps your version has changed the 
count default to 1, which is perhaps a bit more sensible than IBM's 10.

Perhaps Pat made some change that seemed sensible until he tested it!

I expect this should work as well for the Communications Server TN3270 
server program as for an SNA session not concatenated to a TN3270 
connection but I've not tested it. Was that the environment you were testing?

If you've read my response to Pat, you'll know that my guess for the rationale 
for the USS IBMTEST command is rooted in the technology of the late '60s.

Chris Mason

On Mon, 27 Jul 2009 15:10:05 -0500, Mark Zelden 
 wrote:

>On Mon, 27 Jul 2009 15:03:34 -0500, Patrick O'Keefe
> wrote:
>
>>On Mon, 27 Jul 2009 09:26:33 -0400, Thompson, Steve
>> wrote:
>>
>>>...
>>>The picture and last laugh came from one who had been rebuffed for
>>>pointing out the confusion caused by using USS instead of OE or
>>>OMVS, or some such.
>>>...
>>
>>I admit I could not tell who got the last laugh and who or what
>>was being laughed at, but suspected I might be in the "laughed
>>at" catagory.  I guess Chris felt that a bit more strongly than I did.
>>I think we were both wrong.
>>
>>And to show how deeply entrenched I am in the old (real :-) ) def
>>of USS, when I saw the subject I thought, Oh oh.  I misused USS
>>once.  I replaced the default IBMTEST with something that displayed
>>a whole buch of diagnostic stuff.
>>
>>And if nobody but Chris understands what I just said, well, that's
>>fine.
>>
>>Pat O'Keefe
>>
>
>
>I have no idea what you are talking about.
>
>Regards,
>
>IBMECHO ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

--
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


  1   2   >