Cobol - "Mainframe" virsus (was: I *Hate* When I Do This!

Author

"Mainframe" virsus (was: I *Hate* When I Do This!

William M. Klein

2005-01-15, 3:55 pm

"LX-i" <lxi0007@netscape.net> wrote in message
news:SHiFd.677$813.234@fe40.usenetserver.com...
> docdwarf@panix.com wrote:
<snip>[color=darkred]
>
> Heh - that was a reference to _Office Space_ - that's what they called it. :)
> Guess it was a bit oblique...
>

Depending upon how you define "virus" - you may be interested in the story
(true - not "urban myth") at:

http://www.computer.org/security/v1n5/j5cap.htm

About "Christmas in 1987" (for those not familiar with "PROFS" - you might
want to check out the Iran-Contra hearing minutes). Although "most famous" for
what happened to IBM's internal network in '87, this same "program" managed to
find its way into a variety of IBM mainframe shops for several Christmas' after
that.

--
Bill Klein
wmklein <at> ix.netcom.com

Michael Wojcik

2005-01-16, 3:55 am

In article <cs6b1h$711$1@panix5.panix.com>, docdwarf@panix.com writes:
> In article <cs67ue02qo5@news2.newsguy.com>,
> Michael Wojcik <mwojcik@newsguy.com> wrote:
>
> How very interesting... Mr Wojcik, this definition of virus (propogation
> via infection of others versus propogation by replicating self) seems
> closer to the function of the biological model, yes; is there, however, a
> source to be consulted for the 'preferred taxonomy' to which you refer?

I was relying largely on my own observations from reading various
computer security sources, such as the BUGTRAQ, VULN-DEV, and SECPROG
mailing lists; newsletters like RISKS and CRYPTO-GRAM; and books on
the subject, such as Russell & Gangemi's _Computer Security Basics_.

My definitions are close to the ones provided by Russell and Gangemi
(chapter 4 in the corrected first edition, pages 79-88), to note one
source.

Of course usage varies, and even many who are interested in security
will use the terms informally and broadly in some situations. I like
to err on the side of precision (but of course precision is only useful
if there's some agreement on what the terms mean precisely...).

>
> 'Proof' can be such a dicey thing - 'what are the criteria to be applied
> to 'that which constitutes a proof'?' can make for dreary reading - that I
> prefer the much milder 'demonstrate', as in 'to make clear by reasoning or
> evidence' (given that 'clarity' is in the mind of the beholder') or 'to
> illustrate and explain' (given that some people prefer scrambled... but
> others like their eggs plain)... but I'd be willing to say that the lack
> of documented viruses and relative lack of other malware targetting
> mainframes proves that... there hasn't been much documentation written or
> many malware findings announced.

I agree. I meant specifically that it shouldn't be taken to mean
that it's necessarily difficult to create viruses for mainframe OSes.
I believe it supports the thesis that malware authors aren't very
interested in targetting the mainframe, but I wouldn't claim it's
conclusive.

--
Michael Wojcik michael.wojcik@microfocus.com

If Mokona means for us to eat this, I, a gentle person, will become

! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_

Joe Zitzelberger

2005-01-18, 3:55 am

In article <136eu0hn0cv3flvrfftr38lb7ca9eo3li6@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:

> On 13 Jan 2005 16:34:22 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
>
> The dearth of zOS malware is also social, for three reasons:
>
> 1. Application programmers don't know enough to write malware; only
> systems programmers do. They tend to be straight arrow types and few
> in number.

Why would an administrator be more able to write programs than a
programmer? I just don't get that one.

> 2. Young hacker types aren't motivated to spend a year learning the
> ins and outs of zOS because they have little animus against the
> mainframe world. They think it's senile.

z/OS is senile -- but anyone can write a virus. Sometimes it is an
exercise in, er, mental exercise.

I remember the only one I ever wrote was back in the pre hard drive days
-- when you had hundreds or thousands of disks with the OS on them and
you rebooted for each program. I had discovered that if you cycled the
screen border colors on my my new Apple //gs every 37th cycle, the
border would change to a rainbow effect. The code to do this was simple
enough to write and install, the hardest part was picking the cycle
offset at which to change the color.

The problem was how to get that code installed on each of hundreds or
thousands of 5.25" floppies and 3.5" floppies that contained separate
ProDOS installations. The answer, some code to detect when a system
disk was inserted, install the code, then wait for another system disk,
otherwise known as a virus.

Robert Wagner

2005-01-18, 3:55 am

On Fri, 14 Jan 2005 08:46:56 -0500, Joe Zitzelberger
<joe_zitzelberger@nospam.com> wrote:

>In article <136eu0hn0cv3flvrfftr38lb7ca9eo3li6@4ax.com>,
> Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>Why would an administrator be more able to write programs than a
>programmer? I just don't get that one.

In the old days, systems programmers wrote enhancments to the
operating system, file systems, security and other system-level
software. They were low-level internals gurus, working primarily in
assembly language, with a smattering of PL/I.

>
>z/OS is senile -- but anyone can write a virus. Sometimes it is an
>exercise in, er, mental exercise.
>
>I remember the only one I ever wrote was back in the pre hard drive days
>-- when you had hundreds or thousands of disks with the OS on them and
>you rebooted for each program. I had discovered that if you cycled the
>screen border colors on my my new Apple //gs every 37th cycle, the
>border would change to a rainbow effect. The code to do this was simple
>enough to write and install, the hardest part was picking the cycle
>offset at which to change the color.
>
>The problem was how to get that code installed on each of hundreds or
>thousands of 5.25" floppies and 3.5" floppies that contained separate
>ProDOS installations. The answer, some code to detect when a system
>disk was inserted, install the code, then wait for another system disk,
>otherwise known as a virus.

I did something similar in my commercial screen driver that let you
run CGA programs on a machine equipped with Hercules monochrome. After
developing it for MS-DOS, I learned Sierra Online games didn't run
under DOS, they had their own operating system. You rebooted for each
game (floppy) change.

I didn't modify the operating system on the floppies. My program
resided in the top 8K of memory. It modified the BIOS' memory size to
show 8K less than actual. When the machine booted, my program wasn't
touched by POST, BIOS initialization nor OS initialization. It
survived and kept running across general reset and boot. That's a
PERSISTENT Trojan.

Richard

2005-01-19, 3:55 am

> Depending upon how you define "virus" - you may be interested in the
story
> (true - not "urban myth") at:

The point about that is that they learned from that incident, and Unix
and cisco learned from the Internet Worm. Microsoft still hasn't
learned from viruses and spyware and, in fact, has no interest in doing
so.

MS has an interest in keeping Spam and Viruses going because it makes
money selling upgrades and forcing people to the latest version (you
run 2000?, sorry you need to buy XP). Soon they will announce 'Windows
XP 2005' (but delivery in 2007) that 'solves' the IE problems and the
'Outlook' problems but only connects to Windows 2003 Server IIS and
only allows other Windows XP users to send you EMails - "because no one
else can be trusted".

MS will soon be selling (or possibly giving away) its 'Malicious
Software Removal Program', that will Maliciously remove software that
MS doesn't like (OpenOffice, StarOffice, Apache, MySQL, Nortons, Lotus,
etc).

Richard

2005-01-19, 3:55 am

> almost exclusively target Windows ... but that appears to be a
social, not a
technical, phenomenon.

Certainly targetting Windows will get a much higher 'hit rate'. Apart
from the density of such machines they are also much more alike. One
Win98 machine is just like another, give or take a service pack. With
Linux (eg) there are dozens of distributions, each with several
versions, installed with different selections, and then they may have
been recompiled with different options.

However, most of the viruses, trojans, phishing attacks and such are
using _features_ in Windows, or combinations of features that could be
exploited because they were poorly implemented.

For example Windows usually hides the 'file type'. I have no idea why
they do this, probably because they thought users too stupid and would
be

by such things. This means that something.jpg.exe is shown
as if it were an image file. Outlook would open such a file
automatically (this used to be the default) even when just selecting
the email item, opening a .exe or a macro will execute it.

Windows started as a layer on DOS and, while it is no longer on DOS
(last was ME), has been successively added to layer by layer to create
'a rich user experience' or 'convenience' or 'pretty'. These have been
assembled in such a way that it requires new layers of code to try to
add security on top of the insecure underlying design.

Because Windows started on DOS and maintained backwards compatabilty
with previous versions it was not possible to revise the underlying
system, it would break too many programs, and the attraction of Windows
was that it had 'all the apps'. They tried to kill off DOS and Windows
16bit programs with Win98, but beta testers rejected it and so they
spent 6 months putting those back in before release.

Consequently Windows is exploitable _by_design_. The result of XP SP2
is that many programs are broken (eg Fujitsu 7 which requires UP2).

The only real solution for Windows is a complete reworking putting the
security issues as the underlying levels of the system instead of as
layers on top. This would break most existing programs, as Longhorn
promises to do (in 2008 or so).

Michael Wojcik

2005-01-19, 3:55 am

In article <cs4mqo$dcs$1@panix5.panix.com>, docdwarf@panix.com writes:
>
> From the above:
>
> --begin quoted text:
>
> A computer worm disguised as a benign holiday greeting ...
>
> --end quoted text
>
> This can be read as distinguishing between a 'virus' and a 'worm'... but
> consider (again from above):
>
> --begin quoted text:
>
> It was, therefore, quite natural and unsurprising that when, on the
> morning of Wednesday, 9 December 1987, many Bitnet users at several
> different universities received a file called Christma Exec from another
> familiar user, their unsuspicious reaction was to read it and execute it.
>
> --end quoted text
>
> The user had to 'read it and execute it'... and according to
> http://www.download.clubromania.ro/...ic/v.html#virus
> this is a criterion.
>
> --begin quoted text:
>
> Unlike a worm, a virus cannot infect other computers without assistance.
> It is propagated by vectors such as humans trading programs with their
> friends (see SEX).
>
> --end quoted text

In the taxonomy which seems to be preferred by a majority of today's
malware researchers, yes, the 1987 Christmas Card (CHRISTMA.EXEC) was
not a worm, because it required manual user execution. However, it
wasn't a virus either. Viruses are parasitical code fragments which,
when executed as part of an infected program, infect other programs.

The Christmas Card wasn't "infected". It did precisely what it was
written to do; the entire program was (perhaps unintentional)
malware.

In the current terminology, it was a trojan - a program which, when
executed by the user, had malicious consequences unintended by that
user.

(Of course, under this definition, a great many applications are
trojans. I could argue for including MS Word, for example, for its
spelling checker alone.)

In other words:

worm: malware which penetrates a system by exploiting a vulnerability
in some automated and externally-accessible system component, without
requiring user interaction. The Morris Worm and various IIS exploits
like Slammer are worms.

virus: malware which alters existing programs such that when those
programs are run, they execute the malware and infect other programs
(and often do other damage). Requires user interaction, at least for
the initial infection.

trojan: malware which is executed by the victim user, often through
social engineering.

As for IBM mainframe malware, I note that SecurityFocus shows some
exploits against J2EE servers that run on zOS. (The specific ones I
found were worms.) Whether those count as mainframe malware is a
matter of opinion, I suppose, but at least one of them does allow a
variety of attacks within the Java process itself.

The RISKS digest includes descriptions of MVS vulnerabilities dating
back to at least 1987.

I must note that the lack of documented viruses, and relative lack of
other malware, targetting mainframes doesn't prove much. Viruses
found "in the wild" almost exclusively target Windows or (in much
smaller numbers) MacOS, but that appears to be a social, not a
technical, phenomenon. Tom Duff demonstrated a working and
successful Unix virus back in 1989, so Unix viruses are certainly
possible, but they're very rare in practice - apparently because the
people attacking Unix would rather write worms (or, rather less
often, use other attack vectors such as putting trojans in source or
binary distributions of free software).

Similarly, it's entirely plausible that we don't have mainframe
viruses because no one's been inspired to write one yet. (With
Hercules available, resource access probably isn't much of a barrier,
at least for prototyping; and references are available on the web.)

--
Michael Wojcik michael.wojcik@microfocus.com

The surface of the word "profession" is hard and rough, the inside mixed with
poison. It's this that prevents me crossing over. And what is there on the
other side? Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)

Howard Brazee

2005-01-19, 3:55 am

On 13-Jan-2005, docdwarf@panix.com wrote:

> How very interesting... Mr Wojcik, this definition of virus (propogation
> via infection of others versus propogation by replicating self) seems
> closer to the function of the biological model, yes; is there, however, a
> source to be consulted for the 'preferred taxonomy' to which you refer?
> It is pleasant to have a use pointed out but... a source is a source, of
> course.

Google got me a bunch of pages like:
http://www.microsoft.com/athome/sec...s/virus101.mspx

Joe Zitzelberger

2005-01-19, 3:55 am

It seems that all of the elements of a decent virus for MVS are included
with the operating system.

Consider the simple "head patch" approach, where a CSECT is linked in
and marked as the main, or default CSECT to execute. That can be done
using the linker/binder with a few simple commands. If the virus is
smart enough, it can look at the original default CSECT and save that at
a well known offset in its infecting CSECT.

Our original module might look like this:

Name XMPL0001
RSECT DFHEI1 main
CSECT SOMECODE
CSECT SOMEMORE
CSECT EVENMORE

The virus would need to inspect this module to determine that DFHEI1
was the default CSECT -- then it would have to insert a call to that
section in its own malsect. Then it simply invokes the linker to
include itself.

The infected section looks like:

Name XMPL0001
RSECT DFHEI1
CSECT SOMECODE
CSECT SOMEMORE
CSECT EVENMORE
CSECT malware main

Nothing that a few hours with the IDENTIFY macro and the manual for the
linker (SMS utilities I think) can't accomplish.

So the question becomes how do you get access to the load modules. I
think the easiest approach would be to just look at the current STEPLIB.
It seems a reasonable assumption that if you can read from it, you can
write to it.

Iterate through each member and apply the process above.

A little knowledge of RACF and ACF2 would go a long way toward making it
a better virus. When the virus code was executed, it could inspect the
rules for update access to loadlibs -- then select PDSs that qualify
using the ICF facility.

This would be a fun one to write, but I doubt I'll ever try...

In article <cs67ue02qo5@news2.newsguy.com>,
mwojcik@newsguy.com (Michael Wojcik) wrote:

> In the taxonomy which seems to be preferred by a majority of today's
> malware researchers, yes, the 1987 Christmas Card (CHRISTMA.EXEC) was
> not a worm, because it required manual user execution. However, it
> wasn't a virus either. Viruses are parasitical code fragments which,
> when executed as part of an infected program, infect other programs.
>
> The Christmas Card wasn't "infected". It did precisely what it was
> written to do; the entire program was (perhaps unintentional)
> malware.
>
> In the current terminology, it was a trojan - a program which, when
> executed by the user, had malicious consequences unintended by that
> user.
>
> (Of course, under this definition, a great many applications are
> trojans. I could argue for including MS Word, for example, for its
> spelling checker alone.)
>
> In other words:
>
> worm: malware which penetrates a system by exploiting a vulnerability
> in some automated and externally-accessible system component, without
> requiring user interaction. The Morris Worm and various IIS exploits
> like Slammer are worms.
>
> virus: malware which alters existing programs such that when those
> programs are run, they execute the malware and infect other programs
> (and often do other damage). Requires user interaction, at least for
> the initial infection.
>
> trojan: malware which is executed by the victim user, often through
> social engineering.
>
>
> As for IBM mainframe malware, I note that SecurityFocus shows some
> exploits against J2EE servers that run on zOS. (The specific ones I
> found were worms.) Whether those count as mainframe malware is a
> matter of opinion, I suppose, but at least one of them does allow a
> variety of attacks within the Java process itself.
>
> The RISKS digest includes descriptions of MVS vulnerabilities dating
> back to at least 1987.
>
> I must note that the lack of documented viruses, and relative lack of
> other malware, targetting mainframes doesn't prove much. Viruses
> found "in the wild" almost exclusively target Windows or (in much
> smaller numbers) MacOS, but that appears to be a social, not a
> technical, phenomenon. Tom Duff demonstrated a working and
> successful Unix virus back in 1989, so Unix viruses are certainly
> possible, but they're very rare in practice - apparently because the
> people attacking Unix would rather write worms (or, rather less
> often, use other attack vectors such as putting trojans in source or
> binary distributions of free software).
>
> Similarly, it's entirely plausible that we don't have mainframe
> viruses because no one's been inspired to write one yet. (With
> Hercules available, resource access probably isn't much of a barrier,
> at least for prototyping; and references are available on the web.)

Joe Zitzelberger

2005-01-20, 3:55 pm

docdwarf@panix.com

2005-01-20, 3:55 pm

In article <cs8vem02rue@news3.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:
>
>In article <cs6b1h$711$1@panix5.panix.com>, docdwarf@panix.com writes:
>
>I was relying largely on my own observations from reading various
>computer security sources, such as the BUGTRAQ, VULN-DEV, and SECPROG
>mailing lists; newsletters like RISKS and CRYPTO-GRAM; and books on
>the subject, such as Russell & Gangemi's _Computer Security Basics_.
>
>My definitions are close to the ones provided by Russell and Gangemi
>(chapter 4 in the corrected first edition, pages 79-88), to note one
>source.

Greatly appreciated... I can take it from there, certainly.

>
>Of course usage varies, and even many who are interested in security
>will use the terms informally and broadly in some situations. I like
>to err on the side of precision (but of course precision is only useful
>if there's some agreement on what the terms mean precisely...).

Meaning is the result of interpretation, or so Wittgenstein tells us; in
general I find it helpful to agree on definitions before one attempts to
build Logicks... something I learned from studying Euclid, e'er-so-long
ago.

(Come to think of it... I recall being exposed to this 'define first,
reason next' structure in Spinoza; it stunned me, the amount of time he
spent delineating his terms, and changed the way I listened to and form
arguments.)

>
>
>I agree.

'Then one of us must be wrong.' he mused, Wildely.

DD

Sponsored Links