Re: Mainframe hacking (getting back on topic) / some inspirations on that topic
forgive us for the following recommendation: those installations, requiring a really secure mainframe, combatting even the most smart, but bad tricks, should feel free in * visiting the download section of our website, or in * attending our coming Share session 5419 - Managing Security in a Troubled Economy in denver, or in * searching for our presentation of Share session Mainframe Security Compliance - How to Prevent Subprime-like Bubbles and Self-deceptions (austin this year). cheers stephen --- Dr. Stephen Fedtke Enterprise-IT-Security.com Seestrasse 3a CH-6300 Zug Switzerland Tel. ++41-(0)41-710-4005 www.enterprise-it-security.com Meet you at Share in Denver! Visit our session 5419 - Managing Security in a Troubled Economy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Sun, 26 Jul 2009 22:54:52 -0700, Ed Gould ps2...@yahoo.com wrote: Not true... We had a programmer who wrote an SVC screener ... SVC screener = APF. APF means that you can update the dataset without opening it. So??? countless installations still do not have a clue about APF libraries. ... The so is that once you're talking about APF authorized programs MVS security concerns are no longer on the table - the door is open. The technique used at that point - manual response to a security prompt, automated response to a security prompt, access to the dataset without going through a security check, etc. doesn't really matter - technical details. If a shop has lax controls over authorized libraries then they indeed have a security problem, but it's not a mainframe problem; it's a management problem. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Patrick O'Keefe pisze: On Sun, 26 Jul 2009 22:54:52 -0700, Ed Gould ps2...@yahoo.com wrote: Not true... We had a programmer who wrote an SVC screener ... SVC screener = APF. APF means that you can update the dataset without opening it. So??? countless installations still do not have a clue about APF libraries. ... [...] If a shop has lax controls over authorized libraries then they indeed have a security problem, but it's not a mainframe problem; it's a management problem. IMHO very few installations do really have problem with APF libraries. And only few of them do have inproper access to APF libraries. This is not good idea to use one's own experience to judge the others. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
--- On Wed, 7/22/09, Binyamin Dissen bdis...@dissensoftware.com wrote: From: Binyamin Dissen bdis...@dissensoftware.com Subject: Re: Mainframe hacking (getting back on topic) To: IBM-MAIN@bama.ua.edu Date: Wednesday, July 22, 2009, 6:42 AM On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil gerh...@valley.net wrote: :Binyamin Dissen wrote: : Before RACF there were expiration dates. :Expiration dates are too easy to bypass. Required access to the console. - Not true... We had a programmer who wrote an SVC screener and issued the r xx,u for the update. He got away with it for quite some time. I was walking past the console one day and there were the messages and the reply flying past on the screen. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Sun, 26 Jul 2009 10:56:17 -0700 Ed Gould ps2...@yahoo.com wrote: :--- On Wed, 7/22/09, Binyamin Dissen bdis...@dissensoftware.com wrote: :From: Binyamin Dissen bdis...@dissensoftware.com :Subject: Re: Mainframe hacking (getting back on topic) :To: IBM-MAIN@bama.ua.edu :Date: Wednesday, July 22, 2009, 6:42 AM :On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil gerh...@valley.net :wrote: ::Binyamin Dissen wrote: :: Before RACF there were expiration dates. ::Expiration dates are too easy to bypass. :Required access to the console. :- :Not true... We had a programmer who wrote an SVC screener and issued the r xx,u for the update. He got away with it for quite some time. I was walking past the console one day and there were the messages and the reply flying past on the screen. SVC screener = APF. APF means that you can update the dataset without opening it. -- Binyamin Dissen bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
--- On Sun, 7/26/09, Binyamin Dissen bdis...@dissensoftware.com wrote: From: Binyamin Dissen bdis...@dissensoftware.com Subject: Re: Mainframe hacking (getting back on topic) To: IBM-MAIN@bama.ua.edu Date: Sunday, July 26, 2009, 2:39 PM On Sun, 26 Jul 2009 10:56:17 -0700 Ed Gould ps2...@yahoo.com wrote: :--- On Wed, 7/22/09, Binyamin Dissen bdis...@dissensoftware.com wrote: :From: Binyamin Dissen bdis...@dissensoftware.com :Subject: Re: Mainframe hacking (getting back on topic) :To: IBM-MAIN@bama.ua.edu :Date: Wednesday, July 22, 2009, 6:42 AM :On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil gerh...@valley.net :wrote: ::Binyamin Dissen wrote: :: Before RACF there were expiration dates. ::Expiration dates are too easy to bypass. :Required access to the console. :- :Not true... We had a programmer who wrote an SVC screener and issued the r xx,u for the update. He got away with it for quite some time. I was walking past the console one day and there were the messages and the reply flying past on the screen. SVC screener = APF. APF means that you can update the dataset without opening it. So??? countless installations still do not have a clue about APF libraries. I saw one installation that was putting production modules all liked with ac(1). They did not know why they just authorized it. There is no accounting for trust in some installations. Of course we know an wide open APF library is a real no no but again some installations have this buddy system and or management says it is to BE and they follow meekly without waving the flag. Frankly it is a bomb waiting to go off. I am sure there are lots of these types out there. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Tue, 21 Jul 2009 17:34:30 -0500 Rick Fochtman rfocht...@ync.net wrote: :---snip--- : :At the Chicago SHARE 43 meeting in August, 1974, IBM had invited :attendees to a demonstration of the new MVS operating system on the 145 :at the Chicago Ed center. At 8 p.m. Tuesday, three attendees found the :IBM demonstrator on duty was enthralling an attractive lady with his :expertise. Not wanting to be interrupted by three males, he said, Go :play with the system on that user TSO terminal over there -- you can :find out how good the security of an MVS system is for a typical TSO :user. The challenge was accepted, and in short order, Tim W. observed :that SYS1.NUCLEUS was not protected, so he scratched it. Tim W. knew :that once the system is up, the dataset SYS1.NUCLEUS is not read again, :so the SHARE demonstration continued without a flaw. It was later heard :that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a :customer benchmark; it took until 3 a.m. for IBM to find a CE who could :correctly decipher the wait state code and explain that the IPLs kept :failing because there was no SYS1.NUCLEUS on the IPL volume. :unsnip-- :That was before RACF, AFAIK, but I can't help wondering who got kicked :in the a** over that one. :-) Before RACF there were expiration dates. :Damn fine argument for having a second IPL-able SYSRES in thos days. Only if it was offline. -- Binyamin Dissen bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Binyamin Dissen wrote: Before RACF there were expiration dates. Expiration dates are too easy to bypass. Better protection was afforded by password protection, and even better (thanks to S. Metz) setting the password bits in the DSCB1 without having a password entry in the PASSWORD data set. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
Rick Fochtman wrote: Of course, you ALWAYS have recourse to litigation for damages, if you can show how the vendor should be held liable, either for malice or negligence. Shane may or may not has the same recourse as your country, because Shane is living in Australia. Litigation is one thing, but getting compensated is another thing. Oh, btw, I'm not a lawyer and does not play one on tv or youtube... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil gerh...@valley.net wrote: :Binyamin Dissen wrote: : Before RACF there were expiration dates. :Expiration dates are too easy to bypass. Required access to the console. : Better protection was :afforded by password protection, and even better (thanks to S. :Metz) setting the password bits in the DSCB1 without having a :password entry in the PASSWORD data set. That was for protection. I remember that we used expiration dates on all system datasets. -- Binyamin Dissen bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Binyamin Dissen wrote: :Expiration dates are too easy to bypass. Required access to the console. Unless you used SCRATCH with the PURGE option; e.g., I get the extents and map the free space on a volume, scratch the data set, and allocate one of mine with the appropriate space amount(s), and I have all the data unprotected. That was for protection. I remember that we used expiration dates on all system datasets. See above. Password protected data sets with no PASSWORD data set entries were much safer, especially if xMASPZAP was renamed or front-ended. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On Tue, Jul 21, 2009 at 1:28 PM, Hal Merritthmerr...@jackhenry.com wrote: Well, does a hurricane count? Generally, the category of a hurricane just about matches the F number for a tornado (a category three hurricane is about the same wind speed and destructive force as a F-3 tornado). In addition, tornados often accompany hurricanes, but there is so much going on that they are hard to spot and it is hard to attribute specific damage to a tornado. Gotta be a joke about If it's an F3 tornado, just hit F3... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Wed, 22 Jul 2009 08:54:43 -0400 Gerhard Postpischil gerh...@valley.net wrote: :Binyamin Dissen wrote: : :Expiration dates are too easy to bypass. : Required access to the console. :Unless you used SCRATCH with the PURGE option; e.g., I get the :extents and map the free space on a volume, scratch the data :set, and allocate one of mine with the appropriate space :amount(s), and I have all the data unprotected. Wasn't done to protect the data - to prevent unplanned changes - such as even a SP accidentally doing a save. Did scratch purge bypass the prompt? : That was for protection. I remember that we used expiration dates on all : system datasets. :See above. Password protected data sets with no PASSWORD data :set entries were much safer, especially if xMASPZAP was renamed :or front-ended. Different needs for protection. -- Binyamin Dissen bdis...@dissensoftware.com 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Binyamin Dissen wrote: Did scratch purge bypass the prompt? Yes, that was the justification for the parameter. So the expiration date gives you no protection against unauthorized READ access, and doesn't prevent deliberate destruction of the data. In the context of the thread's hacking, the password mechanism provided more, albeit not complete, security. Most installations found ways to restrict access to sensitive program (xMASPSZAP) and function (PROTECT ADD, that would have allowed someone to add a password for a data set not having one). Also many operators acquired the bad habit of replying U to everything, and only checking what it was for if it didn't work. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Also many operators acquired the bad habit of replying U to everything, and only checking what it was for if it didn't work. Unfortunately, auto-ops has that same opportunity. I was trying, once, to modify RMF parms, a few years ago. The auto-ops replied U too quickly, and I couldn't get my changes is, with an approved change request. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Wed, 22 Jul 2009 21:12:40 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Also many operators acquired the bad habit of replying U to everything, and only checking what it was for if it didn't work. Unfortunately, auto-ops has that same opportunity. ... There is no incorrect manual action that cannot be done a lot faster through automation. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
I guess we've all seen some dumb arse automate WAIT and NOHOLD replies so that console and jobs waiting for drives sit there spinning MIPS as fast as the automation product can reply to the messages. All the Auto-Ops people cared was the operators did not have to reply to the messages any more, and why aren't we doing something productive like finding out why the overnight batch run has slowed down... There is no incorrect manual action that cannot be done a lot faster through automation. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
There is an article on the 2600 archives (and replicated elsewhere) on how to break into VM/370 systems but really requires you to know the maint password. I have (bows head in shame) 'hacked' into a system. This was open to the internet and was running an ADCD system and they had not changed the default passwords, including ibmuser. All I did was take a look around and then log out but, for me, that was a very large hole in their security (was not a commercial company but still) Seb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
At 7/20/2009 04:49 PM, Patrick O'Keefe wrote: I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. Basically, yes. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) My issue is mainframe security and what seems to me to be a rather complacent and unfounded attitude that MVS security is bulletproof. It is not bulletproof for the reasons that I discussed in my prior post. To divide the issue by the distinction of insider vs. outsider obscures the threat. First of all, WRT an inside threat, I grant that a person posing such a threat would first have to get past many (well, hopefully many) other security barriers before being able to exploit the authorized libraries vulnerability. But I don't think that therefore one should be unconcerned about the vulnerability. WRT an outside threat, I am willing to accept (and I acknowledged this in my prior post) that the z/OS's defense against non-APF authorized threats is bulletproof. But then to just leave the issue there is, I think, complacent. The presumption seems to be that no outsider would have the ability to put a program into APF authorized libraries. Well, what about 3rd party vendors? We certainly provide the motivation to induce insiders to place our programs into authorized libraries. But what are we? Insiders? Outsiders? (As mentioned in my prior post, one technical way to partially address this exposure would be for IBM to reduce the number of reasons requiring a program to run authorized.) That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. I dunno. Wouldn't Trojan Horse fall into the category of hacking? I think hacking around or through MVS security is very rare. I certainly hope so... But by no means would I consider myself qualified to make that assertion. FWIW, this sort of vulnerability is by no means limited to mainframes. The PC world is plagued by this problem. In other words, the model is out there. If Western Civilization Runs on the Mainframe, then it's only a matter of time before someone will find that it's worth the effort to write a gotta have Trojan Horse. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 7/20/2009 04:49 PM, Patrick O'Keefe wrote: Maybe the result was silence that time but the general topic has been discussed a number of time in a number of venues. I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) Writing a back door is an inside job. It could be an interesting hack, but I don't think that's what the OP meant. MVS security (when used) does a good job of keeping outsiders out, but no system on any operating system is safe from those that are given the authority to bypass the security. Pat O'Keefe I think hacking around or through MVS security is very rare. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Tue, 21 Jul 2009 07:14:13 -0400, David Cole wrote: The presumption seems to be that no outsider would have the ability to put a program into APF authorized libraries. Well, what about 3rd party vendors? We certainly provide the motivation to induce insiders to place our programs into authorized libraries. But what are we? Insiders? Outsiders? (As mentioned in my prior post, one technical way to partially address this exposure would be for IBM to reduce the number of reasons requiring a program to run authorized.) What are the principal offenders? From an applications viewpoint, I see (the facilities provided by) IEBCOPY, IDCAMS, TRANSMIT/RECEIVE. (Others?) I find it bizarre that in a non-APF authorized state I can't manipulate data or rename data sets for which I have all otherwise necessary RACF authority. What relief would be possible? o Could IEBCOPY be enhanced to operate without APF authorization? What performance degradation would this involve? o BPX1EXM appeared tantalizing when it first appeared. But it suffers the defect of not supporting useful DDNAME allocation. Would an APF-authorized wrapper invoked via BPX1EXM, allocating data sets specified by the TSOALLOC environment variable as used by the US^H^H OMVS command, then calling a target authorized utility be secure and useful? o The new-fangled (z/OS 1.4) Unix Rexx address TSO subcommand environment is a great help in some cases: it runs the TMP in a separate, presumably secure, address space. Alas, it's available only when Rexx is spawned from a shell. Would it be possible to access this environment with a suitable API call to the Rexx interpreter? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Tue, 21 Jul 2009 07:14:13 -0400, David Cole dbc...@colesoft.com wrote: (As mentioned in my prior post, one technical way to partially address this exposure would be for IBM to reduce the number of reasons requiring a program to run authorized.) And if there we had a simple way of doing that, we would. Unfortunately, our analysis to date shows that (a) no simple method of accomplishing it exists, especially one that covers enough functions to allow vendors to eliminate their need for full APF in most of the vendor code; and (b) that the complex methods are complex both for z/OS to implement, and for the IBM and vendor products to exploit; and (c) that the complex methods are also very complex for the customer to administer. The functions that require APF do so because, simply, they allow someone to take over the system. Directly, for some of the functions, and indirectly for many others if you're clever enough. Re-architecting the system functions to eliminate the possibility of taking over the system, or allowing granular control in a way that does not involve massive rewriting of both the system and the vendor applications, and that does not involve massive administrative efforts for our customers, would be a big job. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Bulletproof (was Re: Mainframe hacking (getting back on topic))
David Cole wrote: My issue is mainframe security and what seems to me to be a rather complacent and unfounded attitude that MVS security is bulletproof. It is not bulletproof for the reasons that I discussed in my prior post. snip We prefer the phrase bullet resistant. ;-) (Sorry, I couldn't resist.) Several years ago, I visited a state-run data center in the USA's tornado belt. They had searched high and low for a building design that was tornado proof but nobody would certify that. They had to settle for a building that was missile proof. The missile in this case was a utility pole hitting end-on at 200mph. I have no idea whether a tornado ever hit that building, but I do know there are few other buildings I would rather be inside. (Well, Cheyenne Mountain would probably be OK, if you call that a building. ;-) What we said in the z/OS R9 GA announcement was: Specifically, z/OS System Integrity is defined as the inability of any program not authorized by a mechanism under the installation's control to circumvent or disable store or fetch protection, access a resource protected by the z/OS Security Server (RACF®), or obtain control in an authorized state; that is, in supervisor state, with a protection key less than 8, or Authorized Program Facility (APF) authorized. In the event that an IBM System Integrity problem is reported, IBM will always take action to resolve it. Tornado proof? Probably not. Good enough? Up to you, but who else offers more than that? (I do know of some other vendors whose code runs on z/OS who have made similar statements.) To me, it seems that this statement does not address authorized code or authorized users for the same reason the manufacturers' warranties on new cars do not include the consequences of driver error or abuse. But, what do I know? I'm not exactly a security expert. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On Tue, 2009-07-21 at 09:55 -0400, John Eells wrote: Specifically, z/OS System Integrity is defined as the inability of any program not authorized by a mechanism under the installation's control ... This is the bit I have trouble with. Just about every product demands an auth'd library for install. Given that the product has been purchased and is presumably required, how's that under the installation's control ?. As Dave says, this blows the whole idea of security to hell (sorry Dave, my emphasis ... ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
sebast...@welton.de (Sebastian Welton) writes: There is an article on the 2600 archives (and replicated elsewhere) on how to break into VM/370 systems but really requires you to know the maint password. I have (bows head in shame) 'hacked' into a system. This was open to the internet and was running an ADCD system and they had not changed the default passwords, including ibmuser. All I did was take a look around and then log out but, for me, that was a very large hole in their security (was not a commercial company but still) recent post mentioning once taking the bait and demonstrating an exploit/penetration ... they had supposedly added huge amount of security features to an internal system to protect highly classified corporate documents ... and then claimed even if i was in the machine room, i would be able to get access http://www.garlic.com/~lynn/2009k.html#5 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
At the Chicago SHARE 43 meeting in August, 1974, IBM had invited attendees to a demonstration of the new MVS operating system on the 145 at the Chicago Ed center. At 8 p.m. Tuesday, three attendees found the IBM demonstrator on duty was enthralling an attractive lady with his expertise. Not wanting to be interrupted by three males, he said, Go play with the system on that user TSO terminal over there -- you can find out how good the security of an MVS system is for a typical TSO user. The challenge was accepted, and in short order, Tim W. observed that SYS1.NUCLEUS was not protected, so he scratched it. Tim W. knew that once the system is up, the dataset SYS1.NUCLEUS is not read again, so the SHARE demonstration continued without a flaw. It was later heard that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a customer benchmark; it took until 3 a.m. for IBM to find a CE who could correctly decipher the wait state code and explain that the IPLs kept failing because there was no SYS1.NUCLEUS on the IPL volume. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On Tue, Jul 21, 2009 at 9:07 AM, Shane ibm-m...@tpg.com.au wrote: On Tue, 2009-07-21 at 09:55 -0400, John Eells wrote: Specifically, z/OS System Integrity is defined as the inability of any program not authorized by a mechanism under the installation's control ... This is the bit I have trouble with. Just about every product demands an auth'd library for install. Given that the product has been purchased and is presumably required, how's that under the installation's control ?. As Dave says, this blows the whole idea of security to hell (sorry Dave, my emphasis ... ;-) It is under the installation's control because the installation chooses what resources to secure and how to secure them. Security and integrity depends on the whole chain of control. Break one link and you lose control altogether which is why some of us bang on endlessly about software integrity. What's amazing to me is that as near as I have been able to tell, barely anyone (neither vendors, nor customers) actually gives a damn about the software integrity part - which is by far the most important part - assuming of course that the installation doesn't allow the unwashed masses to update system datasets or APF libraries. All of the hand wringing that goes on over vendor use of authorized libraries is just so much uninformed hot air, PROVIDED that the installation maintains the security of those libraries. A product having an authorized library is literally no big deal and with z/OS design as it stands today there just isn't any other way to get most things done. It has been this way since the flood and it is highly unlikely it will ever change. There is of course a presumption that the product itself does not violate integrity which is unfortunately rarely a valid assumption. But again, nobody actually seems to give a damn, so we continue to live in glass houses. Kinda funny really. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
I'm just curious. Has anyone worked for a company whose datacenter was struck by a tornado? Was the datacenter damaged or destroyed? Especially, what if the building was a really tall building? I don't recall ever hearing that. I know in Milwaukee, we occasionally have tornados. Back in the 60's, my wife's family farm near Platteville had a lot of damage due to a tornado. Her dad just watched from the living room. Luckily, it didn't hit the house but only a barn and silo. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: John Eells ee...@us.ibm.com Several years ago, I visited a state-run data center in the USA's tornado belt. They had searched high and low for a building design that was tornado proof but nobody would certify that. They had to settle for a building that was missile proof. The missile in this case was a utility pole hitting end-on at 200mph. I have no idea whether a tornado ever hit that building, but I do know there are few other buildings I would rather be inside. (Well, Cheyenne Mountain would probably be OK, if you call that a building. ;-) John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
Eric Bielefeld wrote: I'm just curious. Has anyone worked for a company whose datacenter was struck by a tornado? Was the datacenter damaged or destroyed? Especially, what if the building was a really tall building? I don't recall ever hearing that. I know in Milwaukee, we occasionally have tornados. Back in the 60's, my wife's family farm near Platteville had a lot of damage due to a tornado. Her dad just watched from the living room. Luckily, it didn't hit the house but only a barn and silo. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: John Eells ee...@us.ibm.com Several years ago, I visited a state-run data center in the USA's tornado belt. They had searched high and low for a building design that was tornado proof but nobody would certify that. They had to settle for a building that was missile proof. The missile in this case was a utility pole hitting end-on at 200mph. I have no idea whether a tornado ever hit that building, but I do know there are few other buildings I would rather be inside. (Well, Cheyenne Mountain would probably be OK, if you call that a building. ;-) John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html When I worked in NYC my office was right next to the NY Federal Reserve building. One time when they were doing repairs on the outside wall I saw that it was about 3-5 feet thick, solid stone. -- Mark Jacobs Time Customer Service Tampa, FL You can have any kind of a home you want. You can even get stucco. Oh, how you can get stucco. Groucho Marx - The Cocoanuts (1929) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
Well, does a hurricane count? Generally, the category of a hurricane just about matches the F number for a tornado (a category three hurricane is about the same wind speed and destructive force as a F-3 tornado). In addition, tornados often accompany hurricanes, but there is so much going on that they are hard to spot and it is hard to attribute specific damage to a tornado. The datacenter was on the top floor of a 7 story building. The roof failed and the top floor was flooded. All of the equipment was powered off and wrapped in plastic about an hour before the roof failed. Had the equipment not been wrapped, we would have surely been classified as 'destroyed'. We were down for a couple of weeks as we mucked out the under floor and dried everything out. This was Hurricane Alicia in 1983 (long before DR was popular). We had plastic handy simply because the roof had a history of leakage. Hurricane Ike last year did very little structural damage but the power was out for weeks. That challenge was getting deliveries of fuel for the generator. The suppliers had no power to pump fuel or were under water, the drivers that did not evacuate had no fuel to drive to work, etc etc. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Tuesday, July 21, 2009 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on topic)) I'm just curious. Has anyone worked for a company whose datacenter was struck by a tornado? Was the datacenter damaged or destroyed? Especially, what if the building was a really tall building? I don't recall ever hearing that. I know in Milwaukee, we occasionally have tornados. Back in the 60's, my wife's family farm near Platteville had a lot of damage due to a tornado. Her dad just watched from the living room. Luckily, it didn't hit the house but only a barn and silo. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: John Eells ee...@us.ibm.com Several years ago, I visited a state-run data center in the USA's tornado belt. They had searched high and low for a building design that was tornado proof but nobody would certify that. They had to settle for a building that was missile proof. The missile in this case was a utility pole hitting end-on at 200mph. I have no idea whether a tornado ever hit that building, but I do know there are few other buildings I would rather be inside. (Well, Cheyenne Mountain would probably be OK, if you call that a building. ;-) John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On 21 Jul 2009 10:30:14 -0700, hmerr...@jackhenry.com (Hal Merritt) wrote: Well, does a hurricane count? Really, the solution isn't to hurricane-proof, tornado-proof, flood-proof, fire-proof, bomb-proof, airplane-proof a data center. That money would be better spent in creating a backup data center at such a distance that the same problem won't bring it down. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
Unfortunately, the way some tax laws are written, hardening the facility could be a write-off while a second data center can be a tax burden. -Original Message- From: Howard Brazee [mailto:howard.bra...@cusys.edu] Sent: Tuesday, July 21, 2009 11:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on topic)) On 21 Jul 2009 10:30:14 -0700, hmerr...@jackhenry.com (Hal Merritt) wrote: Well, does a hurricane count? Really, the solution isn't to hurricane-proof, tornado-proof, flood-proof, fire-proof, bomb-proof, airplane-proof a data center. That money would be better spent in creating a backup data center at such a distance that the same problem won't bring it down. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On 7/21/2009 at 2:24 PM, Schwarz, Barry A barry.a.schw...@boeing.com wrote: Unfortunately, the way some tax laws are written, hardening the facility could be a write-off while a second data center can be a tax burden. Not to mention that certain types of companies are subject to government regulation that requires such types of hardening _and_ second data centers. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
WRT an outside threat, I am willing to accept (and I acknowledged this in my prior post) that the z/OS's defense against non-APF authorized threats is bulletproof. But then to just leave the issue there is, I think, complacent. We had an interesting intrigue about a dozen years ago. I don't know the details, but rumor has it that 1) The agency upset a powerful large corporation 2) The corporation went to their bought and paid for congressman for releif 3) The congressman got the OIG to start a surreptitious audit 4) The OIG obtained some userids on the mainframe and borrowed some NSA types. 5) These guys found a least 3 ways to get into supervisor state as a normal user without any apf access They did not hack into any IBM code and fortunately for us they were unable to hack into any of our in-house code. Instead they found loop holes in vendor code, particularly vendor SVCs. One method was where the SVC was called by an unauthorized program and passed the SVC a chunk of key 8 storage. The SVC would then use that storage as a temporary save area. So the program would schedule a stimer exit to pop in a very short period of time and then issue the SVC. If the timer popped at the right time, it would change the return address so that the SVC code would branch into the unauthorized program in supervisor state key zero. One exploit of this nature was only successful in about 1 out of 100 attempts, but I could run it a 1000 times a second so that didn't matter. This exploit shows why authorized routines in supervisor state and/or key zero should be careful about what data they store into key 8 storage. Greg Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
Depends on the tornado. The one that hit OKC in May, 1999 had enough power to suck pavement off the road. Generally, whatever was above ground in its path simply got blown away. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Tuesday, July 21, 2009 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on topic)) I'm just curious. Has anyone worked for a company whose datacenter was struck by a tornado? Was the datacenter damaged or destroyed? Especially, what if the building was a really tall building? I don't recall ever hearing that. I know in Milwaukee, we occasionally have tornados. Back in the 60's, my wife's family farm near Platteville had a lot of damage due to a tornado. Her dad just watched from the living room. Luckily, it didn't hit the house but only a barn and silo. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: John Eells ee...@us.ibm.com Several years ago, I visited a state-run data center in the USA's tornado belt. They had searched high and low for a building design that was tornado proof but nobody would certify that. They had to settle for a building that was missile proof. The missile in this case was a utility pole hitting end-on at 200mph. I have no idea whether a tornado ever hit that building, but I do know there are few other buildings I would rather be inside. (Well, Cheyenne Mountain would probably be OK, if you call that a building. ;-) John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
---snip--- That's the standard IBM-MAIN Archives login page, just substitute your own email address and password instead of Dave's. That's how I got to it. -unsnip- What password? I don't recall ever setting ANY password for IBM-MAIN. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
snip-- The presumption seems to be that no outsider would have the ability to put a program into APF authorized libraries. Well, what about 3rd party vendors? We certainly provide the motivation to induce insiders to place our programs into authorized libraries. But what are we? Insiders? Outsiders? (As mentioned in my prior post, one technical way to partially address this exposure would be for IBM to reduce the number of reasons requiring a program to run authorized.) unsnip I've always required that 3rd party vendors include penalty clauses in their contracts, such that it their software contributes to a security breach, then they pay penalties that are downright Draconian. Failing that, I want to review all authorized source code, as well as any mechanisms that communitcate to unauthorized code. I would be happy to execute, and abide by, a non-disclosure agreement if that was required. If the vendor won't agree to one or the other of those terms, we looked somewhere else. I only had one vendor refuse and they blew a $200,000 deal just that quickly. (I even got a look at some serious IBM code, but as far as I know, the NDA is still in effect so I can't go into details.) You want to play in my yard, you play by my rules. Period. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Try to search the archives at http://bama.ua.edu/archives/ibm-main.html without one. -Original Message- From: Rick Fochtman Sent: Tuesday, July 21, 2009 2:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking (getting back on topic) ---snip--- That's the standard IBM-MAIN Archives login page, just substitute your own email address and password instead of Dave's. That's how I got to it. -unsnip- What password? I don't recall ever setting ANY password for IBM-MAIN. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Try http://groups.google.com/group/bit.listserv.ibm-main/topics -Original Message- Schwarz, Barry A Try to search the archives at http://bama.ua.edu/archives/ibm-main.html without one. -Original Message- From: Rick Fochtman ---snip--- That's the standard IBM-MAIN Archives login page, just substitute your own email address and password instead of Dave's. That's how I got to it. -unsnip- What password? I don't recall ever setting ANY password for IBM-MAIN. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
snip--- What are the principal offenders? From an applications viewpoint, I see (the facilities provided by) IEBCOPY, IDCAMS, TRANSMIT/RECEIVE. (Others?) I find it bizarre that in a non-APF authorized state I can't manipulate data or rename data sets for which I have all otherwise necessary RACF authority. What relief would be possible? unsnip APF authorization is intended not only to protect the user from himself, but also to maintain system integrity. Invoking the wrong service at the wrong time could be a major disaster for the entire data center. Bear in mind that APF authorization also allows a programmer to bypass many of the checks that help maintain integrity, as well as RACF security (or ACF2 or Top Secret). You can't expect security to be able to distinguish a System dataset from a User dataset by keeping a table of DSNAMEs, since we have the option of renaming so many critical system datasets during installation. So between APF and RACF (et. al.), the system keeps a fairly tight rein on who does what. --snip-- o Could IEBCOPY be enhanced to operate without APF authorization? What performance degradation would this involve? -unsnip IIRC, IEBCOPY uses a couple of fairly sophisticated I/O Appendages in achieving its stellar performance. These are NOT for the average programmer. -snip-- o BPX1EXM appeared tantalizing when it first appeared. But it suffers the defect of not supporting useful DDNAME allocation. Would an APF-authorized wrapper invoked via BPX1EXM, allocating data sets specified by the TSOALLOC environment variable as used by the US^H^H OMVS command, then calling a target authorized utility be secure and useful? --unsnip-- I would question the need. snip o The new-fangled (z/OS 1.4) Unix Rexx address TSO subcommand environment is a great help in some cases: it runs the TMP in a separate, presumably secure, address space. Alas, it's available only when Rexx is spawned from a shell. Would it be possible to access this environment with a suitable API call to the Rexx interpreter? -unsnip- Here again, I would question the need. I can't make any form of detailed comments on the last two points, due to my complete lack of experience in these areas. But if a bona-fide business were presented to IBM, with enough positive response, there MIGHT be adjustments made or mechanisms developed. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
-snip- This is the bit I have trouble with. Just about every product demands an auth'd library for install. Given that the product has been purchased and is presumably required, how's that under the installation's control ?. As Dave says, this blows the whole idea of security to hell (sorry Dave, my emphasis ... ;-) -unsnip--- Shane, you're at a point where you must depend on the vendor's integrity. See my previous post in this thread. Of course, you ALWAYS have recourse to litigation for damages, if you can show how the vendor should be held liable, either for malice or negligence. We had a security audit, years ago, that showed us a hole in IDMS that could be used to bypass security. When we brought it to the attention of the vendor, we had a fix, in source form, in 3 days flat. Unfortunately, that was all before I started reviewing vendor code, and before my management realised the value of penalty clauses in contracts. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
---snip--- At the Chicago SHARE 43 meeting in August, 1974, IBM had invited attendees to a demonstration of the new MVS operating system on the 145 at the Chicago Ed center. At 8 p.m. Tuesday, three attendees found the IBM demonstrator on duty was enthralling an attractive lady with his expertise. Not wanting to be interrupted by three males, he said, Go play with the system on that user TSO terminal over there -- you can find out how good the security of an MVS system is for a typical TSO user. The challenge was accepted, and in short order, Tim W. observed that SYS1.NUCLEUS was not protected, so he scratched it. Tim W. knew that once the system is up, the dataset SYS1.NUCLEUS is not read again, so the SHARE demonstration continued without a flaw. It was later heard that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a customer benchmark; it took until 3 a.m. for IBM to find a CE who could correctly decipher the wait state code and explain that the IPLs kept failing because there was no SYS1.NUCLEUS on the IPL volume. Barry Merrill unsnip-- That was before RACF, AFAIK, but I can't help wondering who got kicked in the a** over that one. :-) Damn fine argument for having a second IPL-able SYSRES in thos days. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bulletproof (was Re: Mainframe hacking (getting back on topic))
On 21 Jul 2009 15:31:59 -0700, in bit.listserv.ibm-main (Message-ID:4a6641a0.80...@ync.net) rfocht...@ync.net (Rick Fochtman) wrote: Shane, you're at a point where you must depend on the vendor's integrity. See my previous post in this thread. We had a security audit, years ago, that showed us a hole in IDMS that could be used to bypass security. When we brought it to the attention of the vendor, we had a fix, in source form, in 3 days flat. When we found a *major* security hole in another product (it was leaking our passwords to outside organizations), their team fought us with obtuseness and then delay. I left my company less than a year after the vendor said they might, eventually, fix it, so I don't know if it has yet been fixed. CERT and well-respected security experts tell us that many vendors (not necessarily for mainframe) will *not* fix a hole until someone at least threatens to go public with it. My company would not allow me to do that. I'm heartened to see that not all 3rd-party vendors are so clueless. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole%40colesoft.com (The resulting silence was deafening.) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
David Cole wrote: Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole%40colesoft.com (The resulting silence was deafening.) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 Dave, It sounds really interesting. But the link takes me to a page where it is asking me to login and it has pre-filled in your email address. Just a heads up. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Steve, That's the standard IBM-MAIN Archives login page, just substitute your own email address and password instead of Dave's. That's how I got to it. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock Sent: Monday, July 20, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking (getting back on topic) David Cole wrote: Snipped Dave, It sounds really interesting. But the link takes me to a page where it is asking me to login and it has pre-filled in your email address. Just a heads up. Kind regards, -Steve Comstock This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Farley, Peter x23353 wrote: Steve, That's the standard IBM-MAIN Archives login page, just substitute your own email address and password instead of Dave's. That's how I got to it. HTH Peter Yeah, I got there. Turns out my password had expired so I had to request a new one. All's fine now. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
Steve, Yeah, that link goes to IBM-MAIN's archives, and you need a your email address (which IBM-MAIN already has) and a password to access that post and the thread in which it lives. I've made a copy of my post at my own website. Here's that link: http://www.dbcole.com/misc/rebackdoors.html Dave Cole At 7/20/2009 02:03 PM, Steve Comstock wrote: Dave, It sounds really interesting. But the link takes me to a page where it is asking me to login and it has pre-filled in your email address. Just a heads up. Kind regards, -Steve Comstock The Trainer's Friend, Inc. David Cole wrote: Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole%40colesoft.com (The resulting silence was deafening.) Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Partners WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
On Mon, 20 Jul 2009 14:43:32 -0400, David Cole dbc...@colesoft.com wrote: ... A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM- MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole% 40colesoft.com (The resulting silence was deafening.) ... Maybe the result was silence that time but the general topic has been discussed a number of time in a number of venues. I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) Writing a back door is an inside job. It could be an interesting hack, but I don't think that's what the OP meant. MVS security (when used) does a good job of keeping outsiders out, but no system on any operating system is safe from those that are given the authority to bypass the security. Pat O'Keefe I think hacking around or through MVS security is very rare. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
