Mainframe hacking
P S
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?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
John P. Baker
P S
John P. Baker
compromising a mainframe system "without inside assistance".
John P. Baker
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of P S
Sent: Sunday, July 19, 2009 5:47 PM
To: IBM-...@bama.ua.edu
Subject: Mainframe hacking
John P. Baker
John P. Baker
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of P S
Sent: Sunday, July 19, 2009 5:53 PM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking
You don't say? :-)
----------------------------------------------------------------------
Mary Anne Matyaz
were notoriously open, at least as far as TCPIP and a firewall. Someone got
the uss screen, was able to get into the production CICS, and the CECI
command was not protected, so they were able to shut the CICS down. The hack
came from Brazil somewhere. Bank of Brazil maybe?
Mary Anne
Gainsford, Allen
> 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?
Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know
exactly how to do it. :)
P S
Allen<allen.g...@eds.com> wrote:
> Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know
> exactly how to do it. �:)
Ouch. Besides the technical inaccuracies, that book was irritating
because for no apparent reason it misplaced University of Waterloo,
putting it near the wrong highway. "When Harlie Was One" is a better
example of the sub-genre, along with "The Moon Is A Harsh Mistress",
of course.
Howard Rifkind
Or was it OS390 R1 or something like that.
--- On Sun, 7/19/09, Mary Anne Matyaz <maryan...@GMAIL.COM> wrote:
Horne, Jim - James S
Jim Horne
Systems Programmer
Large Systems Engineering & Messaging NC4IT
Lowe's Companies, Inc.
1000 Lowe's Boulevard
Mooresville, NC
704-758-5354
Jim....@Lowes.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Howard Rifkind
Sent: Monday, July 20, 2009 8:36 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking
NOTICE:
All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone
(704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you.
Bruno Sugliani
<Jim.S...@LOWES.COM> wrote:
>I don't think MVS 4.3 did but v5 did = MVS/OpenEdition I think it was
called. I remember an IBMer friend of mine telling me that, yes, there was
Unix in that release, but it wouldn't last. Oh well...
No it is correct the first version of OE was in 4.30
But sockets came in 5.10
It was my first time in Poughkeepsie :D
Bruno Sugliani
zxnetconsult(at)free(dot)fr
http://zxnetconsult.free.fr
Ivan Warren
> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>
>
the SSCP-LU session which spews out messages coded in the USSTAB
according to what's coded in the LU macro. That makes more sense to me
as far as then being able to establish a session to a CICS instance.
--Ivan
Binyamin Dissen
:>Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
Same acronym, different meaning.
Unformatted System Service (or something like that).
:>Or was it OS390 R1 or something like that.
:>
:>--- On Sun, 7/19/09, Mary Anne Matyaz <maryan...@GMAIL.COM> wrote:
:>
:>> From: Mary Anne Matyaz <maryan...@GMAIL.COM>
:>> Subject: Re: Mainframe hacking
:>> To: IBM-...@bama.ua.edu
:>> Date: Sunday, July 19, 2009, 10:07 PM
:>> I had one once, circa 1992-1993. It
:>> was at a university, which at the time
:>> were notoriously open, at least as far as TCPIP and a
:>> firewall. Someone got
:>> the uss screen, was able to get into the production CICS,
:>> and the CECI
:>> command was not protected, so they were able to shut the
:>> CICS down. The hack
:>> came from Brazil somewhere. Bank of Brazil maybe?
:>>
:>> Mary Anne
:>>
:>> On Sun, Jul 19, 2009 at 5:47 PM, P S <zos...@gmail.com>
:>> 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?
--
Binyamin Dissen <bdi...@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.
Neal Eckhardt
>with "The Moon Is A Harsh Mistress",
>of course.
I missed that book. I assume it is an old one too?
--
Neal
Elected officials should wear uniforms like
NASCAR drivers. That way it would be easier
to identify their corporate sponsors.
Ted MacNEIL
>Or was it OS390 R1 or something like that.
I thought it came out with 5, or 5.22.
-
Too busy driving to stop for gas!
howard...@cusys.edu
<neck...@penntraffic.nospam.com> wrote:
>>with "The Moon Is A Harsh Mistress",
>>of course.
>
> I missed that book. I assume it is an old one too?
Nah, I just read it in "Worlds of If:, the other day.. decade -
1965-1956. No way I would consider that old.
Rick Fochtman
My shop was never accessed by unauthorized persons, but a DOS attack
slowed us down once. The attacker was traced and successfully prosecuted.
Tony B.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Rick Fochtman
Sent: Monday, July 20, 2009 10:47 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking
P S wrote:
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2248 - Release Date: 07/20/09
06:16:00
David Cole
>>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:
(The resulting silence was deafening.)
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Partners WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
Steve Comstock
>>> 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=ind0608&L=IBM-MAIN&P=R63457&X=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 Road VOICE: 540-456-8536
> Afton, VA 22920 FAX: 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 <==
Farley, Peter x23353
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-...@bama.ua.edu] On
> Behalf Of Steve Comstock
> Sent: Monday, July 20, 2009 2:04 PM
> To: IBM-...@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.
Steve Comstock
> 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 <==
----------------------------------------------------------------------
David Cole
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=ind0608&L=IBM-MAIN&P=R63457&X=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 Road VOICE: 540-456-8536
>Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
Patrick O'Keefe
<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=ind0608&L=IBM-
MAIN&P=R63457&X=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.
Charles T. Lester
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Howard Brazee
> Sent: Monday, July 20, 2009 11:37 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Mainframe hacking
>
Sebastian Welton
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
Mary Anne Matyaz
USSTAB.
MA
David Cole
>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 Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 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.
----------------------------------------------------------------------
Paul Gilmartin
>
>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.)
>
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
Walt Farrell
>(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
John Eells
> 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
Shane
> "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 ...
Anne & Lynn Wheeler
> 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
Anne & Lynn Wheeler
> 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
----------------------------------------------------------------------
Barry Merrill
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
Chris Craddock
> 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.
Bruce Richardson
Doesn't anyone remember the Christmas Tree viral worm?
As I recall, it was an e-mail with an attachment; the reader
was instructed to save the attachment as a EXEC, and run
it to see the Christmas greeting. While the greeting was displayed,
the EXEC harvested the address book (in PROFS, and/or NAMES file)
and resent the original e-mail to anyone it could find. In short order,
systems were crashing due to full SPOOL, and the networks
ground to a halt, shipping this note back and forth.
I believe the programmer did some hard time.
I don't remember what year it was, but is was when PROFS
was big.
Chris Mason
> Possibly also, this person wasn't talking about USS ...
Quite on the contrary, this person, Mary Anne Matyaz, to give "this person" a
name, was talking very precisely about USS, USS (Unformatted System
Services) being the VTAM function which supplies the session establishment
data mapping and information messages to be used on the ...
> ... but rather about the SSCP-LU session ...
... SSCP-LU session which you correctly identify as being the relevant SNA
architectural element.
> ... which spews out messages ...
However the messages are hardly "spewed" but sent out singly as befits the
intelligibility of the incoming command text with the exception of the initial
message 10, the one certainly referred to as the "USS screen" here, which
appears on activation.
> ... coded in the USSTAB ...
Indeed it is the USSTAB operand which supplies the name of the USS table
which contains the installation's specification for the USS function, replacing
the default USS table which does not include an USS message 10, and valid
wherever the associated SSCPFM operand specifies a value other than FSS
for "formatted system services" which require no installation-specific table.
... according to what's coded in the LU macro.
A couple more corrections are due here. Probably because it inherited a
development culture which included QTAM and TCAM, NCP was one of those
products which required to be generated from assembler macro statements -
also just like operating systems at the time and IMS, CICS and so on. VTAM
was actually a product which did not rely on assembler macro statements -
one of the first? - but, because it wanted to incorporate the NCP source as
one of the VTAMLST members (major nodes) it felt obliged, for the sake of
consistency, to ensure that all other VTAMLST members had the syntax of
assembler macros. Other than in the NCP major node, VTAM statements were
*never* macros.
Then along came the NDF program as a way of generating NCPs and now not
even the NCP statements could correctly be described as macros.
Thus, while it is possible that, prior to the early 80's, an USSTAB operand
could be specified on an "LU macro" as long as it was defined within an NCP, it
has been and is impossible since.
Also it is quite possible that the "USS screen" to which Mary Anne refers could
have been presented on a device which maps somehow to a VTAM LOCAL
statement which also can take the USSTAB operand so it doesn't have to
have been even an LU statement.
> That makes more sense to me as far as then being able to establish a
session to a CICS instance.
The interpretation Howard, Jim and Bruno arrived at is, of course, total
nonsense, caused solely because this persistent misuse of an abbreviation for
UNIX System Services. So much so that USS can even be denied its proper
interpretation!!!
Chris Mason
On Mon, 20 Jul 2009 14:59:44 +0200, Ivan Warren <iv...@VMFACILITY.FR>
wrote:
>Howard Rifkind wrote:
>> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>>
>>
>Possibly also, this person wasn't talking about USS, but rather about
>the SSCP-LU session which spews out messages coded in the USSTAB
>according to what's coded in the LU macro. That makes more sense to me
>as far as then being able to establish a session to a CICS instance.
>
>--Ivan
Hal Merritt
Not clear how this is relevant in a MVS/zos context.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Bruce Richardson
Sent: Tuesday, July 21, 2009 11:06 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking
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.
Chris Mason
> Sorry, yes, I meant the VTAM screen. I refer to it as the USS screen, from
USSTAB.
No apology is needed at all. Rather a considerable apology is due from all
those who have so misused USS as so to mislead Howard Rifkind, Jim Horne
and Bruno Sugliani. You and a great many people refer to what you meant
with perfect accuracy as an "USS screen". More specifically the 3270 device
or emulator screen presents the USS message 10 at the time the
corresponding LU is activated. Unformatted System Services (USS) - as
opposed to Formatted System Services (FSS) - has been a feature of VTAM
since before it was a program product, in other words in the mid 70's - long
before UNIX System Services - and the names by which its predecessors were
known - was a twinkle in the eyes of its begetters. Because of Howard's
misunderstanding, we have been reminded that the birth of "UNIX in MVS" was
well over a decade later in the early 90's. If this were subject to some sort of
legal process, the plagiarists would be paying hefty damages by now.
To be completely honest, I have to confess that specifically USS message 10
was *not* one of the suite of original USS messages and I cannot now
remember which release/version/flavour of VTAM introduced USS message 10.
It may have been as late as the early 80's but would still have predated the
pretender by a decade.
I am grateful to you for pointing out however inadvertently what a snare the
misuse of USS is. The widespread wanton use of USS when UNIX System
Services is meant trapped 3 contributors before 2 contributors spotted the
problem - even if one made a gross error in so doing!
I see some joker insists that USS means United States Ship. This is of course
nonsense when the context usually assumed for the IBM-MAIN list is z/OS -
and hoping that another joker will not be jumping in to insist that any zSeries
operating system is appropriate (which was the point of my "usually") - even if
some tangents can take us very far from the original subject!
Chris Mason
On Tue, 21 Jul 2009 05:23:07 -0400, Mary Anne Matyaz
<maryan...@GMAIL.COM> wrote:
>Sorry, yes, I meant the VTAM screen. I refer to it as the USS screen, from
>USSTAB.
>MA
>
>On Mon, Jul 20, 2009 at 8:36 AM, Howard Rifkind <ibm_...@yahoo.com>
wrote:
>
>> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>>
----------------------------------------------------------------------
Eric Bielefeld
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
Mark Jacobs
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)
Mary Anne Matyaz
OpenEdition, or OE, at
the time.
Funny, when I read Howards note, Unix System Services never occurred to me.
I was still thinking Unformatted Systems Services...I was puzzled.
When I see something like that, that looks completely and obviously wrong to
me, I usually try to stop and determine if there's another way of looking at
it, or explaining it, or I try to figure out what I missed. This time I
guess I didnt' do that. :)
Lets blame it on IBM and all their name changes, shall we? :)
MA
Hal Merritt
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-...@bama.ua.edu] On Behalf Of Eric Bielefeld
Sent: Tuesday, July 21, 2009 11:52 AM
To: IBM-...@bama.ua.edu
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.
----------------------------------------------------------------------
Tony Harminc
> Google results show the Christmas Tree viral worm was in 1987 and affected PROFS running on VM/370.
December 10, 1987. PROFS had nothing to do with it except to the
extent that PROFS had turned many new and non-technical people into VM
users.
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB
But really, while this was certainly malware, I'm not sure I'd call it
"hacking", even in the bad sense of the word. It relied on
unsophisticated (or in those days, simply unsuspicious) end users to
run a program; there was no advantage taken of any hole in CMS, CP or
PROFS. So maybe social engineering, like today's phishing attacks.
> Not clear how this is relevant in a MVS/zos context.
Why does it have to be related to MVS/zOS? The question was "Does
anyone here recall any published news articles or incidents involving
mainframe hacking (any flavor of VM, VSE or MVS)?"
Tony H.
howard...@cusys.edu
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.
Schwarz, Barry A
could be a write-off while a second data center can be a tax burden.
-----Original Message-----
From: Howard Brazee [mailto:howard...@CUSYS.EDU]
Sent: Tuesday, July 21, 2009 11:06 AM
To: IBM-...@bama.ua.edu
Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on
topic))
----------------------------------------------------------------------
Thompson, Steve
<SNIPPAGE>
The interpretation Howard, Jim and Bruno arrived at is, of course, total
nonsense, caused solely because this persistent misuse of an
abbreviation for
UNIX System Services. So much so that USS can even be denied its proper
interpretation!!!
Chris Mason
<SNIPPAGE>
Unix System Services vs. VTAM and USS. Pedantic. Last laugh.
Interesting picture here.
Regards,
Steve Thompson
Mark Post
wrote:
> 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
Chase, John
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-...@bama.ua.edu] On
Behalf Of Eric Bielefeld
> Sent: Tuesday, July 21, 2009 11:52 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on
topic))
>
Rick Fochtman
Do you recall the details of the DOS ?
--------------------------------<unsnip>----------------------------
Random USERID generator trying to logon to our system.
When the FBI confiscated his machine, they found 2 GB of "Kiddie porn",
so they hung him for that as well. He got 30 years.
(Certainly what I'd call "Civic Improvement")
Rick
Rick Fochtman
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.
Anne & Lynn Wheeler
> Getting back on target ....
> Doesn't anyone remember the Christmas Tree viral worm?
> As I recall, it was an e-mail with an attachment; the reader
> was instructed to save the attachment as a EXEC, and run
> it to see the Christmas greeting. While the greeting was displayed,
> the EXEC harvested the address book (in PROFS, and/or NAMES file)
> and resent the original e-mail to anyone it could find. In short order,
> systems were crashing due to full SPOOL, and the networks
> ground to a halt, shipping this note back and forth.
> I believe the programmer did some hard time.
> I don't remember what year it was, but is was when PROFS
> was big.
almost exactly a year before the morris worm on the internet
from a a.f.c post
http://www.garlic.com/~lynn/2007u.html#87
vmshare refernce:
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB
and risk digest reference
http://catless.ncl.ac.uk/Risks/5.81.html#subj1
by comparison morris worm a year later
http://en.wikipedia.org/wiki/Morris_worm
for other topic drift ... a thread in a.f.c. & ibmconnect
http://www.garlic.com/~lynn/2009j.html#79 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009j.html#80 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#0 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#6 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#9 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#12 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#13 Timeline: The evolution of online communities
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
----------------------------------------------------------------------
Rick Fochtman
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
Anne & Lynn Wheeler
> We prefer the phrase "bullet resistant." ;-) (Sorry, I couldn't resist.)
misc. past posts mentioning getting to play disk enginneer in bldg.
14 & 15
http://www.garlic.com/~lynn/subtopic.html#disk
we i 1st started playing they had all these "test cells" (engineering
devices under development) ... that they had big switch which
interconnected test cells and some number of mainframes. testing was
"stand alone" with dedicated mainframe machine time scheduled. they had
tried concurrent testing in mvs environment ... but even with a single
connected "test cell", MVS mtbf was 15 minutes (crash or hang requiring
reboot).
so for the heck of it, i undertook to rewrite i/o supervisor to make it
bullet proof and never fail or hang ... allowing significant improvement
in productivity by allowing concurrent, on-demand testing with any
number of "test cells". i happened to mention the mvs 15min mtbf number
in an internal report ... which seemed to bring down the wrath of the
mvs organization on my head.
later when we were doing ha/cmp product ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#hacmp
i was asked to write a section in the corporate continuous availability
strategy document ... unforunately, both rochester and pok complained
(that they couldn't then match the implementation) and my section
got pulled.
i had also coined the terms "disaster survivable" and "geographic
survivable" (to differentiate from disaster/recovery) when we
were out marketing ... misc. past posts
http://www.garlic.com/~lynn/submain.html#available
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
----------------------------------------------------------------------
Schwarz, Barry A
without one.
-----Original Message-----
From: Rick Fochtman
Sent: Tuesday, July 21, 2009 2:46 PM
To: IBM-...@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.
----------------------------------------------------------------------
Rick Fochtman
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
Rick Fochtman
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 Fochtman
>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
Arthur T.
(Message-ID:<4A6641A...@ync.net>) rfoc...@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
Binyamin Dissen
:>-------------------------------<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 <bdi...@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.
Gerhard Postpischil
> 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
Elardus Engelbrecht
>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
Binyamin Dissen
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 <bdi...@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.
----------------------------------------------------------------------
Gerhard Postpischil
> :>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
P S
> 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..."
Binyamin Dissen
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 <bdi...@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.
----------------------------------------------------------------------
Ted MacNEIL
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!
Patrick O'Keefe
<eama...@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
Ed Gould
From: Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>
Subject: Re: Mainframe hacking (getting back on topic)
To: IBM-...@bama.ua.edu
Date: Wednesday, July 22, 2009, 6:42 AM
On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil <ger...@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
Binyamin Dissen
:>--- On Wed, 7/22/09, Binyamin Dissen <bdi...@DISSENSOFTWARE.COM> wrote:
:>From: Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>
:>Subject: Re: Mainframe hacking (getting back on topic)
:>To: IBM-...@bama.ua.edu
:>Date: Wednesday, July 22, 2009, 6:42 AM
:>On Wed, 22 Jul 2009 02:14:48 -0400 Gerhard Postpischil <ger...@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 <bdi...@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.
----------------------------------------------------------------------