The 360/390/z architecture instruction set is designed to support
writing a secure Operating System, but by no means guarantees that a
given Operating System implementation, or a specific Installation's
customized version of that Operating System, will be secure. In order
to allow useful utilities and installation enhancements to be
implemented under MVS, there must be controlled ways provided in which
non-IBM code can gain access to supervisor state or key 0. If an
installation failed to implement basic recommended MVS security
practices, it is conceivable that some MVS user having the ability to
submit his own batch jobs or execute TSO commands might be able to
introduce code into a library where it could run with the required
authority and do damage.
It is unlikely one would find many MVS systems so badly configured, and
the odds of someone being able to exploit such a system are reduced by
the common practice of not allowing the required kind of access from
outside a corporate network - one would in general require both physical
access and access to a valid userid with the required authorities. For
large-scale traditional MVS servers (like CICS, IMS, and more recently,
web servers) that are more likely to be exposed to the outside world,
the compartmentalized nature of MVS address spaces, installation-unique
virtual address mapping, and hardware protection of sensitive memory
pages makes it virtually impossible that anyone would be able to exploit
any code bugs in these servers to introduce executable code into the
server, much less code that could compromise the system.
Hercules emulates S/360 through z/architecture environments. Running
the free MVS 3.8 Operating System under Hercules with suitable utilities
one could generate binary object decks in a format that would still be
understood by current z/OS and which could potentially be ported to a
z/OS system; but for that matter one could conceivably even write an
ordinary PC program to generate data files in the required format to
build an MVS-acceptable program binary deck, as that format is
well-documented from 40 years of use. But, in order to introduce
harmful code to a z/OS system, the system must be mis configured, you
must have access to a valid userid/password capable of exploiting the
misconfiguration, and you must have access into the system into an
environment which would allow you to execute your binary deck as an
authorized program. Not impossible, but very unlikely.
John F. Regus wrote:
It has been pretty much my belief that the 360-390 instruction set was
invincible to outside attack because 1) who has a 370 or 390 machine to
assemble object code on and 2) to do any damage to a zOS machine (I am not
sure of the VM or VSE equivalents...I've forgotten), they would have to be
in to have execute their programs in a supervisor state, key of zero. I
think programs like these have to come from the LNKLST and updating a
LNKLST lib that is not managed by RACF or ACF2, is almost criminal to begin
with
I think some might say well they could write a module on Hercules and take
advantage of a system that way. Well, if I am not mistaken, aren't all of
Hercules modules ASCII that is emulating EBCDIC op codes.
I should have went further in saying that my contention is that it is
impossible for anyone to put malicious code onto a zOS machine based on the
main reason above about having to be in key 0 or in a supervisor state, but
apparently their are some loopholes in zVM and zLinux, and I am not sure of
their equivalents to LNKLST, where the all and powerfull to do anything
that could corrupt the system would have to originate from It is also
my contention, that should someone even get access to a machine and write
some offensive code, that to externally get to LNKLST or run a batch job or
REXX proc to do real harm with ACF2 and RACF in the way, as well as monitors
that now show in real time system library updates it would be next to
impossible, and that is the center of my thesis...i.e. it is impossible to
hack a zOS machine, but now I am having to back off my assertion of just
saying S390 because of the zVM and zLinux problems cited. I thought (well
I still think that finding a zVM machine that has portability from laptop to
390 box, leaves me with questions
I would like to thank those who have been following this and did provide
some insight. To those who offered only flip and arrogant answers,
particularly the anonymous remailer, I only can say that I hope he has
hemorrhoids that both burn and itch so bad that he can't ever in his life
get a good nights sleep.
Sebastian Welton [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I remember sometime ago coming across hacking for VM/CMS which can now be
found at:
http://www.phrack.org/show.php?p=30a=4
and here:
http://www.textfiles.com/hacking/ibm370.hac
and is pretty much out of
