CBR3006I LIB ID not recognised
Hi I have been receiving this error in one of our DR site. I can see the LIB ID and PORT ID are part of IODF. I even tried deleting LIB ID dynamically and reloaded the same IODF. Device for 3590 have got all the attributes set correctly same as production. I am not able to even vary on the the LIBRARY defined for 3592. Under ISMF, tape list the port ID and LIB has been added and I can compare it . There is no discrepancy between IODF entry and ISMF. There was a discussion on this list long back. Not sure if the OP responded how he resolved the issue. Any pointers would be appreciated. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBR3006I LIB ID not recognised
The LIB ID must also be set in the library itself. Is that also the same ID? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter > Sent: 06 May, 2019 11:44 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CBR3006I LIB ID not recognised > > Hi > > I have been receiving this error in one of our DR site. > > I can see the LIB ID and PORT ID are part of IODF. I even tried deleting > LIB ID dynamically and reloaded the same IODF. > > Device for 3590 have got all the attributes set correctly same as > production. > > I am not able to even vary on the the LIBRARY defined for 3592. > > Under ISMF, tape list the port ID and LIB has been added and I can compare > it . There is no discrepancy between IODF entry and ISMF. > > There was a discussion on this list long back. Not sure if the OP > responded > how he resolved the issue. > > Any pointers would be appreciated. > > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBR3006I LIB ID not recognised
On Mon, May 6, 2019 at 4:44 AM Peter wrote: > Hi > > I have been receiving this error in one of our DR site. > > I can see the LIB ID and PORT ID are part of IODF. I even tried deleting > LIB ID dynamically and reloaded the same IODF. > > Device for 3590 have got all the attributes set correctly same as > production. > > I am not able to even vary on the the LIBRARY defined for 3592. > > Under ISMF, tape list the port ID and LIB has been added and I can compare > it . There is no discrepancy between IODF entry and ISMF. > > There was a discussion on this list long back. Not sure if the OP responded > how he resolved the issue. > > Any pointers would be appreciated. > > Peter > > Do you see messages like this in the SYSLOG? CBR3006I Library $ATL0002 with Library ID A0420 unknown in I/O configuration. *CBR3002E Library $ATL0002 no longer usable. CBR3006I Library $VTS0002 with Library ID B1589 unknown in I/O configuration. *CBR3002E Library $VTS0002 no longer usable. If so, that means that the Library IDs in the IODF / SMS do not match the physical Library IDs at DR. You need to change the IODF and SMS to have the proper physical Library IDs. This is one area which z/VM cannot virtualize. If you don't know the actual Library IDs, the simplest way to get it is to enter a command like I did below. Note that 0600 is a virtual tape address, and 0800 is an ATL address. V 0600,ONLINE IEE103I UNIT 0600 NOT BROUGHT ONLINE 635 IEE763I NAME= IECTDSR2 CODE= 0008 IEA437I TAPE LIBRARY DEVICE(0600), HCD(B1589-01),DEVICE(70868-01) IEE764I END OF IEE103IRELATED MESSAGES V 808,ONLINE IEE103I UNIT 0808 NOT BROUGHT ONLINE 578 IEE763I NAME= IECTDSR2 CODE= 0008 IEA437I TAPE LIBRARY DEVICE(0808), HCD(A0420-01),DEVICE(17909-02) IEE764I END OF IEE103IRELATED MESSAGES The above shows that my HCD has B1589-01, but the physical device has 70868. So I went into the HCD and changed the Library ID for the devices. I also updated SMS for the VTS definition. I had to do the same with the physical ATL devices. I could then do a soft activate of the new IODF and an ACTIVATE of the new (updated) SCDS as well. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
The only ones I know of that have been published are the ones that were mentioned (There were legitimate mainframe vulns in there, not just creds reused). I know of others that are actual hacks, but none that are public information. Chad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 6.2 and ARCH(12)
The actual arch level should be somewhere in the Job listing from the Cobol
Compile.
HTH,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
John Abell
Sent: Saturday, May 4, 2019 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 6.2 and ARCH(12)
I am a bit behind on this issue so maybe you have tried some of the below.
I am puzzled by this unless the ARCH parm is not taken by the compiler for some
reason. Do you have the same problem using the DEFAULT ARCH value?
Generate the assembler listing and then see if the S0C1 or S0C4 actually
happens in the COBOL code. Also check the ARCH value in the listing. Look for
Vector instructions, in the assembler listing for starters. I did this for the
C modules compiled under z/OS 2.3 and ARCH(12) and the new Vector instructions
were in the listing. They were not there using earlier versions of the
compiler. I generate C code all of the time using the ARCH and TUNEs value for
the client's machine. The code is compiled on a z14. Client's with z12s and
z13s report no issues. This is all using LE.
One item of interest, maybe, is that the C code compiled with ARCH(12) on z/OS
2.3 runs without issue on z/OS 2.2 and 2.2's LE on a z14.
Can you run without the 3rd party software and see if your code runs?
John T. Abell
Tel:800-295-7608Option 4
President
International: 1-416-593-5578 Option 4
E-mail: john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609
International: 1-416-593-5579
International Software Products
https://apc01.safelinks.protection.outlook.com/?url=www.ispinfo.com&data=02%7C01%7Callan.staller%40HCL.COM%7C94623be694344a0455d808d6d09f07a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636925778808536522&sdata=hIdc5QKlumv6gBEJu8VMRPH7iXIE42%2BgqvIYR5yhpZY%3D&reserved=0
This email may contain confidential and privileged material for the sole use of
the intended recipient(s). Any review, use, retention, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient), please
contact the sender by reply email and delete all copies of this message.
Also,email is susceptible to data corruption, interception, tampering,
unauthorized amendment and viruses. We only send and receive emails on the
basis that we are not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Schwab
Sent: Friday, May 03, 2019 8:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 6.2 and ARCH(12)
Is the abend in the user compiled instructions? Then check the compiler
processor settings.
Is the abend in the vendor compiled libraries or included subroutines?
Then check the vendor's subroutine / runtime libraries.
On Fri, May 3, 2019 at 6:52 PM Charles Mills wrote:
>
> I think I disagree.
>
> You compile the program for ARCH(8). IBM guarantees that it will run on a z10
> (do I have that right?). They do NOT guarantee that the program plus LE will
> behave on a z114 exactly as though it were running on a z10.
>
> No matter what ARCH the program were compiled for, I would expect that LE
> running on a z114 might well exploit the actual hardware. I would be kind of
> unhappy if it did NOT.
>
> The vendor product either supports z114's or it does not. If they do not
> support z114 instructions, they should admit that they do not.
>
> > If LE really is doing this, why even have an ABO product
>
> To update ("optimize") the *compiled* object code. The OS-resident
> support/library modules (LE) are a different matter. They are already (I am
> guessing) at a current level.
>
> What is the z/OS release? I would expect LE to be built for the lowest level
> hardware that that release supported, but LE might be clever enough to
> dual-path, and I think that would be a good thing.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Friday, May 3, 2019 3:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 6.2 and ARCH(12)
>
> On Fri, 3 May 2019 15:57:34 -0400, Brian Chapman wrote:
>
> >We have a vendor debugging product that is constantly causing 0C1 and
> >0C4 abends since we have upgraded to COBOL 6.2. It also caused these
> >abends when we were at COBOL 4,2, but the abend rate has grown
> >considerably after the upgrade.
> >
> >The vendor has produced countless patches, but so far they have not
> >resolved the issues. We were notified today that they believe they
> >understand the issue. They are stating that even though our COBOL
> >compiler is set with ARCH(8) (to support our DRE machine), LE
> >run-time is recognizing that the program is COBOL 6.2, running on a
> >z14, and automatically switch the ARCH level to ARCH(12). The
Re: COBOL 6.2 and ARCH(12)
Your should have something similar to the following in the COBOL listing where I have used ARCH(11). Invocation parameters: OPTFILE Options from SYSOPTF: ARCH(11) ARITH(COMPAT) DATA(31) . . . John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Monday, May 06, 2019 8:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) The actual arch level should be somewhere in the Job listing from the Cobol Compile. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of John Abell Sent: Saturday, May 4, 2019 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) I am a bit behind on this issue so maybe you have tried some of the below. I am puzzled by this unless the ARCH parm is not taken by the compiler for some reason. Do you have the same problem using the DEFAULT ARCH value? Generate the assembler listing and then see if the S0C1 or S0C4 actually happens in the COBOL code. Also check the ARCH value in the listing. Look for Vector instructions, in the assembler listing for starters. I did this for the C modules compiled under z/OS 2.3 and ARCH(12) and the new Vector instructions were in the listing. They were not there using earlier versions of the compiler. I generate C code all of the time using the ARCH and TUNEs value for the client's machine. The code is compiled on a z14. Client's with z12s and z13s report no issues. This is all using LE. One item of interest, maybe, is that the C code compiled with ARCH(12) on z/OS 2.3 runs without issue on z/OS 2.2 and 2.2's LE on a z14. Can you run without the 3rd party software and see if your code runs? John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products https://apc01.safelinks.protection.outlook.com/?url=www.ispinfo.com&data=02%7C01%7Callan.staller%40HCL.COM%7C94623be694344a0455d808d6d09f07a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636925778808536522&sdata=hIdc5QKlumv6gBEJu8VMRPH7iXIE42%2BgqvIYR5yhpZY%3D&reserved=0 This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, May 03, 2019 8:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) Is the abend in the user compiled instructions? Then check the compiler processor settings. Is the abend in the vendor compiled libraries or included subroutines? Then check the vendor's subroutine / runtime libraries. On Fri, May 3, 2019 at 6:52 PM Charles Mills wrote: > > I think I disagree. > > You compile the program for ARCH(8). IBM guarantees that it will run on a z10 > (do I have that right?). They do NOT guarantee that the program plus LE will > behave on a z114 exactly as though it were r
Re: COBOL 6.2 and ARCH(12)
I verified a few of my recent COBOL listings, and they all have ARCH(8) specified. Our applications developers claim that this issue only occurs when they run their code through the debugger. It apparently never occurs outside the debugger. The issue has been very intermittent, so it hasn't been easy to replicate but we have dumps from most of the 0C1 or 0C4 abends. How does z/OS handle a situation where two COBOL programs that are compiled at different ARCH levels and part of the same LE enclave? Since the vendor code receives execution first, does it determine the enclave level? I'm not sure what ARCH level the vendor compiles their COBOL code (if they have any). Thank you, Brian Chapman On Mon, May 6, 2019 at 9:01 AM John Abell < john.ab...@intnlsoftwareproducts.com> wrote: > Your should have something similar to the following in the COBOL listing > where I have used ARCH(11). > > Invocation parameters: > OPTFILE > Options from SYSOPTF: > ARCH(11) > ARITH(COMPAT) > DATA(31) > . > . > . > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > www.ispinfo.com > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we are not liable for any such corruption, > interception, tampering, amendment or viruses or any consequence thereof. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: Monday, May 06, 2019 8:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > The actual arch level should be somewhere in the Job listing from the > Cobol Compile. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of John Abell > Sent: Saturday, May 4, 2019 9:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I am a bit behind on this issue so maybe you have tried some of the below. > > I am puzzled by this unless the ARCH parm is not taken by the compiler for > some reason. Do you have the same problem using the DEFAULT ARCH value? > > Generate the assembler listing and then see if the S0C1 or S0C4 actually > happens in the COBOL code. Also check the ARCH value in the listing. Look > for Vector instructions, in the assembler listing for starters. I did this > for the C modules compiled under z/OS 2.3 and ARCH(12) and the new Vector > instructions were in the listing. They were not there using earlier > versions of the compiler. I generate C code all of the time using the ARCH > and TUNEs value for the client's machine. The code is compiled on a z14. > Client's with z12s and z13s report no issues. This is all using LE. > > One item of interest, maybe, is that the C code compiled with ARCH(12) on > z/OS 2.3 runs without issue on z/OS 2.2 and 2.2's LE on a z14. > > Can you run without the 3rd party software and see if your code runs? > > John T. Abell > Tel:800-295-7608Option 4 > President > International: 1-416-593-5578 Option 4 > E-mail: john.ab...@intnlsoftwareproducts.com > Fax:800-295-7609 > > International: 1-416-593-5579 > > > International Software Products > > https://apc01.safelinks.protection.outlook.com/?url=www.ispinfo.com&data=02%7C01%7Callan.staller%40HCL.COM%7C94623be694344a0455d808d6d09f07a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636925778808536522&sdata=hIdc5QKlumv6gBEJu8VMRPH7iXIE42%2BgqvIYR5yhpZY%3D&reserved=0 > > This email may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review, use, retention, distribution > or disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive on behalf of the named recipient), > please contact the sender by reply email and delete all copies of this > message. Also,email is susceptible to data corruption, interception, > tampering, unauthorized amendment and viruses. We only send and receive > emails on the basis that we are not liable for any such corruption, > interception, tampering, amendment or viruses or any consequence thereof. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: Friday, May 03, 2019 8:41 PM > To: IBM-MAIN@LISTSERV.U
Re: COBOL 6.2 and ARCH(12)
> How does z/OS handle a situation where two COBOL programs that are compiled > at different ARCH levels and part of the same LE enclave? Since the vendor > code receives execution first, does it determine the enclave level? I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. If you were writing a compiler, your compiler code would say "can I use machine instruction XYZ? Nope, user said ARCH(n), so no can do." The code you emitted would be fixed (of course): it would never, ever have an instruction XYZ in it. If the user ran it on a zWhatever, it would still be devoid of XYZ instructions. The enclave does not have an ARCH level, the various programs running there either do or do not include instruction XYZ. > I'm not > sure what ARCH level the vendor compiles their COBOL code (if they have > any). They need to know. I was until very recently responsible for a vendor product written in C++. There was a conscious management decision to support customers back through a z9, so I compiled ARCH(7). End of story. I did not pick some new ARCH level that appealed to me that day. Question: did you possibly customize or parametize the debugger for a z14 during installation, and then clone that installation over to your older DR machine? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Chapman Sent: Monday, May 6, 2019 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) I verified a few of my recent COBOL listings, and they all have ARCH(8) specified. Our applications developers claim that this issue only occurs when they run their code through the debugger. It apparently never occurs outside the debugger. The issue has been very intermittent, so it hasn't been easy to replicate but we have dumps from most of the 0C1 or 0C4 abends. How does z/OS handle a situation where two COBOL programs that are compiled at different ARCH levels and part of the same LE enclave? Since the vendor code receives execution first, does it determine the enclave level? I'm not sure what ARCH level the vendor compiles their COBOL code (if they have any). Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 6.2 and ARCH(12)
Charles, Thanks for the explanation. Our system IGYCOPT specifies ARCH=*8. We are only experiencing this issue on our production machine. We clone our machine for DR, but our test systems are never started so the debugging tool would never be used on this machine. Simulation debuggers are not allowed on our production systems. Thank you, Brian Chapman On Mon, May 6, 2019 at 10:34 AM Charles Mills wrote: > > How does z/OS handle a situation where two COBOL programs that are > compiled > > at different ARCH levels and part of the same LE enclave? Since the > vendor > > code receives execution first, does it determine the enclave level? > > I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. If > you were writing a compiler, your compiler code would say "can I use > machine instruction XYZ? Nope, user said ARCH(n), so no can do." The code > you emitted would be fixed (of course): it would never, ever have an > instruction XYZ in it. If the user ran it on a zWhatever, it would still be > devoid of XYZ instructions. The enclave does not have an ARCH level, the > various programs running there either do or do not include instruction XYZ. > > > I'm not > > sure what ARCH level the vendor compiles their COBOL code (if they have > > any). > > They need to know. I was until very recently responsible for a vendor > product written in C++. There was a conscious management decision to > support customers back through a z9, so I compiled ARCH(7). End of story. I > did not pick some new ARCH level that appealed to me that day. > > Question: did you possibly customize or parametize the debugger for a z14 > during installation, and then clone that installation over to your older DR > machine? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Monday, May 6, 2019 6:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I verified a few of my recent COBOL listings, and they all have ARCH(8) > specified. > > Our applications developers claim that this issue only occurs when they run > their code through the debugger. It apparently never occurs outside the > debugger. The issue has been very intermittent, so it hasn't been easy to > replicate but we have dumps from most of the 0C1 or 0C4 abends. > > How does z/OS handle a situation where two COBOL programs that are compiled > at different ARCH levels and part of the same LE enclave? Since the vendor > code receives execution first, does it determine the enclave level? I'm not > sure what ARCH level the vendor compiles their COBOL code (if they have > any). > > > Thank you, > > Brian Chapman > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBR3006I LIB ID not recognised
'Note that 0600 is a virtual tape address, and 0800 is an ATL address' Guess 0600 and 800 is specific to your shop ? In my shop I have the UCB set as 2800 and 2801 for 3590. I get the same error message when I vary on 2800 and 2801 How do the IBM hardware guys set the LIB ID in ATL ?( just curious I am away from my DR site ) On Mon, 6 May, 2019, 3:48 PM John McKown, wrote: > On Mon, May 6, 2019 at 4:44 AM Peter wrote: > > > Hi > > > > I have been receiving this error in one of our DR site. > > > > I can see the LIB ID and PORT ID are part of IODF. I even tried deleting > > LIB ID dynamically and reloaded the same IODF. > > > > Device for 3590 have got all the attributes set correctly same as > > production. > > > > I am not able to even vary on the the LIBRARY defined for 3592. > > > > Under ISMF, tape list the port ID and LIB has been added and I can > compare > > it . There is no discrepancy between IODF entry and ISMF. > > > > There was a discussion on this list long back. Not sure if the OP > responded > > how he resolved the issue. > > > > Any pointers would be appreciated. > > > > Peter > > > > > Do you see messages like this in the SYSLOG? > > CBR3006I Library $ATL0002 with Library ID A0420 unknown in I/O > configuration. > *CBR3002E Library $ATL0002 no longer usable. > CBR3006I Library $VTS0002 with Library ID B1589 unknown in I/O > configuration. > *CBR3002E Library $VTS0002 no longer usable. > > > If so, that means that the Library IDs in the IODF / SMS do not match the > physical Library IDs at DR. You need to change the IODF and SMS to have the > proper physical Library IDs. This is one area which z/VM cannot virtualize. > If you don't know the actual Library IDs, the simplest way to get it is to > enter a command like I did below. Note that 0600 is a virtual tape address, > and 0800 is an ATL address. > > V 0600,ONLINE > IEE103I UNIT 0600 NOT BROUGHT ONLINE 635 > IEE763I NAME= IECTDSR2 CODE= 0008 > IEA437I TAPE LIBRARY DEVICE(0600), HCD(B1589-01),DEVICE(70868-01) > IEE764I END OF IEE103IRELATED MESSAGES > > V 808,ONLINE > IEE103I UNIT 0808 NOT BROUGHT ONLINE 578 > IEE763I NAME= IECTDSR2 CODE= 0008 > IEA437I TAPE LIBRARY DEVICE(0808), HCD(A0420-01),DEVICE(17909-02) > IEE764I END OF IEE103IRELATED MESSAGES > > > The above shows that my HCD has B1589-01, but the physical device has > 70868. So I went into the HCD and changed the Library ID for the devices. I > also updated SMS for the VTS definition. I had to do the same with the > physical ATL devices. I could then do a soft activate of the new IODF and > an ACTIVATE of the new (updated) SCDS as well. > > > -- > This is clearly another case of too many mad scientists, and not enough > hunchbacks. > > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crazy concatenation mystery
Not that I know of, other then the SMF records for the input and output. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 3, 2019 1:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Crazy concatenation mystery On Fri, 3 May 2019 14:03:49 +, Seymour J Metz wrote: >In OS/360, IEBCOPY couldn't reblock load modules. In OS/VS, it could, with the >appropriate control statement. > When IEBCOPY reblocks a module, does it leave any audit trail? That might be of interest in case of the OP's problem. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Crazy concatenation mystery
By "object blocks" do you mean text blocks? As I recall, everything other than text blocks is limited to 256 bytes. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Thursday, May 2, 2019 11:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Crazy concatenation mystery The object code blocks are written in multiples of 1K up to 32,760 bytes. There are also text blocks that are usually under 1K unless you have a lot of external symbols. A linkedit / binder / copymod will try to fill the rest of the track, down to a 1K block. The Advance Print Function libraries should be 18K. On Thu, May 2, 2019 at 9:16 PM David Spiegel wrote: > > Hi Steve, > You said: "... but the received wisdom is that all load libraries should > have blksize=32K-8. ..." > > For optimal space usage, however, the BLKSIZE should be 27998 (i.e. > half-track blocking). > > Regards, > David > > On 2019-05-02 21:57, Steve Smith wrote: > > Well, Greg Price explained why the blksize issue doesn't arise in normal > > execution. > > > > In addition, PDSEs don't really have a blksize; that is faked up on the fly > > when BPAM or something similar is used. Program Fetch uses something like > > DIV or paging I/O to load program objects. For classic PDS, the blksize is > > "real", but again Program Fetch doesn't use access methods, and doesn't > > care what size the blocks are. > > > > It's a little late in the day, but the received wisdom is that all load > > libraries should have blksize=32K-8. That predates PDSE by decades. The > > old linkage-editor was smart enough to fill tracks up with whatever block > > size would fit. As long as it wasn't artificially restricted to something > > less than the max. RECFM=U does not work like FB. > > > > btw, why are you running FA? Has it ever done anything useful for you? > > > > sas > > > > > > > > On Thu, May 2, 2019 at 8:42 PM Attila Fogarasi wrote: > > > >> The Binder is not invoked by Db2 when executing your application program -- > >> hence no error message and successful execution. Fault Analyzer is > >> invoking the Binder to get debugging info about the load module as part of > >> its processing for the prior problem. Other debugging tools handle this > >> more elegantly but FA chooses to just confuse you with the irrelevant > >> cascaded error which has no bearing on the defect it is trying to report. > >> Quick fix is to turn off Fault Analyzer as these "invalid" load module > >> block sizes are perfectly valid for execution or even for use with the > >> Binder with the right environment. For better or worse the Binder defaults > >> to using 32760 (maximum device supported blksize) whenever possible, unless > >> directed otherwise. > >> > >> On Fri, May 3, 2019 at 8:43 AM Jesse 1 Robinson > >> wrote: > >> > >>> Thanks to the many contributions to this thread, I think we have it > >>> (mostly) figured out. The key was identifying what changed on 14 April. > >> No > >>> module changes. No JCL changes. But of course something happened that I > >>> didn't mention earlier because 'it could not be the cause'. What happened > >>> on the 14th was an error in the data that caused an SQL duplicate record > >>> condition, or 811. That led to a U3003 abend, which woke up Fault > >> Analyzer > >>> *for the first time*. Upon awakening, he looked around and saw the > >> invalid > >>> module block sizes and complained about them. For literally years FA had > >>> never peeped because there had never been an actual abend. Why did fetch > >>> not bellyache about BLKSIZE? I have no idea. The module named in the > >> message > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CBR3006I LIB ID not recognised
On Mon, May 6, 2019 at 11:44 AM Peter wrote: > 'Note that 0600 is a virtual tape address, > and 0800 is an ATL address' > > Guess 0600 and 800 is specific to your shop ? In my shop I have the UCB set > as 2800 and 2801 for 3590. > Correct. I could have been clearer about that. > > I get the same error message when I vary on 2800 and 2801 > > How do the IBM hardware guys set the LIB ID in ATL ?( just curious I am > away from my DR site ) > I have no idea. It may be settable in the firmware, or maybe it is "hard coded" into the hardware. I am thinking that it is conceptually like the CPUID on the z. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 6.2 and ARCH(12)
I don't think this is an ARCH problem at all. I think the darned debugger is just plain buggy. You say the debugger is experiencing S0C4's (as well as S0C1's). I don't think an ARCH mismatch can cause a S0C4 (at least not in the real world -- someone might be able to come up with a theoretical example). An ARCH problem would almost always result in a S0C1. Nor should an ARCH issue ever cause a problem on a newer machine (compile ARCH(8), run on z14) but only on an older machine (compile ARCH(12), attempt to run on z10). Ergo, I do not think you have an ARCH problem, I think the debugger has a bug problem. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Chapman Sent: Monday, May 6, 2019 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) Charles, Thanks for the explanation. Our system IGYCOPT specifies ARCH=*8. We are only experiencing this issue on our production machine. We clone our machine for DR, but our test systems are never started so the debugging tool would never be used on this machine. Simulation debuggers are not allowed on our production systems. Thank you, Brian Chapman On Mon, May 6, 2019 at 10:34 AM Charles Mills wrote: > > How does z/OS handle a situation where two COBOL programs that are > compiled > > at different ARCH levels and part of the same LE enclave? Since the > vendor > > code receives execution first, does it determine the enclave level? > > I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. If > you were writing a compiler, your compiler code would say "can I use > machine instruction XYZ? Nope, user said ARCH(n), so no can do." The code > you emitted would be fixed (of course): it would never, ever have an > instruction XYZ in it. If the user ran it on a zWhatever, it would still be > devoid of XYZ instructions. The enclave does not have an ARCH level, the > various programs running there either do or do not include instruction XYZ. > > > I'm not > > sure what ARCH level the vendor compiles their COBOL code (if they have > > any). > > They need to know. I was until very recently responsible for a vendor > product written in C++. There was a conscious management decision to > support customers back through a z9, so I compiled ARCH(7). End of story. I > did not pick some new ARCH level that appealed to me that day. > > Question: did you possibly customize or parametize the debugger for a z14 > during installation, and then clone that installation over to your older DR > machine? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Monday, May 6, 2019 6:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I verified a few of my recent COBOL listings, and they all have ARCH(8) > specified. > > Our applications developers claim that this issue only occurs when they run > their code through the debugger. It apparently never occurs outside the > debugger. The issue has been very intermittent, so it hasn't been easy to > replicate but we have dumps from most of the 0C1 or 0C4 abends. > > How does z/OS handle a situation where two COBOL programs that are compiled > at different ARCH levels and part of the same LE enclave? Since the vendor > code receives execution first, does it determine the enclave level? I'm not > sure what ARCH level the vendor compiles their COBOL code (if they have > any). > > > Thank you, > > Brian Chapman > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
> One of the tricks he pulled was to offload the RACF Database to a PC and > Dictionary Attack it. I *believe* that was done by investigators after the fact, attempting to determine how the attack might have been done. I don't recall that there is compelling evidence that Svartholm actually did that. It *is* trivially easy to do, assuming (a.) read access to the DB and (b.) old-style password storage. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Spiegel Sent: Sunday, May 5, 2019 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Hi Itschak, Gottfrid Svartholm Warg (Pirate Bay founder) hacked Logica. One of the tricks he pulled was to offload the RACF Database to a PC and Dictionary Attack it. The Security Admin folks were inexperienced to say the least. (This is not to say that relatively secure site with seasoned veterans can't be hacked. They just made it easy.) Regards, David On 2019-05-05 10:35, ITschak Mugzach wrote: I wonder if there are proved & published cases where mainframe where hacked. I know the Danish case of GCG. ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
#1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 6.2 and ARCH(12)
I fully agree with this opinion. John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609 International: 1-416-593-5579 International Software Products www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, May 06, 2019 1:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) I don't think this is an ARCH problem at all. I think the darned debugger is just plain buggy. You say the debugger is experiencing S0C4's (as well as S0C1's). I don't think an ARCH mismatch can cause a S0C4 (at least not in the real world -- someone might be able to come up with a theoretical example). An ARCH problem would almost always result in a S0C1. Nor should an ARCH issue ever cause a problem on a newer machine (compile ARCH(8), run on z14) but only on an older machine (compile ARCH(12), attempt to run on z10). Ergo, I do not think you have an ARCH problem, I think the debugger has a bug problem. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Chapman Sent: Monday, May 6, 2019 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 6.2 and ARCH(12) Charles, Thanks for the explanation. Our system IGYCOPT specifies ARCH=*8. We are only experiencing this issue on our production machine. We clone our machine for DR, but our test systems are never started so the debugging tool would never be used on this machine. Simulation debuggers are not allowed on our production systems. Thank you, Brian Chapman On Mon, May 6, 2019 at 10:34 AM Charles Mills wrote: > > How does z/OS handle a situation where two COBOL programs that are > compiled > > at different ARCH levels and part of the same LE enclave? Since the > vendor > > code receives execution first, does it determine the enclave level? > > I don't think an enclave HAS an ARCH level. ARCH is a compiler parm. > If you were writing a compiler, your compiler code would say "can I > use machine instruction XYZ? Nope, user said ARCH(n), so no can do." > The code you emitted would be fixed (of course): it would never, ever > have an instruction XYZ in it. If the user ran it on a zWhatever, it > would still be devoid of XYZ instructions. The enclave does not have > an ARCH level, the various programs running there either do or do not include > instruction XYZ. > > > I'm not > > sure what ARCH level the vendor compiles their COBOL code (if they > > have any). > > They need to know. I was until very recently responsible for a vendor > product written in C++. There was a conscious management decision to > support customers back through a z9, so I compiled ARCH(7). End of > story. I did not pick some new ARCH level that appealed to me that day. > > Question: did you possibly customize or parametize the debugger for a > z14 during installation, and then clone that installation over to your > older DR machine? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, May 6, 2019 6:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 6.2 and ARCH(12) > > I verified a few of my recent COBOL listings, and they all have > ARCH(8) specified. > > Our applications developers claim that this issue only occurs when > they run their code through the debugger. It apparently never occurs > outside the debugger. The issue has been very intermittent, so it > hasn't been easy to replicate but we have dumps from most of the 0C1 or 0C4 > abends. > > How does z/OS handle a situation where two COBOL programs that are > compiled at different ARCH levels and part of the same LE enclave? > Since the vendor code receives execution first, does it determine the > enclave level? I'm not sure what ARCH level the vendor compiles their > COBOL code (if they have any). > > > Thank you, > > Brian Chapman > > -- > For IBM-MAIN subscribe
Re: mainframe hacking "success stories"?
well, there are some clients of my that got a copy of the RACF/Top secret db by internal email. I was not only able to copy the file, but also to send it outside the mainframe. People like me that do pentests for leaving have seem almost everything. Last week I've noticed a client configuration that allowed route command to all and no console auto login. the result is that the command issued on the other lpar ran under *BYPASS* identity. People does stupid things that help you completely destroy the system. I still look for a published events. ITschak d to all. On Mon, May 6, 2019 at 8:21 PM Charles Mills wrote: > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS > a legitimate part of the mainframe, which it has been for 20 years or so). > It was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't > really a mainframe hack ... whatever." If your CEO was standing in front of > the press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
On Mon, 6 May 2019 10:21:25 -0700, Charles Mills wrote: >#1: Noo. It was a legitimate mainframe hack (assuming you consider USS a >legitimate part of the mainframe, which it has been for 20 years or so). It >was an exploit of CGI buffer overrun. > Was that Shellshock? Is only bash susceptible to Shellshock. That feature is so vulnerable that it ought to be withdrawn; reliance on filtering inputs is hardly sufficient. >#2: It drives me nuts to hear mainframers explain away mainframe breaches. "It >wasn't really a mainframe hack, they got in through USS." "It wasn't really a >mainframe hack, they re-used a Windows password." "It wasn't really a >mainframe hack ... whatever." If your CEO was standing in front of the press >explaining how your company let x million credit card numbers go astray, would >it matter HOW they got into your mainframe, or only that they DID?" If your >mainframe is vulnerable to a USS hack, or a shared Windows password, or >whatever, you need to fix THAT, or risk having to explain to your CEO why he >got fired (like Target's) for letting all those credit card numbers go astray. > +1 It doesn't matter. How does one audit for shared Windows passwords, even when they may be encrypted and salted? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BLKSIZE=0 (was: Crazy ...)
On Mon, 6 May 2019 16:44:47 +, Seymour J Metz wrote: >Not that I know of, other then the SMF records for the input and output. > >From: Paul Gilmartin >Sent: Friday, May 3, 2019 1:42 PM > >When IEBCOPY reblocks a module, does it leave any audit trail? That >might be of interest in case of the OP's problem. > Amidst the nattering about 32760 vs. half-track vs. 4KiB vs. ... I suggested coding BLKSIZE=0. That received neither support nor opposition. So, I wonder: Does coding BLKSIZE=0 ever lead to complete failure of a utility or product? I encountered one many years ago. It was promptly fixed by APAR. Does BLKSIZE=0 ever lead to suboptimum performance? There might be trivial exceptions for unlabelled tapes with DISP=MOD or for IEBGENER where SYSUT1 is already adversely blocked. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
QSAM question
All: I have a QSAM question. If I have a Cobol program writing to a QSAM file and it runs out of space on the file, i.e.; SB37 , can i recover from the SB37 without manual intervention. A possible condition handler ? If I write and Assembler I/O routine to be called passing the data to and writing to the QSAM file, the same question, my assumption is "yes" and can someone point me to the manual I assume it DFSMSdfp working with datasets ... Regards, Scott -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
The Pirate Bay hack acquired a valid mainframe userid and password off of a Microsoft laptop. In effect, not really a mainframe hack. He just logged on. https://badcyber.com/a-history-of-a-hacking/ Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM question
On Mon, May 6, 2019 at 1:15 PM scott Ford wrote: > All: > > I have a QSAM question. If I have a Cobol program writing to a QSAM file > and it runs out of space on the file, i.e.; SB37 , can i recover from the > SB37 without manual intervention. > A possible condition handler ? > > If I write and Assembler I/O routine to be called passing the data to and > writing to the QSAM file, the same question, my assumption is "yes" and can > someone point me to the manual I assume it DFSMSdfp working with datasets > ... > > Regards, > Scott > > -- > Perhaps this? https://www.ibm.com/support/knowledgecenter/en/SS6SG3_5.2.0/com.ibm.cobol52.ent.doc/PGandLR/ref/rlcdsusea.html If not, there are Language Environment (CEExxx) calls to set up a generalized recovery environment that you might be able to use. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceea300/clchdlr.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ceea300/clc3srp.htm -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library Server Being Replaced Clarification
Hi Folks Regrettably, bookshelves were rarely, if ever, available outside the collection kits for individual download from the IBM Publications Center, and with good reason. Softcopy Librarian (SCL) requires a set of files, called descriptor files, that are created as a by-product of the now defunct softcopy kit manufacturing process. That’s why you cannot define the Library Server site as a source repository in SCL. If you open SCL and click on the “Internet” repository, you’ll see a list of available softcopy kits. BookManager technology was very precise. The shelves required that the book timestamps exactly match the shelf metadata. This scheme was used to help ensure the currency of content for users who chose to manage their own local repositories. The “z/OS Software Products Collection” shelves in SCL should contain all the content you need. However, if there are product shelves and books that you still need, let me know what they are. I will see what I can do. For information about Library Server, see https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bks/bks.htm . For information about SCL and BookManager, see https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.bkm/bkm.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM question
Scott, An assembler I/O module would handle this without much effort. Take a look at the EXLST parameter on the file DCB. *DCBEXIT DS0H * * USING DCBXPLST,R1 * * CLHHSI DCBXPRM1,B37 Abend code B37? * * BERECOVER Yes. Ignore abend* *…* *RECOVER DS0H * ** * LTORG * *B37 EQU X'B370' B37 Abend code * ** * *DCBTEMP DCB DDNAME=,DSORG=PS,MACRF=PM,RECFM=FB,LRECL=2960, ** * EXLST=ABNDXLST * ** * *ABNDXLST DCAL1(EXLLASTE+EXLDCBAB),AL3(DCBEXIT) * ** * * IHAEXLST * * DCBD * ** * Thank you, Brian Chapman On Mon, May 6, 2019 at 2:15 PM scott Ford wrote: > All: > > I have a QSAM question. If I have a Cobol program writing to a QSAM file > and it runs out of space on the file, i.e.; SB37 , can i recover from the > SB37 without manual intervention. > A possible condition handler ? > > If I write and Assembler I/O routine to be called passing the data to and > writing to the QSAM file, the same question, my assumption is "yes" and can > someone point me to the manual I assume it DFSMSdfp working with datasets > ... > > Regards, > Scott > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Yes. Just logged on... And had access to all databases. This us how they was caught. Too much queries per second. בתאריך יום ב׳, 6 במאי 2019, 21:17, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > The Pirate Bay hack acquired a valid mainframe userid and password off of > a Microsoft laptop. In effect, not really a mainframe hack. He just logged > on. https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS > a legitimate part of the mainframe, which it has been for 20 years or so). > It was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't > really a mainframe hack ... whatever." If your CEO was standing in front of > the press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: CBR3006I LIB ID not recognised
Regarding the "how do the IBM hardware guys set the LIB ID" question - it is set during the initial configuration of the machine. We were able to pick the library ID for the composite library as well as the distributed library name back when we put our first TS7720 on the floor. When we upgraded to a TS7760 clustered to a TS7760T at our DR location, we picked the IDs for the new nodes, tying them together using the composite library number. The CE used the lib IDs when he configured the machines. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Monday, May 6, 2019 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: CBR3006I LIB ID not recognised On Mon, May 6, 2019 at 11:44 AM Peter wrote: > 'Note that 0600 is a virtual tape address, and 0800 is an ATL address' > > Guess 0600 and 800 is specific to your shop ? In my shop I have the > UCB set as 2800 and 2801 for 3590. > Correct. I could have been clearer about that. > > I get the same error message when I vary on 2800 and 2801 > > How do the IBM hardware guys set the LIB ID in ATL ?( just curious I > am away from my DR site ) > I have no idea. It may be settable in the firmware, or maybe it is "hard coded" into the hardware. I am thinking that it is conceptually like the CPUID on the z. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Exactly. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 2:43 PM, ITschak Mugzach wrote: Yes. Just logged on... And had access to all databases. This us how they was caught. Too much queries per second. בתאריך יום ב׳, 6 במאי 2019, 21:17, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > The Pirate Bay hack acquired a valid mainframe userid and password off of > a Microsoft laptop. In effect, not really a mainframe hack. He just logged > on. https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS > a legitimate part of the mainframe, which it has been for 20 years or so). > It was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't > really a mainframe hack ... whatever." If your CEO was standing in front of > the press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM question
John and Brian, A big thanks I thought so. Assembler i was aware of, but Cobol I hadnt had the experience. But it looks like it might *be doable* thanks , friend John. Scott On Mon, May 6, 2019 at 2:40 PM Brian Chapman wrote: > Scott, > > An assembler I/O module would handle this without much effort. Take a look > at the EXLST parameter on the file DCB. > > > > *DCBEXIT DS0H * > > * USING DCBXPLST,R1 * > > * CLHHSI DCBXPRM1,B37 Abend code B37? * > > * BERECOVER Yes. Ignore abend* > > > > *…* > > *RECOVER DS0H * > > ** > > > > > > * LTORG * > > *B37 EQU X'B370' B37 Abend code * > > ** * > > *DCBTEMP DCB DDNAME=,DSORG=PS,MACRF=PM,RECFM=FB,LRECL=2960, ** > > * EXLST=ABNDXLST * > > ** * > > *ABNDXLST DCAL1(EXLLASTE+EXLDCBAB),AL3(DCBEXIT) * > > > ** * > > * IHAEXLST * > > * DCBD * > > ** * > > > Thank you, > > Brian Chapman > > > On Mon, May 6, 2019 at 2:15 PM scott Ford wrote: > > > All: > > > > I have a QSAM question. If I have a Cobol program writing to a QSAM file > > and it runs out of space on the file, i.e.; SB37 , can i recover from > the > > SB37 without manual intervention. > > A possible condition handler ? > > > > If I write and Assembler I/O routine to be called passing the data to and > > writing to the QSAM file, the same question, my assumption is "yes" and > can > > someone point me to the manual I assume it DFSMSdfp working with datasets > > ... > > > > Regards, > > Scott > > > > -- > > > > > > > > *IDMWORKS * > > > > Scott Ford > > > > z/OS Dev. > > > > > > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > > friend or collegue you demean yourself” > > > > > > > > www.idmworks.com > > > > scott.f...@idmworks.com > > > > Blog: www.idmworks.com/blog > > > > > > > > > > > > *The information contained in this email message and any attachment may > be > > privileged, confidential, proprietary or otherwise protected from > > disclosure. If the reader of this message is not the intended recipient, > > you are hereby notified that any dissemination, distribution, copying or > > use of this message and any attachment is strictly prohibited. If you > have > > received this message in error, please notify us immediately by replying > to > > the message and permanently delete it from your computer and destroy any > > printout thereof.* > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
The attacker created zero day exploits against z/OS in the wild allowing escalation of privilege and proved difficult to dislodge even once discovered. Information available to the public supports this. Phil Young has done a good job of dissecting the hack. Philip Young - Smashing the Mainframe for Fun and Prison Time https://youtu.be/SjtyifWTqmc And How Hackers Breached a Government (and a Bank) https://share.confex.com/share/124/webprogram/Handout/Session16982/How%20Hackers%20Breached%20a%20Government%20%28and%20a%20Bank%29.pdf z/OS on IBMz hardware is the most securable environment in the world but as public evidence supports it was compromised. It would seem fair to say the mainframe was hacked. Best Regards, Sam Knutson -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Exactly. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 2:43 PM, ITschak Mugzach wrote: Yes. Just logged on... And had access to all databases. This us how they was caught. Too much queries per second. בתאריך יום ב׳, 6 במאי 2019, 21:17, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or so). > It was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing > in front of the press explaining how your company let x million credit > card numbers go astray, would it matter HOW they got into your > mainframe, or only that they DID?" If your mainframe is vulnerable to > a USS hack, or a shared Windows password, or whatever, you need to fix > THAT, or risk having to explain to your CEO why he got fired (like > Target's) for letting all those credit card numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
No. >From the link you cite: "According to various sources, the hackers succeeded in finding (and exploiting) at least 2 previously unknown errors enabling them to raise their authorisations in the system. One of them was an error in an IBM HTTP server and the other one was an error in the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which means that by leveraging on the errors it contains, one is able to execute commands with the system administrator’s authorisations)." His "user" access to InfoTorg was not a problem for the mainframe. (It was a problem for the MPAA lawyer whose account he accessed, but not for the mainframe in general.) The above mainframe security vulnerability was. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? The Pirate Bay hack acquired a valid mainframe userid and password off of a Microsoft laptop. In effect, not really a mainframe hack. He just logged on. https://badcyber.com/a-history-of-a-hacking/ Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Charles is correct. He found vulnerabilities in DFS I believe. Used that for privesc. > On May 6, 2019, at 21:17, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Possibly, but after they logged on with a valid userid acquired from a hacked laptop. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:29 PM, Bigendian Smalls wrote: Charles is correct. He found vulnerabilities in DFS I believe. Used that for privesc. > On May 6, 2019, at 21:17, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Still never would have occurred without a valid userid. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: No. >From the link you cite: "According to various sources, the hackers succeeded in finding (and exploiting) at least 2 previously unknown errors enabling them to raise their authorisations in the system. One of them was an error in an IBM HTTP server and the other one was an error in the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which means that by leveraging on the errors it contains, one is able to execute commands with the system administrator’s authorisations)." His "user" access to InfoTorg was not a problem for the mainframe. (It was a problem for the MPAA lawyer whose account he accessed, but not for the mainframe in general.) The above mainframe security vulnerability was. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? The Pirate Bay hack acquired a valid mainframe userid and password off of a Microsoft laptop. In effect, not really a mainframe hack. He just logged on. https://badcyber.com/a-history-of-a-hacking/ Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. > On May 6, 2019, at 21:43, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Still never would have occurred without a valid userid. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Zos 1.x used to ship uads with users tso00 to tso03 (or 1-4), so passwords could be collected from another system. Used this to penetrate the mainframe. Tx god ibm stop shipping pre loaded uads. בתאריך יום ב׳, 6 במאי 2019, 22:54, מאת Bigendian Smalls < mainfr...@bigendiansmalls.com>: > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack > as anything today. > > > On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Still never would have occurred without a valid userid. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > > > No. > > > > From the link you cite: > > > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > > > > His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Monday, May 6, 2019 11:17 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > > > #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > > > > #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Sunday, May 5, 2019 10:00 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. > On May 6, 2019, at 21:43, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Still never would have occurred without a valid userid. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
So was it hacked 100’s of times then? Since it’s so easy? Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:04 PM, ITschak Mugzach wrote: Zos 1.x used to ship uads with users tso00 to tso03 (or 1-4), so passwords could be collected from another system. Used this to penetrate the mainframe. Tx god ibm stop shipping pre loaded uads. בתאריך יום ב׳, 6 במאי 2019, 22:54, מאת Bigendian Smalls < mainfr...@bigendiansmalls.com>: > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack > as anything today. > > > On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Still never would have occurred without a valid userid. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > > > No. > > > > From the link you cite: > > > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > > > > His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Monday, May 6, 2019 11:17 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > > > #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > > > > #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Sunday, May 5, 2019 10:00 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscrib
Re: mainframe hacking "success stories"?
Bill, would you care to back that sweeping generalization up with some detail? > On May 6, 2019, at 22:06, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Completely different. Hacking Microsoft is way easier. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls > wrote: > > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack as > anything today. > >> On May 6, 2019, at 21:43, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> Still never would have occurred without a valid userid. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: >> >> No. >> >> From the link you cite: >> >> "According to various sources, the hackers succeeded in finding (and >> exploiting) at least 2 previously unknown errors enabling them to raise >> their authorisations in the system. One of them was an error in an IBM HTTP >> server and the other one was an error in the CNMEUNIX file, which in the >> default configuration has SUID 0 authorisations (which means that by >> leveraging on the errors it contains, one is able to execute commands with >> the system administrator’s authorisations)." >> >> His "user" access to InfoTorg was not a problem for the mainframe. (It was a >> problem for the MPAA lawyer whose account he accessed, but not for the >> mainframe in general.) The above mainframe security vulnerability was. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Monday, May 6, 2019 11:17 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> The Pirate Bay hack acquired a valid mainframe userid and password off of a >> Microsoft laptop. In effect, not really a mainframe hack. He just logged on. >> https://badcyber.com/a-history-of-a-hacking/ >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: >> >> #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a >> legitimate part of the mainframe, which it has been for 20 years or so). It >> was an exploit of CGI buffer overrun. >> >> #2: It drives me nuts to hear mainframers explain away mainframe breaches. >> "It wasn't really a mainframe hack, they got in through USS." "It wasn't >> really a mainframe hack, they re-used a Windows password." "It wasn't really >> a mainframe hack ... whatever." If your CEO was standing in front of the >> press explaining how your company let x million credit card numbers go >> astray, would it matter HOW they got into your mainframe, or only that they >> DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows >> password, or whatever, you need to fix THAT, or risk having to explain to >> your CEO why he got fired (like Target's) for letting all those credit card >> numbers go astray. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Sunday, May 5, 2019 10:00 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> Wasn’t really a mainframe hack. It was a laptop hack that acquired >> legitimate mainframe credentials. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: mainframe hacking "success stories"?
40 years of mainframe experience and you are talking a handful of mainframe “hacks” versus thousands of Microsoft hacks. Maybe tens of thousands. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls wrote: Bill, would you care to back that sweeping generalization up with some detail? > On May 6, 2019, at 22:06, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Completely different. Hacking Microsoft is way easier. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls > wrote: > > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack as > anything today. > >> On May 6, 2019, at 21:43, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> Still never would have occurred without a valid userid. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: >> >> No. >> >> From the link you cite: >> >> "According to various sources, the hackers succeeded in finding (and >> exploiting) at least 2 previously unknown errors enabling them to raise >> their authorisations in the system. One of them was an error in an IBM HTTP >> server and the other one was an error in the CNMEUNIX file, which in the >> default configuration has SUID 0 authorisations (which means that by >> leveraging on the errors it contains, one is able to execute commands with >> the system administrator’s authorisations)." >> >> His "user" access to InfoTorg was not a problem for the mainframe. (It was a >> problem for the MPAA lawyer whose account he accessed, but not for the >> mainframe in general.) The above mainframe security vulnerability was. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Monday, May 6, 2019 11:17 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> The Pirate Bay hack acquired a valid mainframe userid and password off of a >> Microsoft laptop. In effect, not really a mainframe hack. He just logged on. >> https://badcyber.com/a-history-of-a-hacking/ >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: >> >> #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a >> legitimate part of the mainframe, which it has been for 20 years or so). It >> was an exploit of CGI buffer overrun. >> >> #2: It drives me nuts to hear mainframers explain away mainframe breaches. >> "It wasn't really a mainframe hack, they got in through USS." "It wasn't >> really a mainframe hack, they re-used a Windows password." "It wasn't really >> a mainframe hack ... whatever." If your CEO was standing in front of the >> press explaining how your company let x million credit card numbers go >> astray, would it matter HOW they got into your mainframe, or only that they >> DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows >> password, or whatever, you need to fix THAT, or risk having to explain to >> your CEO why he got fired (like Target's) for letting all those credit card >> numbers go astray. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Sunday, May 5, 2019 10:00 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> Wasn’t really a mainframe hack. It was a laptop hack that acquired >> legitimate mainframe credentials. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > For IBM-MAIN subscribe / signoff / archive
Re: mainframe hacking "success stories"?
It’s why banks stay on the mainframe. Security. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls wrote: Bill, would you care to back that sweeping generalization up with some detail? > On May 6, 2019, at 22:06, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Completely different. Hacking Microsoft is way easier. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls > wrote: > > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack as > anything today. > >> On May 6, 2019, at 21:43, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> Still never would have occurred without a valid userid. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: >> >> No. >> >> From the link you cite: >> >> "According to various sources, the hackers succeeded in finding (and >> exploiting) at least 2 previously unknown errors enabling them to raise >> their authorisations in the system. One of them was an error in an IBM HTTP >> server and the other one was an error in the CNMEUNIX file, which in the >> default configuration has SUID 0 authorisations (which means that by >> leveraging on the errors it contains, one is able to execute commands with >> the system administrator’s authorisations)." >> >> His "user" access to InfoTorg was not a problem for the mainframe. (It was a >> problem for the MPAA lawyer whose account he accessed, but not for the >> mainframe in general.) The above mainframe security vulnerability was. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Monday, May 6, 2019 11:17 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> The Pirate Bay hack acquired a valid mainframe userid and password off of a >> Microsoft laptop. In effect, not really a mainframe hack. He just logged on. >> https://badcyber.com/a-history-of-a-hacking/ >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: >> >> #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a >> legitimate part of the mainframe, which it has been for 20 years or so). It >> was an exploit of CGI buffer overrun. >> >> #2: It drives me nuts to hear mainframers explain away mainframe breaches. >> "It wasn't really a mainframe hack, they got in through USS." "It wasn't >> really a mainframe hack, they re-used a Windows password." "It wasn't really >> a mainframe hack ... whatever." If your CEO was standing in front of the >> press explaining how your company let x million credit card numbers go >> astray, would it matter HOW they got into your mainframe, or only that they >> DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows >> password, or whatever, you need to fix THAT, or risk having to explain to >> your CEO why he got fired (like Target's) for letting all those credit card >> numbers go astray. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Bill Johnson >> Sent: Sunday, May 5, 2019 10:00 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: mainframe hacking "success stories"? >> >> Wasn’t really a mainframe hack. It was a laptop hack that acquired >> legitimate mainframe credentials. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM question
Not a COBOL programmer, but wouldn't file status 34 be issued in such a case? Or DECLARATIVEs? On Mon, 6 May 2019 14:15:06 -0400 scott Ford wrote: :>I have a QSAM question. If I have a Cobol program writing to a QSAM file :>and it runs out of space on the file, i.e.; SB37 , can i recover from the :>SB37 without manual intervention. :>A possible condition handler ? :>If I write and Assembler I/O routine to be called passing the data to and :>writing to the QSAM file, the same question, my assumption is "yes" and can :>someone point me to the manual I assume it DFSMSdfp working with datasets -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
No. It has nothing to do with security. It is a lagend. Penetrated all my clients. The reason is convertion complexity, tco and simplicity. Security, in a nut shell is what your sysprog does. Only few security guys left to guide them. בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > Bill, would you care to back that sweeping generalization up with some > detail? > > > On May 6, 2019, at 22:06, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Completely different. Hacking Microsoft is way easier. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > > > Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > > > >> On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Still never would have occurred without a valid userid. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 3:18 PM, Charles Mills > wrote: > >> > >> No. > >> > >> From the link you cite: > >> > >> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >> > >> His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Monday, May 6, 2019 11:17 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 1:21 PM, Charles Mills > wrote: > >> > >> #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > >> > >> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Sunday, May 5, 2019 10:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists.
Re: QSAM question
Binyamin, Sir your correct. Todah Rabah Scott On Mon, May 6, 2019 at 4:21 PM Binyamin Dissen wrote: > Not a COBOL programmer, but wouldn't file status 34 be issued in such a > case? > > Or DECLARATIVEs? > > On Mon, 6 May 2019 14:15:06 -0400 scott Ford wrote: > > :>I have a QSAM question. If I have a Cobol program writing to a QSAM file > :>and it runs out of space on the file, i.e.; SB37 , can i recover from > the > :>SB37 without manual intervention. > :>A possible condition handler ? > > :>If I write and Assembler I/O routine to be called passing the data to and > :>writing to the QSAM file, the same question, my assumption is "yes" and > can > :>someone point me to the manual I assume it DFSMSdfp working with datasets > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: QSAM question
[Default] On 6 May 2019 11:15:28 -0700, in bit.listserv.ibm-main idfli...@gmail.com (scott Ford) wrote: >All: > >I have a QSAM question. If I have a Cobol program writing to a QSAM file >and it runs out of space on the file, i.e.; SB37 , can i recover from the >SB37 without manual intervention. >A possible condition handler ? If you just want to extend the data set proper use of SMS or a package like Stop X37 is probably the answer. If there is some other action to be taken that is unique to the program a status code can be associated with the file and all I-O related to that file can and must be checked for non-zero completion codes (34 on output is a file full or X37 condition for QSAM). This includes OPEN and CLOSE statements. Failure to do so can lead to interesting and normally bad results. To the best of my knowledge COBOL does not have anything that would allow you to extend the file or number of tape volumes allocated to the file. Clark Morris > >If I write and Assembler I/O routine to be called passing the data to and >writing to the QSAM file, the same question, my assumption is "yes" and can >someone point me to the manual I assume it DFSMSdfp working with datasets >... > >Regards, >Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=0 (was: Crazy ...)
BLKSIZE=0 requests "System-Determined Block size". It is indeed the best option. Presumably the "system" has all the relevant facts and knowledge at its disposal. Which is likely at least as much as you know. However, BLKSIZE is one of the many things carried over from medieval times where the amount of core used, how long your reads stayed connected to a channel, how efficiently DASD at $1000/mb was used, and various other no-longer-relevant considerations factored into that specification. sas On Mon, May 6, 2019 at 2:08 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 6 May 2019 16:44:47 +, Seymour J Metz wrote: > > >Not that I know of, other then the SMF records for the input and output. > > > >From: Paul Gilmartin > >Sent: Friday, May 3, 2019 1:42 PM > > > >When IEBCOPY reblocks a module, does it leave any audit trail? That > >might be of interest in case of the OP's problem. > > > Amidst the nattering about 32760 vs. half-track vs. 4KiB vs. ... > I suggested coding BLKSIZE=0. That received neither support nor > opposition. So, I wonder: > > Does coding BLKSIZE=0 ever lead to complete failure of a utility or > product? > I encountered one many years ago. It was promptly fixed by APAR. > > Does BLKSIZE=0 ever lead to suboptimum performance? > > There might be trivial exceptions for unlabelled tapes with DISP=MOD > or for IEBGENER where SYSUT1 is already adversely blocked. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Well, RSM and Vanguard and so forth claim they never do a pen test that does not succeed, so I guess yes, hacked hundreds of times. Of course, maybe hackers aren't as smart as pen testers ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? So was it hacked 100’s of times then? Since it’s so easy? Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:04 PM, ITschak Mugzach wrote: Zos 1.x used to ship uads with users tso00 to tso03 (or 1-4), so passwords could be collected from another system. Used this to penetrate the mainframe. Tx god ibm stop shipping pre loaded uads. בתאריך יום ב׳, 6 במאי 2019, 22:54, מאת Bigendian Smalls < mainfr...@bigendiansmalls.com>: > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack > as anything today. > > > On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Still never would have occurred without a valid userid. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > > > No. > > > > From the link you cite: > > > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > > > > His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Monday, May 6, 2019 11:17 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > > > #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > > > > #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Sunday, May 5, 2019 10:00 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > --
Re: mainframe hacking "success stories"?
You're right. And you get to explain to your CEO how it wasn't really a mainframe hack because they had a userid and Windows gets hacked all the time. Denial ain't just a river in Egypt. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. > On May 6, 2019, at 21:43, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Still never would have occurred without a valid userid. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---
Re: mainframe hacking "success stories"?
> How does one audit for shared Windows passwords, even when they may be > encrypted and salted? Good question. I guess the answer to this and all similar questions is "MFA". Two factor authentication solves a lot of problems, or at least makes them a whole lot less likely. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 6, 2019 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? On Mon, 6 May 2019 10:21:25 -0700, Charles Mills wrote: >#1: Noo. It was a legitimate mainframe hack (assuming you consider USS a >legitimate part of the mainframe, which it has been for 20 years or so). It >was an exploit of CGI buffer overrun. > Was that Shellshock? Is only bash susceptible to Shellshock. That feature is so vulnerable that it ought to be withdrawn; reliance on filtering inputs is hardly sufficient. >#2: It drives me nuts to hear mainframers explain away mainframe breaches. "It >wasn't really a mainframe hack, they got in through USS." "It wasn't really a >mainframe hack, they re-used a Windows password." "It wasn't really a >mainframe hack ... whatever." If your CEO was standing in front of the press >explaining how your company let x million credit card numbers go astray, would >it matter HOW they got into your mainframe, or only that they DID?" If your >mainframe is vulnerable to a USS hack, or a shared Windows password, or >whatever, you need to fix THAT, or risk having to explain to your CEO why he >got fired (like Target's) for letting all those credit card numbers go astray. > +1 It doesn't matter. How does one audit for shared Windows passwords, even when they may be encrypted and salted? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
On 5/6/19 1:42 PM, Bill Johnson wrote: > Still never would have occurred without a valid userid. Think about it this way: Would a DBA be able to get away saying that "the DB was copied because a mainframe operator reused their mainframe credentials as their credentials to access the RDBMS."? (Regardless of how the credentials were actually acquired.) My bet is that such a response would not hold any water and the DBA would be expected to better secure the RDBMS. I feel like the same methodology & standards apply to the mainframe as it does to the RDBMS. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
I was a DBA. Anyone who has valid access, no matter how they got it, doesn’t qualify as a hack of that platform. Nearly every bank in the world still uses the mainframe. Why? Because it is almost impenetrable by regular hacking means. So do most insurance companies for the same reason. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 7:30 PM, Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: On 5/6/19 1:42 PM, Bill Johnson wrote: > Still never would have occurred without a valid userid. Think about it this way: Would a DBA be able to get away saying that "the DB was copied because a mainframe operator reused their mainframe credentials as their credentials to access the RDBMS."? (Regardless of how the credentials were actually acquired.) My bet is that such a response would not hold any water and the DBA would be expected to better secure the RDBMS. I feel like the same methodology & standards apply to the mainframe as it does to the RDBMS. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
The mainframe hasn’t even been hack 5 times. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 7:04 PM, Charles Mills wrote: Well, RSM and Vanguard and so forth claim they never do a pen test that does not succeed, so I guess yes, hacked hundreds of times. Of course, maybe hackers aren't as smart as pen testers ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 1:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? So was it hacked 100’s of times then? Since it’s so easy? Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:04 PM, ITschak Mugzach wrote: Zos 1.x used to ship uads with users tso00 to tso03 (or 1-4), so passwords could be collected from another system. Used this to penetrate the mainframe. Tx god ibm stop shipping pre loaded uads. בתאריך יום ב׳, 6 במאי 2019, 22:54, מאת Bigendian Smalls < mainfr...@bigendiansmalls.com>: > Which is how 80% of all the hacks today start. Find purchase and advance > your position. This is how the game is played. It was as classic of a hack > as anything today. > > > On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Still never would have occurred without a valid userid. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > > > No. > > > > From the link you cite: > > > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > > > > His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Monday, May 6, 2019 11:17 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > > > #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > > > > #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > > Sent: Sunday, May 5, 2019 10:00 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send emai
Re: mainframe hacking "success stories"?
Yeah, how dare a lurker challenge the people who dominate the board. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 7:06 PM, Charles Mills wrote: You're right. And you get to explain to your CEO how it wasn't really a mainframe hack because they had a userid and Windows gets hacked all the time. Denial ain't just a river in Egypt. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. > On May 6, 2019, at 21:43, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > Still never would have occurred without a valid userid. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: > > No. > > From the link you cite: > > "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise their > authorisations in the system. One of them was an error in an IBM HTTP server > and the other one was an error in the CNMEUNIX file, which in the default > configuration has SUID 0 authorisations (which means that by leveraging on > the errors it contains, one is able to execute commands with the system > administrator’s authorisations)." > > His "user" access to InfoTorg was not a problem for the mainframe. (It was a > problem for the MPAA lawyer whose account he accessed, but not for the > mainframe in general.) The above mainframe security vulnerability was. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Monday, May 6, 2019 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > The Pirate Bay hack acquired a valid mainframe userid and password off of a > Microsoft laptop. In effect, not really a mainframe hack. He just logged on. > https://badcyber.com/a-history-of-a-hacking/ > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: > > #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a > legitimate part of the mainframe, which it has been for 20 years or so). It > was an exploit of CGI buffer overrun. > > #2: It drives me nuts to hear mainframers explain away mainframe breaches. > "It wasn't really a mainframe hack, they got in through USS." "It wasn't > really a mainframe hack, they re-used a Windows password." "It wasn't really > a mainframe hack ... whatever." If your CEO was standing in front of the > press explaining how your company let x million credit card numbers go > astray, would it matter HOW they got into your mainframe, or only that they > DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows > password, or whatever, you need to fix THAT, or risk having to explain to > your CEO why he got fired (like Target's) for letting all those credit card > numbers go astray. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Sunday, May 5, 2019 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: mainframe hacking "success stories"? > > Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate > mainframe credentials. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MA
Re: mainframe hacking "success stories"?
LOL, sure. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:23 PM, ITschak Mugzach wrote: No. It has nothing to do with security. It is a lagend. Penetrated all my clients. The reason is convertion complexity, tco and simplicity. Security, in a nut shell is what your sysprog does. Only few security guys left to guide them. בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > Bill, would you care to back that sweeping generalization up with some > detail? > > > On May 6, 2019, at 22:06, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Completely different. Hacking Microsoft is way easier. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > > > Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > > > >> On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Still never would have occurred without a valid userid. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 3:18 PM, Charles Mills > wrote: > >> > >> No. > >> > >> From the link you cite: > >> > >> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >> > >> His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Monday, May 6, 2019 11:17 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 1:21 PM, Charles Mills > wrote: > >> > >> #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > >> > >> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Sunday, May 5, 2019 10:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >>
Re: mainframe hacking "success stories"?
Wrong. https://www.americanbanker.com/news/why-citi-is-buying-ibms-new-mainframe-for-mobile-transactions Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:23 PM, ITschak Mugzach wrote: No. It has nothing to do with security. It is a lagend. Penetrated all my clients. The reason is convertion complexity, tco and simplicity. Security, in a nut shell is what your sysprog does. Only few security guys left to guide them. בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > Bill, would you care to back that sweeping generalization up with some > detail? > > > On May 6, 2019, at 22:06, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Completely different. Hacking Microsoft is way easier. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > > > Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > > > >> On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Still never would have occurred without a valid userid. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 3:18 PM, Charles Mills > wrote: > >> > >> No. > >> > >> From the link you cite: > >> > >> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >> > >> His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Monday, May 6, 2019 11:17 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 1:21 PM, Charles Mills > wrote: > >> > >> #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > >> > >> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Sunday, May 5, 2019 10:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the messag
Re: mainframe hacking "success stories"?
Read up. https://www.allerin.com/blog/why-do-banks-still-use-mainframes Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:23 PM, ITschak Mugzach wrote: No. It has nothing to do with security. It is a lagend. Penetrated all my clients. The reason is convertion complexity, tco and simplicity. Security, in a nut shell is what your sysprog does. Only few security guys left to guide them. בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > Bill, would you care to back that sweeping generalization up with some > detail? > > > On May 6, 2019, at 22:06, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Completely different. Hacking Microsoft is way easier. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > > > Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > > > >> On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Still never would have occurred without a valid userid. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 3:18 PM, Charles Mills > wrote: > >> > >> No. > >> > >> From the link you cite: > >> > >> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >> > >> His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Monday, May 6, 2019 11:17 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 1:21 PM, Charles Mills > wrote: > >> > >> #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > >> > >> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Sunday, May 5, 2019 10:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >
Re: mainframe hacking "success stories"?
Security: Banks deal with a lot of sensitive and confidential information. Security is a non-negotiable concern with them. Mainframes have security built into them from the ground up. Through cryptographic hardware acceleration and secure operating system, mainframes fulfill the critical requirement of keeping the user and internal data protected. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:23 PM, ITschak Mugzach wrote: No. It has nothing to do with security. It is a lagend. Penetrated all my clients. The reason is convertion complexity, tco and simplicity. Security, in a nut shell is what your sysprog does. Only few security guys left to guide them. בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > Bill, would you care to back that sweeping generalization up with some > detail? > > > On May 6, 2019, at 22:06, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > Completely different. Hacking Microsoft is way easier. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > > > > Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > > > >> On May 6, 2019, at 21:43, Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> Still never would have occurred without a valid userid. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 3:18 PM, Charles Mills > wrote: > >> > >> No. > >> > >> From the link you cite: > >> > >> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >> > >> His "user" access to InfoTorg was not a problem for the mainframe. (It > was a problem for the MPAA lawyer whose account he accessed, but not for > the mainframe in general.) The above mainframe security vulnerability was. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Monday, May 6, 2019 11:17 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> The Pirate Bay hack acquired a valid mainframe userid and password off > of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 1:21 PM, Charles Mills > wrote: > >> > >> #1: Noo. It was a legitimate mainframe hack (assuming you consider > USS a legitimate part of the mainframe, which it has been for 20 years or > so). It was an exploit of CGI buffer overrun. > >> > >> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >> > >> Charles > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >> Sent: Sunday, May 5, 2019 10:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: mainframe hacking "success stories"? > >> > >> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua
Re: BLKSIZE=0 (was: Crazy ...)
What about BUFL=? As I recall, I used to use this to keep from having problems with concatenations... By having a buffer length equal to or larger than any buffer one might read... And we really were beyond CORE in those days. But it is true, C-STORE was expensive. Regards, Steve Thompson On 5/6/19 6:52 PM, Steve Smith wrote: BLKSIZE=0 requests "System-Determined Block size". It is indeed the best option. Presumably the "system" has all the relevant facts and knowledge at its disposal. Which is likely at least as much as you know. However, BLKSIZE is one of the many things carried over from medieval times where the amount of core used, how long your reads stayed connected to a channel, how efficiently DASD at $1000/mb was used, and various other no-longer-relevant considerations factored into that specification. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Ok, but why is Windows easier to hack than the mainframe? Personally, I'd find a mainframe far easier to hack because I know a little bit about control blocks, APF auth, SVC's, subsystems, address spaces, RACF, etc., and I know far less about the equivalents on Windows. But of course the first step is to get any kind of userid, and that's done by pretty-much the same methods - regardless of platform. On 5/6/2019 1:18 PM, Bill Johnson wrote: It’s why banks stay on the mainframe. Security. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls wrote: Bill, would you care to back that sweeping generalization up with some detail? On May 6, 2019, at 22:06, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. On May 6, 2019, at 21:43, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Still never would have occurred without a valid userid. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: No. From the link you cite: "According to various sources, the hackers succeeded in finding (and exploiting) at least 2 previously unknown errors enabling them to raise their authorisations in the system. One of them was an error in an IBM HTTP server and the other one was an error in the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which means that by leveraging on the errors it contains, one is able to execute commands with the system administrator’s authorisations)." His "user" access to InfoTorg was not a problem for the mainframe. (It was a problem for the MPAA lawyer whose account he accessed, but not for the mainframe in general.) The above mainframe security vulnerability was. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? The Pirate Bay hack acquired a valid mainframe userid and password off of a Microsoft laptop. In effect, not really a mainframe hack. He just logged on. https://badcyber.com/a-history-of-a-hacking/ Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe
Re: mainframe hacking "success stories"?
A plethora of reasons. Lack of emphasis on security by MSFT. More interest in selling the next release than securing each release. Buggy code. Went to a security seminar once where it was stated that MSFT code had one bug for every 25 lines of code. IBM was around one bug every 250 lines and NASA was one bug every 10,000 lines. Called KLOC. MSFT is also more available. There are millions of possible targets. That’s why Safari was less exposed to hack than IE. IE had a much larger install base so was more targeted. Many other reasons. Hackers tend to target the easier platform. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 9:27 PM, Tom Brennan wrote: Ok, but why is Windows easier to hack than the mainframe? Personally, I'd find a mainframe far easier to hack because I know a little bit about control blocks, APF auth, SVC's, subsystems, address spaces, RACF, etc., and I know far less about the equivalents on Windows. But of course the first step is to get any kind of userid, and that's done by pretty-much the same methods - regardless of platform. On 5/6/2019 1:18 PM, Bill Johnson wrote: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls > wrote: > > Bill, would you care to back that sweeping generalization up with some detail? > >> On May 6, 2019, at 22:06, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> Completely different. Hacking Microsoft is way easier. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls >> wrote: >> >> Which is how 80% of all the hacks today start. Find purchase and advance >> your position. This is how the game is played. It was as classic of a hack >> as anything today. >> >>> On May 6, 2019, at 21:43, Bill Johnson >>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Still never would have occurred without a valid userid. >>> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: >>> >>> No. >>> >>> From the link you cite: >>> >>> "According to various sources, the hackers succeeded in finding (and >>> exploiting) at least 2 previously unknown errors enabling them to raise >>> their authorisations in the system. One of them was an error in an IBM HTTP >>> server and the other one was an error in the CNMEUNIX file, which in the >>> default configuration has SUID 0 authorisations (which means that by >>> leveraging on the errors it contains, one is able to execute commands with >>> the system administrator’s authorisations)." >>> >>> His "user" access to InfoTorg was not a problem for the mainframe. (It was >>> a problem for the MPAA lawyer whose account he accessed, but not for the >>> mainframe in general.) The above mainframe security vulnerability was. >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>> Behalf Of Bill Johnson >>> Sent: Monday, May 6, 2019 11:17 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: mainframe hacking "success stories"? >>> >>> The Pirate Bay hack acquired a valid mainframe userid and password off of a >>> Microsoft laptop. In effect, not really a mainframe hack. He just logged >>> on. https://badcyber.com/a-history-of-a-hacking/ >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: >>> >>> #1: Noo. It was a legitimate mainframe hack (assuming you consider USS >>> a legitimate part of the mainframe, which it has been for 20 years or so). >>> It was an exploit of CGI buffer overrun. >>> >>> #2: It drives me nuts to hear mainframers explain away mainframe breaches. >>> "It wasn't really a mainframe hack, they got in through USS." "It wasn't >>> really a mainframe hack, they re-used a Windows password." "It wasn't >>> really a mainframe hack ... whatever." If your CEO was standing in front of >>> the press explaining how your company let x million credit card numbers go >>> astray, would it matter HOW they got into your mainframe, or only that they >>> DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows >>> password, or whatever, you need to fix THAT, or risk having to explain to >>> your CEO why he got fired (like Target's) for letting all those credit card >>> numbers go astray. >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>> Behalf Of Bill Johnson >>> Sent: Sunday, May 5, 2019 10:00 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: mainframe hacking "success stories"? >>> >>> Wasn’t really a mainframe hack. It was a laptop hack that acquired >>> legitimate mainframe credentials. >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive
Re: mainframe hacking "success stories"?
How do you get a userid for a mainframe hack attempt? How do you insure it’s one with decent security access? Knowing very few have APF access. I’ve never actually seen a mainframe hacked in 40 years and 15 different shops. Also never heard of one at shops in the Ohio, Pennsylvania area that I didn’t work. I’ve heard of potential holes but never seen it happen. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 9:27 PM, Tom Brennan wrote: Ok, but why is Windows easier to hack than the mainframe? Personally, I'd find a mainframe far easier to hack because I know a little bit about control blocks, APF auth, SVC's, subsystems, address spaces, RACF, etc., and I know far less about the equivalents on Windows. But of course the first step is to get any kind of userid, and that's done by pretty-much the same methods - regardless of platform. On 5/6/2019 1:18 PM, Bill Johnson wrote: > It’s why banks stay on the mainframe. Security. > > > Sent from Yahoo Mail for iPhone > > > On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls > wrote: > > Bill, would you care to back that sweeping generalization up with some detail? > >> On May 6, 2019, at 22:06, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> Completely different. Hacking Microsoft is way easier. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls >> wrote: >> >> Which is how 80% of all the hacks today start. Find purchase and advance >> your position. This is how the game is played. It was as classic of a hack >> as anything today. >> >>> On May 6, 2019, at 21:43, Bill Johnson >>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> Still never would have occurred without a valid userid. >>> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: >>> >>> No. >>> >>> From the link you cite: >>> >>> "According to various sources, the hackers succeeded in finding (and >>> exploiting) at least 2 previously unknown errors enabling them to raise >>> their authorisations in the system. One of them was an error in an IBM HTTP >>> server and the other one was an error in the CNMEUNIX file, which in the >>> default configuration has SUID 0 authorisations (which means that by >>> leveraging on the errors it contains, one is able to execute commands with >>> the system administrator’s authorisations)." >>> >>> His "user" access to InfoTorg was not a problem for the mainframe. (It was >>> a problem for the MPAA lawyer whose account he accessed, but not for the >>> mainframe in general.) The above mainframe security vulnerability was. >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>> Behalf Of Bill Johnson >>> Sent: Monday, May 6, 2019 11:17 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: mainframe hacking "success stories"? >>> >>> The Pirate Bay hack acquired a valid mainframe userid and password off of a >>> Microsoft laptop. In effect, not really a mainframe hack. He just logged >>> on. https://badcyber.com/a-history-of-a-hacking/ >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: >>> >>> #1: Noo. It was a legitimate mainframe hack (assuming you consider USS >>> a legitimate part of the mainframe, which it has been for 20 years or so). >>> It was an exploit of CGI buffer overrun. >>> >>> #2: It drives me nuts to hear mainframers explain away mainframe breaches. >>> "It wasn't really a mainframe hack, they got in through USS." "It wasn't >>> really a mainframe hack, they re-used a Windows password." "It wasn't >>> really a mainframe hack ... whatever." If your CEO was standing in front of >>> the press explaining how your company let x million credit card numbers go >>> astray, would it matter HOW they got into your mainframe, or only that they >>> DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows >>> password, or whatever, you need to fix THAT, or risk having to explain to >>> your CEO why he got fired (like Target's) for letting all those credit card >>> numbers go astray. >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>> Behalf Of Bill Johnson >>> Sent: Sunday, May 5, 2019 10:00 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: mainframe hacking "success stories"? >>> >>> Wasn’t really a mainframe hack. It was a laptop hack that acquired >>> legitimate mainframe credentials. >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> >>> >>> -- >>> For IBM-MAIN subscribe / signoff /
Re: mainframe hacking "success stories"?
I know there are other reasons, but the one I always trot out at this point in the conversation is that Windows is a younger OS. The mainframe has been around a couple more decades than Windows, so there's been more time to spot and plug holes. Plus, for the first decade or so of Windows' life it was essentially a one-operator OS; whatever you did to Windows was just you, not (usually) someone reaching in from outside. Then, too, it took a while for MS to get religion about security. But first and foremost, IMVHO, it's that MVS has been around so much longer. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If the Earth were flat, cats would have pushed everything off it by now. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Monday, May 6, 2019 21:27 Ok, but why is Windows easier to hack than the mainframe? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Itschak, I'm not sure what you're asking but there's quite a bit of documentation on the Logica break-in. I had to do a report on it for my employers a few years ago, and I cited six or seven sources for it. Do you want them? I can send you a copy, although I wouldn't want you to think I'm claiming expertise in the subject. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If the Earth were flat, cats would have pushed everything off it by now. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITschak Mugzach Sent: Sunday, May 5, 2019 13:13 I know "how to", doing that every day. I am looking for real events that was published. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
"Once they’d downloaded the RACF database, they subjected it to a password-cracking tool. John the Ripper is one such tool, widely available on the internet. On Feb 28, about the same time the RACF database was downloaded, some questions appeared on the mailing list PaulDotCom about hashing methods for RACF; by March 3rd, apparently in response, John the Ripper had been enhanced to include the capability of working on RACF passwords, in collaboration with another tool call CRACF. "In the Zauf article is this description: 'Creating a password hash algorithm works like this: After entering the password, it is padded with spaces, if necessary, to a length of 8 bytes. Each character is then XORed with x‘55’ and shifted left one bit. Then the user ID is DES-encrypted, using the modified password as the DES key. Developers took a few days to determine the algorithm and modify John the Ripper. Now the utility excels at hashing the RACF database.' It also mentioned a source-code module named racf2john.c, 'a tool that converts database file exported in the input data, read for JTR' [Google’s translation from Polish]. "By way of testing, investigators attempted to use these tools themselves to crack RACF passwords. They found that a great many passwords could be extracted, that they were easy to discover by dictionary attack, that they were not very complex and in many cases that they’d been unchanged from the default when the ID was created. Using a standalone PC they cracked about 30 000 passwords (out of 120 000 on Applicat’s database) in 'a couple of days'." --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If the Earth were flat, cats would have pushed everything off it by now. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, May 6, 2019 13:14 I *believe* that was done by investigators after the fact, attempting to determine how the attack might have been done. I don't recall that there is compelling evidence that Svartholm actually did that. It *is* trivially easy to do, assuming (a.) read access to the DB and (b.) old-style password storage. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Spiegel Sent: Sunday, May 5, 2019 8:02 AM One of the tricks he pulled was to offload the RACF Database to a PC and Dictionary Attack it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
In most shops only 2 people have the required access to the RACF database. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 11:06 PM, Bob Bridges wrote: "Once they’d downloaded the RACF database, they subjected it to a password-cracking tool. John the Ripper is one such tool, widely available on the internet. On Feb 28, about the same time the RACF database was downloaded, some questions appeared on the mailing list PaulDotCom about hashing methods for RACF; by March 3rd, apparently in response, John the Ripper had been enhanced to include the capability of working on RACF passwords, in collaboration with another tool call CRACF. "In the Zauf article is this description: 'Creating a password hash algorithm works like this: After entering the password, it is padded with spaces, if necessary, to a length of 8 bytes. Each character is then XORed with x‘55’ and shifted left one bit. Then the user ID is DES-encrypted, using the modified password as the DES key. Developers took a few days to determine the algorithm and modify John the Ripper. Now the utility excels at hashing the RACF database.' It also mentioned a source-code module named racf2john.c, 'a tool that converts database file exported in the input data, read for JTR' [Google’s translation from Polish]. "By way of testing, investigators attempted to use these tools themselves to crack RACF passwords. They found that a great many passwords could be extracted, that they were easy to discover by dictionary attack, that they were not very complex and in many cases that they’d been unchanged from the default when the ID was created. Using a standalone PC they cracked about 30 000 passwords (out of 120 000 on Applicat’s database) in 'a couple of days'." --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* If the Earth were flat, cats would have pushed everything off it by now. */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, May 6, 2019 13:14 I *believe* that was done by investigators after the fact, attempting to determine how the attack might have been done. I don't recall that there is compelling evidence that Svartholm actually did that. It *is* trivially easy to do, assuming (a.) read access to the DB and (b.) old-style password storage. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Spiegel Sent: Sunday, May 5, 2019 8:02 AM One of the tricks he pulled was to offload the RACF Database to a PC and Dictionary Attack it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Here's one: By acting dumb (well, even more than usual) I got the Help Desk where I worked to give me my name, the prod system id, my userid, and a password reset. I gave no information other than calling from my own desk phone. The real reason for the call was that I heard they were using the same string for all password reset requests, and (as one of the RACF support people) I wanted to surreptitiously test that. But when they answered the phone with "Hello Tom Brennan", I thought I'd take the ruse as far as possible. The Help Desk wants to help. On 5/6/2019 7:03 PM, Bill Johnson wrote: How do you get a userid for a mainframe hack attempt? How do you insure it’s one with decent security access? Knowing very few have APF access. I’ve never actually seen a mainframe hacked in 40 years and 15 different shops. Also never heard of one at shops in the Ohio, Pennsylvania area that I didn’t work. I’ve heard of potential holes but never seen it happen. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 9:27 PM, Tom Brennan wrote: Ok, but why is Windows easier to hack than the mainframe? Personally, I'd find a mainframe far easier to hack because I know a little bit about control blocks, APF auth, SVC's, subsystems, address spaces, RACF, etc., and I know far less about the equivalents on Windows. But of course the first step is to get any kind of userid, and that's done by pretty-much the same methods - regardless of platform. On 5/6/2019 1:18 PM, Bill Johnson wrote: It’s why banks stay on the mainframe. Security. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls wrote: Bill, would you care to back that sweeping generalization up with some detail? On May 6, 2019, at 22:06, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. On May 6, 2019, at 21:43, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Still never would have occurred without a valid userid. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: No. From the link you cite: "According to various sources, the hackers succeeded in finding (and exploiting) at least 2 previously unknown errors enabling them to raise their authorisations in the system. One of them was an error in an IBM HTTP server and the other one was an error in the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which means that by leveraging on the errors it contains, one is able to execute commands with the system administrator’s authorisations)." His "user" access to InfoTorg was not a problem for the mainframe. (It was a problem for the MPAA lawyer whose account he accessed, but not for the mainframe in general.) The above mainframe security vulnerability was. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? The Pirate Bay hack acquired a valid mainframe userid and password off of a Microsoft laptop. In effect, not really a mainframe hack. He just logged on. https://badcyber.com/a-history-of-a-hacking/ Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 1:21 PM, Charles Mills wrote: #1: Noo. It was a legitimate mainframe hack (assuming you consider USS a legitimate part of the mainframe, which it has been for 20 years or so). It was an exploit of CGI buffer overrun. #2: It drives me nuts to hear mainframers explain away mainframe breaches. "It wasn't really a mainframe hack, they got in through USS." "It wasn't really a mainframe hack, they re-used a Windows password." "It wasn't really a mainframe hack ... whatever." If your CEO was standing in front of the press explaining how your company let x million credit card numbers go astray, would it matter HOW they got into your mainframe, or only that they DID?" If your mainframe is vulnerable to a USS hack, or a shared Windows password, or whatever, you need to fix THAT, or risk having to explain to your CEO why he got fired (like Target's) for letting all those credit card numbers go astray. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, May 5, 2019 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate mainframe credentials. --
Re: mainframe hacking "success stories"?
For the mainframe, one of the words I like to use is "Integrity". The hardware designers and programmers did not want to let any error, no matter how small, go unnoticed. A quick example: On a real 3278 terminal if you tried to type on top of a protected field, the box made a clicky noise and locked the keyboard from further input until you pressed Reset. This is Integrity, protecting the data entry clerk from missing even a single character on that COBOL coding form. Same with the OS of course - with all the logging and SMF and error recovery and message manuals a mile long. You don't see anything close to this in Windows and Linux/Unix. In fact, on those platforms it's sometimes the opposite... Call a subroutine, forget to check the return code, and the program continues on as if nothing happened - good luck. On the mainframe, if I call an SVC and it fails I get an abend by default with a decent message. That's just one small part of the built-in integrity the mainframe has over the other platforms. One of my old jokes working with Unix/Linux was: If you got an error that makes no sense, check to see if the disk ran out of space. I was surprised how often this turned out to be true. Over the years one of the bigger Windows/Unix hacks has been buffer overflows, I believe based on string copies with no supplied length (you keep copying bytes until you hit a zero). But variable fields on the mainframe typically had a length byte or halfword - so we avoided one of the bigger hacking issues. Well, until USS came along and C started being used for mainframe coding. But this all makes no difference when you find passwords.txt on a sysprog's laptop because the security folks decided the password needs to be changed each month to something impossible to remember. That's more the point I'm trying to make. On 5/6/2019 6:52 PM, Bill Johnson wrote: A plethora of reasons. Lack of emphasis on security by MSFT. More interest in selling the next release than securing each release. Buggy code. Went to a security seminar once where it was stated that MSFT code had one bug for every 25 lines of code. IBM was around one bug every 250 lines and NASA was one bug every 10,000 lines. Called KLOC. MSFT is also more available. There are millions of possible targets. That’s why Safari was less exposed to hack than IE. IE had a much larger install base so was more targeted. Many other reasons. Hackers tend to target the easier platform. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 9:27 PM, Tom Brennan wrote: Ok, but why is Windows easier to hack than the mainframe? Personally, I'd find a mainframe far easier to hack because I know a little bit about control blocks, APF auth, SVC's, subsystems, address spaces, RACF, etc., and I know far less about the equivalents on Windows. But of course the first step is to get any kind of userid, and that's done by pretty-much the same methods - regardless of platform. On 5/6/2019 1:18 PM, Bill Johnson wrote: It’s why banks stay on the mainframe. Security. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls wrote: Bill, would you care to back that sweeping generalization up with some detail? On May 6, 2019, at 22:06, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Completely different. Hacking Microsoft is way easier. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls wrote: Which is how 80% of all the hacks today start. Find purchase and advance your position. This is how the game is played. It was as classic of a hack as anything today. On May 6, 2019, at 21:43, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Still never would have occurred without a valid userid. Sent from Yahoo Mail for iPhone On Monday, May 6, 2019, 3:18 PM, Charles Mills wrote: No. From the link you cite: "According to various sources, the hackers succeeded in finding (and exploiting) at least 2 previously unknown errors enabling them to raise their authorisations in the system. One of them was an error in an IBM HTTP server and the other one was an error in the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which means that by leveraging on the errors it contains, one is able to execute commands with the system administrator’s authorisations)." His "user" access to InfoTorg was not a problem for the mainframe. (It was a problem for the MPAA lawyer whose account he accessed, but not for the mainframe in general.) The above mainframe security vulnerability was. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, May 6, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? The Pirate Bay hack acquired a valid mainframe userid and password off of a
Re: mainframe hacking "success stories"?
Bill Johnson wrote:
>Mainframes have security built into them from the ground up.
>Through cryptographic hardware acceleration and secure operating
>system, mainframes fulfill the critical requirement of keeping
>the user and internal data protected.
There are many excellent security attributes included with and available
for IBM mainframes, true, agreed. Moreover, the architectural patterns that
mainframes uniquely facilitate can be quite helpful in raising and
enforcing enterprise security levels. More highly centralized, well
managed, richer information services offer certain inherent
security-related advantages.
That said, I'm quite concerned (paranoid, even) because these wonderful
security features so frequently either aren't implemented at all or are
implemented badly, inconsistently. Also, unfortunately, there are far too
many organizations running unsupported technologies with known security
vulnerabilities, and there are even more that do not have reasonable,
timely preventive maintenance programs that they execute consistently and
well.
I was probably working on helping a government get SSL (then, now evolved
into TLS) encryption turned on for ALL their mainframe network connections
("internal" and "external"), and with certificate authentications (client
and server), literally 20 years ago today. SSL significantly predates z/OS.
Yet here we are, 20 years later, and so many organizations haven't even
done that much. It's upsetting.
I agree with the comment that there's always room for improvement, often
ample improvement. I assert that if you aren't concerned (or more) then you
aren't even awake.
Be careful out there, always. I don't think there was ever a time to rest
easy, and this era certainly isn't such a time.
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
