T.R | Title | User | Personal Name | Date | Lines |
---|
640.1 | yes../no... Nice it happened to them | VISA::MONAHAN | I am not a free number, I am a telephone box | Wed Dec 23 1987 12:12 | 7 |
| Yes, that sort of thing happened on Easynet a few years ago.
No, I won't tell you how it was done.
A bit of thought about the above answers will tell you why we do
not always give detailed explanations for security guidelines, or
document exactly what a security related patch changes.
|
640.2 | | ERIS::CALLAS | I've lost my faith in nihilism. | Wed Dec 23 1987 13:51 | 23 |
| Aw, come on! Geez, Louise, Paul told this story at the VAX magic
session at DECUS a couple of years ago. It's not like this is a secret.
And besides, what happened here was *very*, *VERY* different to what
happened at IBM.
What happened here was a command procedure that Paul Winalski wrote to
do some monitoring on the Enet. It had a bug in it, and it got out of
control and swamped the net. It was a pain to track down.
What happened at IBM was what is called a "letter bomb," for the
obvious reasons. Block-mode terminals are especially prone to this type
of hacking. Think of a terminal with a large answerback that is
programmable by escape sequence. You just load a command procedure into
the buffer, and send it from the terminal. The computer has no idea
that you didn't type it, and merrily executes it.
We're somewhat immune to this because MAIL filters out escape
sequences. Now, of course, you can always EXTRACT TT, but that requires
your participation, not merely reading the thing. We're even more
immune to it because we don't really do block mode terminals and we
don't have programmable answerback buffers or anything like that.
Jon
|
640.3 | Not as it may seem... | SMURF::REEVES | Jon Reeves | Wed Dec 23 1987 16:41 | 14 |
| Except -- according to some authoritative-sounding explanations
posted to comp.risks -- no MAIL was involved; instead, on an IBM
system, it's possible to ship executable command procedures around
and get them run for you. There's also a log of everyone who's
ever sent mail to you or received mail from you, which is what the
program scanned to construct its victim list.
From the posted explanations, it doesn't sound like it was written
with malicious intent; however, it got sent to/run by some naive
users. The only surprising thing is that it got through IBM's
ultra-paranoid gateway mechanism.
I strongly recommend digging out the appropriate issues of RISKS
(5.80 and 5.81 are best) if you're interested.
|
640.4 | Plug, Plug! | SNDCSL::SMITH | William P.N. (WOOKIE::) Smith | Fri Dec 25 1987 00:15 | 5 |
| The Risks digest volume 5 Notes file is at SNDBOX::RISKS_5, press
Select or KP7...
Willie Smith
Risks Moderator
|
640.5 | | VIDEO::LEICHTERJ | Jerry Leichter | Sat Dec 26 1987 16:05 | 9 |
| In summary, what you'll find (about this particular incident) in RISKS is: On
IBM systems, you can send someone a file. It appears in their directory, rather
than being added to a mail file. What happened here was that two messages
got sent: The "cover letter", which appeared as a mail message, and a REXX
exec file - essentially the equivalent of a DCL .COM file - named CHRISTMA.
(Good old IBM 8-character limit....) The "cover letter" suggested that you
execute CHRISTMA. A lot of people did, without looking at it. Boom.
-- Jerry
|
640.6 | | PSW::WINALSKI | Paul S. Winalski | Tue Jan 05 1988 17:03 | 38 |
| MAIL under VM/370 is a special case of file transfer which is done by (get
your barf bags ready, folks) "punching" the message you want to send into your
virtual machine's virtual card punch, after which the network software causes
it to appear in the recipient's virtual card reader. Queue entries in the
card reader/card punch queues are typed--one of the types is MAIL. The mail
reader program looks for queue entries of type MAIL and reconsitutes them into
disk files again.
The CHRISTMA EXEC hack involved sending a MAIL message that was an EXEC file--
the VM/CMS equivalent of a DCL command procedure--with a comment at the front
saying that if you execute the file, something interesting will happen. There
were a lot of gullible people at IBM who did that, with the documented results.
PROBE.COM, the procedure that I acidentally let loose on the ENET (it wasn't the
EasyNet yet back then) was completely automatic and didn't require that a
remote user do anything. It was a command procedure that:
1) did a SHOW NETWORK command with the output directed into a file
2) TYPEd the file back over the network link that caused PROBE.COM
to execute in the first place
3) processed the file to determine which nodes are adjacent to the
current one
4) for each adjacent node, COPYed PROBE.COM there and then executed
it as a network task, with output directed back over the network
link running the current incarnation of PROBE.
The purpose of this command procedure was to determine the current network
topology. This was in the days of Phase 2 DECnet, when you couldn't use
NCP TELL on anything except immediately physically adjacent nodes. The bug
in the procedure is that there was nothing to detect loops in the topology
and prevent PROBE from running somewhere that it had already been. In
particular, I forgot that if A is adjacent to B, B is also adjacent to A.
Infinite loops were guaranteed, and the problem compounded itself geometrically.
Yes, the same technique would work today, yes, I still have the source file for
PROBE.COM, and no, I will not post it here.
--PSW
|
640.7 | | PASTIS::MONAHAN | I am not a free number, I am a telephone box | Wed Jan 06 1988 04:52 | 10 |
| re: .1, .2
The one I was thinking of was *not* Paul's. It was let loose in
Europe while Easynet was at phase 3 DECnet. Because of the rather
unusual set up of the gateways to the U.S. I think no copies got across
the pond (fortunately), but it did paralyse the European part of the
net for a couple of days.
It sounds as if it was similar to Paul's in design, but unlike it
in that it was not even intended to serve a useful purpose.
|
640.8 | Timeout for a stupid question? | DPDMAI::BEATTIE | But, Is BLISS ignorance? | Wed Jan 06 1988 10:39 | 16 |
| Re: .6, .7
Q1: Isn't what you discribed less of a threat now because SECURPAC
turns off the ::"TASK=..." network object?
Q2: I think I heard that SECURPAC is a requisite for joining the
EasyNet (??).
I'm not naive enough to believe that any security precaution is
absolutely unbreakable, and recogise that any priv'd user could
easily go back and turn on ::"0=", but what if they don't? As an
ex-VAXcluster System manager turned PSS, whose customers are
occasionally interested in network security, I'm curious...
-- Brian
|
640.9 | | DISSRV::NORRIS | What is it, Miss Pfeffernuss? | Thu Jan 07 1988 09:07 | 14 |
| Re .8 SECURPACK does NOT turn off the TASK object. When you run
option 7 (Security Enhancement of DECNET Default Account) it will
provide you information on how to restrict access or elimate the
TASK object, but SECURPACK will not change it for you. Chapter 5
of SECPACK_DOCUMENT.MEM will provide you with more information.
DIS Policy 6.11 requires all VAX/VMS nodes on the EASYnet to have
SECURPACK installed and running.
I see nothing wrong with the TASK object as long as its access is
via proxy or an access control string.
Ed
|