Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Security Software

Was This the First Denial of Service Attack? 166

Posted by timothy
from the read-the-disclaimer-about-calling-first dept.
An anonymous reader writes "Way back in 1974, Dave Dennis, then aged 13, decided to try out the -ext- TUTOR command on the PLATO system at the University of Illinois, and see if he could cause all the terminals of other users to go offline. It worked. And he never got caught. Of course, the powers that be eventually caught on and fixed the -ext- command so terminals by default didn't automatically receive -ext-'s sent from other locations."
This discussion has been archived. No new comments can be posted.

Was This the First Denial of Service Attack?

Comments Filter:
  • by TinBromide (921574) on Sunday February 14, 2010 @11:39PM (#31140318)
    Yes
    • by Anonymous Coward on Monday February 15, 2010 @01:10AM (#31140896)

      This [wordpress.com] type of denial of service was already quite common long before that.

    • Re:Shorter answer (Score:5, Interesting)

      by A nonymous Coward (7548) on Monday February 15, 2010 @02:46AM (#31141330)

      No

      I will back that up with my own story of a weaker DoS. The year was one of 1970-72, I do not know which. UC Berkeley had two CDC 6400s, A was normal, B was used for an experimental time sharing system and thus had an optional-at-extra-cost instruction, Exchange Jump, which swapped context. I had been toying with a Fortran program and gotten tired of it, so decided to finish it off in a burst of glory. It began execution in some obscure subroutine instead of MAIN, never called MAIN, and as it ground away at its nominal task, it gradually modified an innocent instruction into an Exchange Jump. But sadly, once it finally had modified it to the Exchange Jump opcode, there was no context, just a pointer to 0, and it farked the entire machine.

      Now I wasn't truly anti-social. I had in fact written on the card deck that it was only to be run on machine A, not B. Unbeknownst to me, that Exchange Jump instruction was also used by diagnostic programs, and the tech was too lazy to disable it after each visit, just left it enabled at all times, so my Fortran program crashed the machine.

      It wasn't much of a DoS, I will admit. The OS, CALIDOSCOPE (Cal Improved Design On SCOPE (Supervisory Control Of Program Execution)), could only handle 6 batch jobs at once at most, so that's the worst it could do. But I did get called in to the admin's office, who sighed and gave me that "What are we going to do with you?" look. He knew I wasn't malicious, but he had to warn me to not do it again.

      • Re:Shorter answer (Score:2, Interesting)

        by Anonymous Coward on Monday February 15, 2010 @06:05AM (#31142320)

        My own tale from 1974/5 was that my school had a time-sharing terminal and rented time from a local consulting company. Normally we used BASIC, but the maths teacher came back raving about the new language he had been taught at a weekend conference: APL. As one of the better pupils, I was given all the documentation, and went away to read up about it. A few weeks later, I had developed my symbolic differentiation program, and had carefully entered it in, and saved on paper tape. Unfortunately the program had a minor bug, so it used up *slightly* more CPU time than anyone might have expected. Apparently, the bill for the few seconds of run-time before I killed the program was over GPB 300 - a huge amount, and as it was pointed out to me, about the same as the computing budget for the entire year :( Fortunately the computer owners realised it was a mistake and didn't actually charge the school for the time - so I was off the hook, and took greater care to ensure that programs ran efficiently and bug free. A good lesson for a 13 year old.

      • by poena.dare (306891) on Monday February 15, 2010 @08:44AM (#31143002)

        No.

        100,000 BC

        "Krug, in next village, is giving away free Mammoth meat. Better hurry before it's all gone."

      • by vaporland (713337) on Tuesday February 16, 2010 @12:22PM (#31156050) Homepage
        In 1979 I was a student at Virginia Commonwealth University, using their Hewlett-Packard 3000 Series III minicomputer system. I discovered that:

        -if you wrote a program called "A" which used the BASIC CHAIN statement to invoke a program called "B",
        -and if you wrote a program called "B" which used the BASIC CHAIN statement to invoke program "A",
        -and if you ran program "A" and waited about 30 seconds for the two programs to start ping-ponging back and forth between each other,
        -and if you then used the "KILL" command to erase either "A" or "B" . . .

        . . . the entire system would crash with a "hardware failure" message on the system console. Needless to say, this was great fun at exam time. BUT - upon the fourth consecutive failure, the fourth time the entire minicomputer had been disassembled and reassembled, the HP customer engineer decided to read the memory dump instead of running hardware diagnostics, and I was severely warned by the system administrator about doing this again...
    • by YourExperiment (1081089) on Monday February 15, 2010 @05:32AM (#31142150)

      Yes

      tl;dr

  • by JorDan Clock (664877) <jordanclock@gmail.com> on Sunday February 14, 2010 @11:39PM (#31140320)
    The first recorded denial of service was performed by a 13 year old, who was basically using a "script kiddie" technique? Well, color me surprised.
  • by Anonymous Coward on Sunday February 14, 2010 @11:40PM (#31140326)

    And last post...

    -ext- :D

  • by Anonymous Coward on Sunday February 14, 2010 @11:41PM (#31140332)

    You don't have permission to access /blog/2010/02/perhaps-the-first-denial-of-service-attack.html on this server.

  • by Darkness404 (1287218) on Sunday February 14, 2010 @11:45PM (#31140368)
    So, let me get this right. You could more or less get a list of addresses, and they would accept commands without question if you just typed in the commands and the right address? Sounds like the worst security system ever.
    • by Anonymous Coward on Sunday February 14, 2010 @11:51PM (#31140402)

      So, let me get this right. You could more or less get a list of addresses, and they would accept commands without question if you just typed in the commands and the right address? Sounds like the worst security system ever.

      Yeah, but this was 1974, when overly-trusting users used commands to do USEFUL things, rather than cause mischief (or shove adverts in front of you)!

      • by girlintraining (1395911) on Sunday February 14, 2010 @11:59PM (#31140456)

        Yeah, but this was 1974, when overly-trusting users used commands to do USEFUL things, rather than cause mischief (or shove adverts in front of you)!

        If you remember 1974, you weren't there, maaan!

      • by gad_zuki! (70830) on Monday February 15, 2010 @12:09AM (#31140546)

        I dont care if its 1974 ot 1794, human nature doesnt change. Put locks on your (virtual) doors.

        • by Ethanol-fueled (1125189) * on Monday February 15, 2010 @12:35AM (#31140710) Homepage Journal
          From the summary:

          And he never got caught.

          If he did get caught he'd get a smirky, eye-rolling verbal warning instructing him to stay away from the terminal. Nowdays a kid would be taken into custody and charged with violating computer crime and terrorism laws.

          FBI and/or DHS interrogations would follow, then he'd be forced to turn snitch and lure other kids(er, "marks") into "hacking" the system, to avoid a decade or more of federal prison.

        • by PCM2 (4486) on Monday February 15, 2010 @12:59AM (#31140840) Homepage

          I dont care if its 1974 ot 1794, human nature doesnt change. Put locks on your (virtual) doors.

          Yeah, that seems like great advice now, but hindsight is always 20/20, as they say. As recently as the early 90s, most Unix systems didn't even use shadow passwords.

          Admin Guy: "Yeah, so what could happen? Some college kid is going to buy a Unix server and set it up in his dorm room so he can run a brute force attack on /etc/passwd? I'd like to see that one!" LOLZ, snort snort...

          • by mysidia (191772) on Monday February 15, 2010 @03:03AM (#31141458)

            They were crypted... why would you need to hide a strong password that was crypted? Shadow'ed passwords are an ugly hack.

            Also, if you restrict "shadow" passwords so only root can see them, then suddenly every program that needs to perform authentication must be setuid root...... this is a security risk. In that era, possibly a much larger security risk than the risk of a strong password being cracked.

            The problem wasn't failing to use shadow passwords. It was (1) UNIX users who set weak passwords, and (later), an (2) explosion in computing power, making it easier to attempt to crack the passwords.

            Also, the reverse-engineering of the original DES-based crypt binaries allowed inefficiency that was intentionally contained in the algorithm to slow it down (making use for cracking improbable), to be removed, after years of study.

            The DES-based crypt() algorithm was optimized into fast-crypt which was orders of magnitude faster, and actually made password cracking feasible. If a harder cryptographic algorithm would have been used -- then matters could be very different.

            The latter bit they should have seen coming. The explosion in computing power was by no means a certain development, it wasn't an immediate issue at the time.

          • by gad_zuki! (70830) on Monday February 15, 2010 @10:33AM (#31143754)

            >Yeah, that seems like great advice now, but hindsight is always 20/20, as they say. As recently as the early 90s, most Unix systems didn't even use shadow passwords.

            Yet in 1993, Windows NT had ACLs, security groups, NTLM, etc. Theres no excuse for ignoring basic security principles. CS departments and tech companies the world over have understood these basic controls since the 50s or 60s.

            Sadly, everyone has to reinvent the wheel. Look at how PHP has changed from "personal home page" which was a security nightmare to what it is now, which is more like a security bad dream. Starting with security first goes a long way. This isnt a 20/20 vision thing, its called getting off your ass and doing things right the first time.

      • Exactly (Score:4, Interesting)

        by NotQuiteReal (608241) on Monday February 15, 2010 @01:03AM (#31140866) Journal
        I don't think it was quite as early as 1974, but somewhere right around there, I remember going to the "math room" in Jr High, and being able to access a terminal to get to "the main frame". It was something that used fan-fold paper (not a CRT). You could write BASIC programs on it, I think. I kind of remember writing stuff as complicated as 2D grid based Star-Trek type programs (one step up from Hunt the Wumpus).

        Anyhow, we did have a command that we could type in that would crash the system, which we did once in a while, just to cause mischief. I really don't recall if we discovered it, or it was given to us (a la script kiddie), but it eventually ended up being a program called "runme" or some such...

        Anyhow, letting random people on a "public" terminal to the mainframe of the San Diego unified school district is probably a thing of the past.

        The best security breach, by far, however was an attempt to save money by re-using the fan-fold computer paper. Man, there was some juicy stuff on the flip-side of that stuff - names, addresses and IQ rating of all your class mates, payroll runs, all sorts of entertainment!

        Simpler Times. Get off my lawn!
      • by Provocateur (133110) on Monday February 15, 2010 @08:40AM (#31142978) Homepage

        Hey you're not asking me to go back in time to deny this kid's god-given right to his first ever DoS, that would be like Denying a DoS....

    • by girlintraining (1395911) on Sunday February 14, 2010 @11:55PM (#31140426)

      Sounds like the worst security system ever.

      *cough* Diebold. *cough*

    • by pookemon (909195) on Monday February 15, 2010 @12:00AM (#31140466) Homepage
      So I'm guessing you weren't around in 1974. It might also surprise you to learn that once upon a time there were no virus scanners or firewalls. I bet I just blew your mind with that one...
      • by Waffle Iron (339739) on Monday February 15, 2010 @02:35AM (#31141276)

        Another thing about PLATO in particular, is that while it was very cool and ahead of its time, there was very little important secret information stored in it.

        Most of the users used it to do mundane homework assignments. It also had some games, and facilities that resembled today's newsgroups, chat and rudimentary informational websites.

        At least in the site I used, keeping the aging Control Data Cyber mainframes that hosted PLATO creaking along was probably a much bigger worry than any security threats. There was no shortage of hardware-related downtime.

    • by betterunixthanunix (980855) on Monday February 15, 2010 @12:18AM (#31140602)
      You know, this was all way before my time, but back then, security was not a common concern on university computers. People working in a lab trusted each other; thus, those who used Unix (or a similar system) would leave their home directories world readable, and as another example, ITS had the ability to observe another user's keystrokes. Things changed in the 1980s as more students got computer access and as proprietary software became the norm.

      There are still echoes of the trust that existed back then. For example, where I am now, anyone in the CS department can remotely access any computer system located in the department, and the permissions on home directories are 755 by default. The only firewall is on the gateway between the department the general campus network, but port 22 is open for any system so you can always ssh through the firewall. We are given root upon request on our assigned desktops. There are plenty of ways that I could subvert others in the department, I could even bring the entire department to its knees by running a simple fork bomb on every system we have, but I do not do any of that because I am not here to attack people or make their lives difficult.
      • by antifoidulus (807088) on Monday February 15, 2010 @12:34AM (#31140698) Homepage Journal
        nd the permissions on home directories are 755 by default.

        thats actually common on a lot of unixes(OS X for example), and not really as bad as you think it is. Essentially it just allows any users to get a list of files on the top level of the home directory, thats it. You cannot necessarily even read any files in the root of the home directory, just list their names and sizes. The really important thing is what their default umask is set to be. Any decently good paranoid cs student will set it to 0022 asap.
        • by DavidRawling (864446) <hulk_@y a h o o .com> on Monday February 15, 2010 @01:46AM (#31141062)

          Actually, I'd expect a paranoid CS student would be setting the umask [wikipedia.org] to 0077. If you're that paranoid ... do you really want other group members (students) reading your code? (Ah, the days when the student server was Hardy and the Staff one Laurel ... 500 CS students compiling at the same time on a <60MHz SuperSPARC I was NOT FUN, and those of us who tutored used the staff server instead. Same spec, 3x as fast!)

          And since you can't get a umask right, you can hand in your geek card on the way out the door, you imposter you!

      • by LordLucless (582312) on Monday February 15, 2010 @12:50AM (#31140792)
        And the fact that you need to SSH in with your own credentials mean that if you were stupid enough to do something of the sort, they'd haul your ass over the coals.

        If you're dealing with people in positions of trust, logging is often the right balance between security and trust. It doesn't stop them from doing the things they need to, but the knowledge that their fingerprints will give them away will (generally) stop them from doing anything to violate that trust.
      • by ChrisMaple (607946) on Monday February 15, 2010 @02:50PM (#31146872)
        I used the Multics system in 1971, and permissions were in place and used. Not long after the system was first brought up, a friend of mine who was a developer but not totally aware of what everything did, found some files he had full access to that he didn't recognize. So he erased them and the system crashed. The next day, did the same thing. Turns out that he had erased the OS. The next time the system was brought up, the permissions were corrected to prevent general user write access to the OS.
    • by Sycraft-fu (314770) on Monday February 15, 2010 @02:21AM (#31141222)

      Computer security was poor back in the day. Since computers were expensive, scarce things that were generally not connected to others, it wasn't a big deal. You knew everyone who had access, if someone caused trouble they'd get in trouble. Even once the Internet, or rather ARPANET back then got started, security was extremely lax. If you look at some of the low numbered ports you'll discover they ware things like "chargen" which just sends a random string of characters out. You can see how this would be a bad idea currently, but it could be a useful tool to make sure a system and link were working.

      As with most things, people learn from experience. As computers become more common and networks larger, security got better by necessity. Things got broken in to, so the problems were fixed. Go with that for a couple decades and we now have systems with multiple privilege levels, hardware enforced memory access limits, virus scanners, firewalls, etc, etc.

      A good deal of security in the world is born out of necessity and experience. Bad things happen, so security is designed to stop them from happening.

    • by hedronist (233240) * on Monday February 15, 2010 @11:56AM (#31144794)

      Security? When I first sat down at a PLATO IV terminal in Jan 1973, you typed "s" to login as a student, and "a" to login in as an author -- no passwords. If you could guess a file name (called "lesson spaces") you could edit it. Al McNeil and I found any number of allocated-but-unused lesson spaces and just started poking and prodding the system. Al and I basically "guessed" the TUTOR language from looking at other people's code because there were no manuals available at that time (at least not in far off Chicago). But it was exactly because it was so easy to get into the system that we became hackers.

      Weirdly enough, 9 months later we (I was a Business undergrad, and Al was an Art undergrad) were teaching TUTOR to UICC profs who wanted to use it for their classes ... and one of our students was Al's father, the head of the Physics department.

    • by ShakaUVM (157947) on Monday February 15, 2010 @05:19PM (#31148730) Homepage Journal

      So, let me get this right. You could more or less get a list of addresses, and they would accept commands without question if you just typed in the commands and the right address? Sounds like the worst security system ever.

      In UNIX systems, circa 1997 and before, they'd allow anyone to write to any TTY. This was how Talk worked, for instance.

      So when I wanted to mess with my friends, I'd cat poetry or /dev/random > their TTY and watch them start cursing in the lab.

      It's how I taught my friends about ^L.

  • by Al Dimond (792444) on Sunday February 14, 2010 @11:57PM (#31140442) Journal

    I always think of DoS meaning flooding a system with requests, causing all resources to be used, thus nobody can get service.

    It seems like this guy just found a "Halt and Catch Fire" instruction and an overly trusting security policy. Which may have been a first something, but not really a DoS, right? Or am I missing something?

    • by XanC (644172) on Monday February 15, 2010 @12:02AM (#31140486)

      A DoS, generally, is anything that prevents a computer (or I suppose anything) from performing its functions. It's anything that "denies" "service".

    • by nedlohs (1335013) on Monday February 15, 2010 @12:03AM (#31140492)

      "Denial of Service". It's the damn name.

      One way is to flood the system, but there are plenty of other ways. The one mentioned for example.

    • by Fallon (33975) <Devin,Noel&Gmail,com> on Monday February 15, 2010 @12:04AM (#31140506) Homepage Journal
      What does DoS stand for? Denial of Service. Getting everybody kicked off the system certainly sounds like denying them access to that computer service to me. Just because a DoS is usually performed by a network flood of some kind doesn't mean that's the only way to do it. Heck an idiot tripping over the power cord to the server is technically a DoS if people loose access.
      • by Rennt (582550) on Monday February 15, 2010 @03:24AM (#31141562)

        Heck an idiot tripping over the power cord to the server is technically a DoS if people loose access.

        PRACTICALLY. That would practically be a DoS. Technically all you've got is a clumsy buffoon.

        Anyway, nobody ever means "denial of service" when they say DoS. It is a "denial of service attack". Which def. does not include unplugging the server.

      • by YourExperiment (1081089) on Monday February 15, 2010 @05:37AM (#31142174)

        By that definition, walking up to their terminal and hitting it repeatedly with a baseball bat would also be a denial of service attack. So would physically restraining them in their chair such that they were unable to reach the keyboard.

        This seems to me to be an overly broad definition. The term "denial of service attack" has taken on a more specific meaning than "any means of denying access to a computer system".

    • by xous (1009057) on Monday February 15, 2010 @12:05AM (#31140516) Homepage

      Hi,

      DoS stands for 'Denial of Service' so anything that can cause a system to fail to respond to legitimate requests.

    • by cvd6262 (180823) on Monday February 15, 2010 @12:16AM (#31140598)

      Back in the 19th Century (in the US anyway), mail *recipients* paid postage to get their mail from the local general store. Political figures and others who might have a negative following would receive scores of blank letters and have to pay for them. The objective was to either crowd out the legitimate communications or bankrupt the recipient. Traditionally, one could place an ad in the local paper explaining that he or she would no longer receive letters at the store, which would free them from their obligation.

    • by weicco (645927) on Monday February 15, 2010 @03:46AM (#31141686)

      Flooding is just one way/method to execute (D)DoS attack. You can read more here: http://en.wikipedia.org/wiki/Denial-of-service_attack#Methods_of_attack [wikipedia.org]

    • by tricorn (199664) <sep@shout.net> on Monday February 15, 2010 @07:30AM (#31142672) Journal

      Well, the -ext- command was used to send data to an arbitrary piece of "external" equipment attached to the terminal. A couple devices were a 4-voice music synthesizer, a Votrax voice synthesizer, and a random-access audio play-back device.

      It was useful with some of the equipment for another user's program to be able to send such external data to your equipment and vice versa. Most people didn't have anything attached, but the system didn't know that. With nothing attached, all it did was make your terminal really really slow, as the other program queued up output for you that was basically thrown away, but had to be sent anyway (the external data took up about 3 character's worth in the data stream, with about 180 characters/second being output).

      The system actually had pretty good security, and insulated each user from the other in terms of resource usage, and this wasn't strictly speaking a security breach, but this was a way to interfere with other users in an unintended way. It didn't take the entire system down, it only interfered with the terminals that were targeted.

  • One of many ways... (Score:4, Interesting)

    by mikael (484) on Monday February 15, 2010 @12:01AM (#31140474)

    It used to be possible to crash early Sun servers (or at least the terminal server attached to the server by trying to copy data from a virtual terminal (cat /dev/ttyp0) or something similar.

    One university department tried to get around the user quotas on commercial UNIX licenses by creating a single user account for an entire class. Hilarity ensued as students working on real-time projects would accidently kill each others processess.

  • by Demonoid-Penguin (1669014) on Monday February 15, 2010 @12:18AM (#31140606) Homepage
    2 minutes searching shows - October 29, 1969

    First packets sent by Charley Kline at UCLA as he tried logging into SRI. The first attempt resulted in the system crashing as the letter G of LOGIN was entered.

    I'd bet that part of the initial DARPA deployment testing involved deliberate attempts to jam the network

    Just saying....

    • by tricorn (199664) <sep@shout.net> on Monday February 15, 2010 @07:35AM (#31142702) Journal

      I really don't think Charley was trying to crash it, so it wasn't a "denial of service" attack. In fact, there was no service, so nothing was being denied! All these stories of "well, I typed this and it crashed the system" aren't DOS attacks. Deliberately doing it repeatedly, and in a way that couldn't be easily locked out (e.g. by deleting your user account and banning you from the computer room) might constitute a DOS attack, but there has to be an intent to Deny Service to one or more other people.

  • by chelberg (1712998) on Monday February 15, 2010 @12:35AM (#31140718)

    In high school in 1974 our district (8 schools) used an HP access timesharing system. It ran the BASIC language. I was able to write a very short program that would cause the system to crash. Having discovered this bug in the system, I was able to bring down the entire district's computers at will. I had discovered this capability while exploring a new feature of BASIC. Fortunately for them, I was ethical and informed my teacher who at first didn't believe the exploit until I demonstrated it in front of her. We then contacted HP, gave them the code, and they came up with a patch within a couple of months. I'm not sure if anyone at HP can confirm this at this point.

    I am sure that there are probably earlier exploits as well.

    And as a side note, I was also a PLATO author in 1975 and greatly enjoyed working on that system.

  • by DougReed (102865) on Monday February 15, 2010 @12:43AM (#31140756)

    The earliest one I know of was by the smartest man I ever knew (and the strangest). He was my mentor. In the IBM 360 days this guy used to write code .. COMPLEX code in binary on the roller bars on the front of the console because he was too lazy to logon. He made IBM's code more efficient by eliminating all modularization. It was more efficient to just have one big super efficient kernel, so he redesigned their system, and got something like 140% efficiency out of the hardware (40% greater than theoretical possibility) by IBM's own benchmarks, and found a security hole in their code in the process .. as he put it "bit enough to drive an 18 wheeler through", which he reported to them. They told him it was his hacking, he broke something ... NOT OUR CODE!!! IBM CODE CAN'T BE BROKEN!!! So he went to their 'demo center' and fed in a deck of punch cards.

    On the IBM Selectric console in the IBM demo center, it printed.

    "May I please have a cookie?"

    The operator ignored it.

    8 hours later during shift turnover It printed

    "I never got my cookie"

    The two operators looked at it, shrugged, and ignored it. The dayshift operator went home.

    4 hours later the console printed.

    "You're not a very nice operator either, I never did get my cookie"

    The operator thought the guys upstairs were fooling around and ignored it.

    2 hours later.

    "WHERE IS MY COOKIE!"

    hummm...

    1 hour later.

    "Dammit give me a cookie!"

    30 minutes.

    "I WANT A COOKIE!"

    15 minutes ... 7.5 minutes ... eventually we get to 32 cookies this second .. 64 cookies this second ... 128 cookies this second.

    An IBM Selectric typewriter which is the main console for a 360/65 cannot print even the word cookie in a second, much less a whole sentence, and certainly not 128 of them! There was ONE way to crash a 360/65 .. Fill up the console buffer. The system considered console messages to be important, and if the system couldn't print all of them, it halted.

    Reboot ... excuse me... Mainframe terminology here... "IPL" the system. First console message:

    "You know, I never DIID get my cookie!" .. and the process starts over.

    Finally IBM called my mentor...

    um... did you submit a job to the demo center?

    Yes, but don't worry, it was just a simple 'unprivileged' process, and as you said, your security is flawless, so I am sure there is no danger. :-)

    Sir, I think we are prepared to acknowledge that there MAY BE a security hole in our system somewhere. It seems that your job never finished and yet it does not seem to exist in the system anywhere. Our experts tell us we have to re-install the operating system to fix it. Do you have any alternative suggestions?

    Just one... Go get the best operator you have and put him on the console and call me back.

    Yes sir... .. an hour later

    Sir, this is king super operator, they just called me back in to work to assist you in solving our issue.

    OK ... now listen carefully. I am only going to say this once. Type carefully, and don't screw this up .. are you ready?

    Yes sir.

    Good type this ... "c" "o" "o" "k" "i" "e" ... now press "Enter"

    Console prints . "Thank you that was good", and the job ends.

    After that IBM never ever questioned it if my mentor reported a problem with IBM software ever again.

  • by dmomo (256005) on Monday February 15, 2010 @12:43AM (#31140762) Homepage

    Denial of Service is just about as old as marriage.

  • by marciot (598356) on Monday February 15, 2010 @12:52AM (#31140806)

    Back in my high school's UNIX system I used to like piping binary files to people terminals. It worked pretty well as a DoS and made a loud racket with the all the BEL characters.

    Cntl-S could also be used to halt people's sessions, and "+++" would screw with people on dial up sessions.

    The good ol' days.

  • by gavron (1300111) on Monday February 15, 2010 @01:00AM (#31140852)

    Yes, of course. 13 years old kids in 1974 got access to UI computer systems without paying for timeshare.
    Our hero, managed to take a whole room of "terminals" offline with one existing command.

    And now [queue evil music] 36 years later, having done nothing of note ever, he now seeks his hard-earned fame.

    First ever DoS... or 49 year old sociopath longing for publicity... or just a liar. You decide. I already have.

    E

  • by Space cowboy (13680) * on Monday February 15, 2010 @01:01AM (#31140858) Journal
    See This journal entry [slashdot.org] I posted a while back... These days, at least in the US, I'd probably be up on federal wiretap charges or something. Back then, it was serious enough that they'd threaten to throw me out of college, but I never got any sense of there being jail-time involved...

    Simon
  • by GrpA (691294) on Monday February 15, 2010 @01:21AM (#31140946)

    Well if that was the first DOS, then I'll claim the first "Slashdotted" on a PLATO system. In 1987 after the local admins cut off all access to chat ( due to abuse of the system by people sitting next to each other using "chat" ) I wrote a tutor script that caused a timeout error every second.

    The result was to flush the keyboard buffer to common memory. Then the other terminals read the common memory and updated their display - Kind of like early IRC. Because this was written at the lowest security level, the admins couldn't block it. They deleted the original, but all the other authors had the code by then. It wasn't very efficient code, but they managed to keep it alive despite the best attempts of the admin to get rid of it.

    After the application consumed 99% or more of all recorded resource use for three months running (making all other resource access slow) I got my ass kicked off the system and they decommissioned that installation of PLATO (CALS).

    Funny thing is I went back three years later in 1990 and managed to convince them to give me an unrestricted dial-in port for Internet access. My first! Several months later, they came to me and said "You're taking up all of our spare resources... You remind us of this guy who wrote a chat program on the old PLATO system several years back."

    I never did own up to it at the time since no one knew my surname at the time ( That's another story entirely ). Although I did buy them another terminal server to make up for it.

    GrpA

    • Law of unintended consequences - they cut off chat for something pretty minor (using chat when sitting next to each other - that's "abuse"?) and created a much bigger problem.

    • You use a lot of words, but they don't really make sense when put together. A "tutor script"? A timeout error every second that flushes the keyboard buffer to common?

      The common "chat" program was talkomatic ("talk" on Unix systems is very similar, it allowed up to 6 people to communicate at once, with any number of additional people to monitor a channel), and it really wouldn't matter if everyone on the system was in it, it was fairly efficient, so I don't know why they'd want to prevent people from using it. The only resource it would use would be a terminal. Did they also disable TERM-talk, Personal Notes, notesfiles, and all games as well? I'd have thought you'd be more interested in writing a game in order to stick it to them rather than write a hideously inelegant and inefficient version of talkomatic.

      PLATO was fairly conservative in giving out resources - if you went in "background" mode, you could use all the processing available, but got lower priority, and wouldn't interfere with anyone else running in "foreground".

      Why wouldn't they just delete the author signons of anyone who implemented code they didn't want on the system, anyway? You can't write code anonymously on a PLATO system, and if they were trying to control things so tightly that they objected to people talking to one another, surely they'd tightly control who got author signons.

      So, your story doesn't really make any sense.

  • by drfreak (303147) <dtarsky@@@gmail...com> on Monday February 15, 2010 @01:44AM (#31141048)

    Enough Said.

  • by Kenja (541830) on Monday February 15, 2010 @01:53AM (#31141112)
    Taking out telegraph lines, signal towers, killing messengers. DoS attacks have existed as long as people have tried to communicate over distances. Even man in the middle attacks, intercepting and replacing semaphore messages etc.
  • by Skapare (16644) on Monday February 15, 2010 @07:58AM (#31142820) Homepage

    My first DoS discovery was in October 1976. On IBM mainframes running VM/CMS, I found I could take down the entire system from an ASCII serial port connection, without even being logged in. At any prompt, including the "LOGON:" prompt (hence why being logged in was not needed), just press the RETURN key followed immediately by the BREAK key.

    A couple years later when I obtained the source code to the system (bought it on a reel of tape, from IBM, for $150) I found the bug in the code that caused it. The "CP" kernel went into a loop trying to send a command to the I/O controller to reverse the direction of the half-duplex serial port, which would always fail because it had not received the interrupt informing it of the BREAK status, which it would never get because all I/O interrupts were masked off at that point.

  • by Ancient_Hacker (751168) on Monday February 15, 2010 @08:40AM (#31142980)

    In 1972, I was a college student with more time on my hands than sense. Here's a few things I did to a $4 million CDC 6600 time-sharing system:

    (1) Hells bells: This machine had ten PP's (Peripheral Processors) that offloaded I/O tasks. The PP's had for-the-time screaming I/O speeds-- all of 2MBPS. User disk space consisted of two washing-machine sized disk drives, 88MB total. A little metal arithmetic suggested that you could fill the disks in no time. so a 2-line FORTRAN program: 1 WRITE(1) 76437643764376437643B; GOTO 1 ... it filled up the disks in under a minute, bringing the system to a standstill. (7643B was the display code for ^G, bell) ( The system programmers quickly implemented disk space quotas after that ).

    (2) There was a fixed-size open file table in the kernel memory area, usually configured for 400 files. There were no open file quotas. So a 2-line SNOBOL program could very quickly open up an number of empty temp files, bringing the system to a halt. ( FORTRAN programs could only work with files declared in the program header line ). ( The system programmers again very quickly implemented a limit on number of files per user ).

    (3) On early core RAM modules, the modules were interleaved 8-wise, so each module only got accessed every 8-th word fetch.. But if you knew this, and wrote a program that jumped forward 8 words several dozen times, then jumped back to the start, one module would get accessed at the maximum possible rate and within a minute the module would melt down. I did not try this ( the 4K modules must have cost $100 or so ), but I heard of someone that did.

    (4) The card punch was designed for punching text data, which had at most two out of every 12 rows punched per column. If one punched a few hundred cards of -0 (all ones on a one's complement machine), and did a DISPOSE(OUTPUT=PUNCHB), the card punch would overheat and melt down all the punch electromagnets. My boss at the time admitted to doing this.

    (5) The line printers were amazing machines, extremely speedy, BUT if you write out a few hundred lines of "-------------------", the first column was carriage control, and the default cc tape would map "-" to mean "no line feed". A few dozen lines of that and the paper would cut through, bringing that printer to a halt.
    ]
    (6) Same thing as (5), but with a "1" in column 1 would eject pages at the maximum rate, which was much faster than the paper stacker could collect the pages. There were page limits in place, but the poor operators would still be confronted by a printer covered with 100 pages of ejected paper.

    (7) At first you could make system calls with bit 20 set, which meant asyncronously. You could issue these requests much faster than the OS or PP's could finish them, so you could easily tie up all the free PP's and that would instantly bring the system to a very slow crawl. Very soon thereafter, a limit of 2 PP's per user task was implemented.

    There were more, but the statute of limitations may not be up for them.

    • by Maximum Prophet (716608) on Tuesday February 16, 2010 @01:25PM (#31156958)

      (3) On early core RAM modules, the modules were interleaved 8-wise, so each module only got accessed every 8-th word fetch.. But if you knew this, and wrote a program that jumped forward 8 words several dozen times, then jumped back to the start, one module would get accessed at the maximum possible rate and within a minute the module would melt down. I did not try this ( the 4K modules must have cost $100 or so ), but I heard of someone that did.

      Purdue's CDC 6000 series machines had a similar bug that would destroy modules. (I still have a pair) AFAIK, they cost much, much more than $100 each. They were core modules that had 48k by 1 bit and had been assembled by hand.

      The CDC was retired with a major security bug. The system "root" password was stored in a protected place in memory, but the core dump routine didn't honor the memory protection. You would load an address register with the location of the root password, then trigger a core dump. The corresponding data register would get loaded with the password, then the dump routine would print it out. Since much of that was programmed into the hardware, it was never fixed.

      • by Ancient_Hacker (751168) on Wednesday February 17, 2010 @12:01PM (#31170270)

        > (I still have a pair) AFAIK, they cost much, much more than $100 each. They were core modules that had 48k by 1 bit and had been assembled by hand.

        Yes, I meant to say, more than $1000 in 1972 dollars.

        And yes, there were many ways to get passwords-- the simplest being to run the password changing program from one terminal and dump out memory from another. At first when you requested memory the OS did not zero it out! Easy password pickins.

        For a long while the password file was passed form system to system through ECS. A simple "DUMPECS" command would often dump out lots of passwords.

  • by originalhack (142366) on Monday February 15, 2010 @11:32AM (#31144428)
    The author and I were contemporaries and he forgot one very important reason he was never prosecuted. In 1974, there was no crime even if this had been done by an adult maliciously and for money. The pendulum, of course, has swung far in the other direction and users now face serious criminal charges for TOS violations.

    By the way, many of us who have good heads for computer security learned during years before it became a felony to practice.
  • by Baldrson (78598) * on Monday February 15, 2010 @12:27PM (#31145202) Homepage Journal
    Quoting David Woolley [thinkofit.com]:

    Reminds me of something I did on PLATO III. Back then, the -press- command let you give an argument to cause a keypress at another terminal. Naturally, the 16-year-old mind wonders what will happen if you put all the terminals in the classroom into a chain where a keypress on one ripples through them all and cycles back around to the original. Well, it hangs the system, that's what.

    I actually remember being there when the -ext- command exploit hit. It didn't hit me personally but it created quite an uproar.

    However, that was on that PLATO IV system in 1974. PLATO III was a few years earlier.

Never buy what you do not want because it is cheap; it will be dear to you. -- Thomas Jefferson

Working...