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

 



Forgot your password?
typodupeerror
×
Security Education

Canadian University to Begin Training Hackers 379

torok writes "According to an article at The Edmonton Journal, The University of Calgary is going to start teaching select computer science students to write software viruses in a special new disconnected lab. Will Canada be accused of training the world's next generation of cyber-terrorists... or peacekeepers?"
This discussion has been archived. No new comments can be posted.

Canadian University to Begin Training Hackers

Comments Filter:
  • Just tools (Score:3, Insightful)

    by IronBlade ( 60118 ) on Thursday May 22, 2003 @08:48PM (#6020213) Homepage
    The fact they are learning the hows of a skill does not mean they will use the skill maliciously.
    In fact, when educated, most people will use their powers for good, not evil.. :)
  • by boredMDer ( 640516 ) <pmohr+slashdot@boredmder.com> on Thursday May 22, 2003 @08:55PM (#6020267)
    "they could author some detection scheme that monitors for activity that is like a virus"

    Hueuristics, anyone? (Yes, I horribly butchered the spelling of that word, I know.)
    Granted, that sort of technology is somewhat prone to false alarms, but we have it. We just need to work on improving detection techniques and and reducing/eliminating false positives..
  • Don't overreact (Score:5, Insightful)

    by Mossfoot ( 310128 ) on Thursday May 22, 2003 @09:00PM (#6020318) Homepage
    After all, by studying how viruses are made, you can better understand them and thus make better anti-virus software. The kids going here are not going because they want to learn to be L33T cyber hackers or whatever, but knowing the tools of the trade (white and black hat) will help them in the computer programing/protection field.
  • peacekeepers (Score:3, Insightful)

    by tarzan353 ( 246515 ) on Thursday May 22, 2003 @09:07PM (#6020358)
    No matter what path they choose, whether to be malicious hackers or peacekeeping notify-devs-before-it-gets-noticed types, the end result will be the same: better code.

    Now if only we can get MS to believe what us open source folks have been saying for years!
  • Re:Crackers (Score:5, Insightful)

    by RobotRunAmok ( 595286 ) * on Thursday May 22, 2003 @09:10PM (#6020379)
    losing battle

    Lost, son. Circa 15 years ago. Woulda helped had we picked a word not already firmly ensconced in both the vernacular (thin biscuit) AND slang (narrow-minded Southern whitey) simultaneously. 'Cracker' never stood a chance; teenage cabals can *suggest* lanaguage, but it's up to the media to bless it and disseminate it.

    Just let it go. As a geek patheticism, insisting on the use of the word "cracker" over "hacker" is starting to rank up there with wearing one's plastic Vulcan ears out in public.
  • by caouchouc ( 652238 ) on Thursday May 22, 2003 @09:18PM (#6020443)
    As a software engineer, I have to say that the perceived "skill" required to write a virus is blown way out of proportion.

    There's nothing inherently special about a virus or a worm. They're actually very simple, and most malware writers today are not very talented. They produce bloated, barely functional software (scripts, for the most part today) that is only dangerous because the average user is so trusting. I remember when viruses were actually smaller than the files they infected...

    Got coders in your firm? If they're capable of writing inter-operation layers for your apps or database frontends, then they're capable of writing viruses and worms far worse than bugbear. But chances are they don't, because it's a waste of time.

    Those students don't need specialized virus-writing courses. A simple assembly course would put them lightyears ahead of the "bad guys" if they actually paid attention for once.
  • by KrispyKringle ( 672903 ) on Thursday May 22, 2003 @09:21PM (#6020455)
    This is, in fact, the case at many universities. The U of P, birthplace of ENIAC, teaches (this may change soon, apparently) O'Caml (a branch of ML) in the first semester of intro to programming. Talk about useless, perhaps, but the idea is not to teach just technical proficiency (something easily learned at a local community college) but to teach theory. O'Caml teaches recursion and functional programming well, and levels the playing field for those who have and have not had C/C++ in high school.

    Incidentally, they then move to Java, although C is taught in Systems Engineering and used somewhat in later Computer Science courses.

    The idea here is that anyone can learn any language fairly quickly. It takes a week or so to pick up a new OO language if one is proficient in theory; if one learns only how to use a certain language or API, though, he will have a much tougher time adjusting.

    Certainly, this has some flaws, but the general approach is wholly valid. There is no reason to just teach the current programming lingua franca; standards change. Learning how to write something provided in the VB API or Java API may also seem silly, but its done for the same reason. CS courses here don't teach a specific language, they teach with a specific language. The language illustrates; it itself is not the objective.

    Students who are taught just one specific skill and language can't see the forest for the trees. Students who can see the big picture can learn to deal with unfamiliar details.

  • by ryanr ( 30917 ) * <ryan@thievco.com> on Thursday May 22, 2003 @09:58PM (#6020650) Homepage Journal
    You don't secure systems against viruses. You have to secure people against them. They're a behavioral problem. A virus doesn't need any kind of flaw to propagate, it just needs a trusting person. You could write a bugless operating system, and as long as a regular user can use it to get useful work done, then the same user can also infect it through neglect, ignorace, or maliciousness.
  • by Frater 219 ( 1455 ) on Thursday May 22, 2003 @10:05PM (#6020689) Journal
    My job includes being the computer security guru for my workplace. In that role, it's my job to understand the way my clients' systems work, so that I can recommend effective operational ways to improve their security. It's also my job to understand the world of attacks -- not just keeping my ear to the ground regarding what kind of shit is going down at the moment, but understanding what attacks are possible, which are likely, and which are worthy of taking special defensive measures.

    I recommend strongly that anyone in a role like mine take some time to study viruses, exploits, rootkits, and other pieces of hostile code. These are a basic part of the security environment in the field. The more you understand the crap that the Net's rejects and crackheads are throwing at you, the better a job you can do.


    Here's just one example of what we can learn from viruses; a bit of an older example, so I'm not doing too much of your work for you:

    Let's say your client is considering a bonehead move -- like, say, deploying Microsoft Outlook enterprise-wide. Any security nerd can say "duh, Outlook sux0r, it's full of vulnerabilities, that's why it spreads viruses." However, if you have read the source code of the LoveLetter and Melissa viruses, you will realize (and can explain to your client) that these viruses do not exploit vulnerabilities at all -- at least, not in the sense of buffer overflows and other attacks which target bugs in software. These viruses don't crack anything -- they use perfectly ordinary, documented API calls. It isn't holes in the Windows Mail API that make it a virus breeding ground -- it's just its built-in, designed, intended functionality. That's why these viruses can still spread after years of bug fixes: their critical paths do not rely on bugs at all.

    What do we learn from these viruses? Security is not about patching bugs, or having bug-free software. It is about correctly modeling the trust relationships people have with each other regarding their computer resources, in software. The Windows MAPI's design implies an assumption that people want to entrust word-processing documents with the power to send hundreds of emails. That's obviously wrong -- and that, not any bug, is what must be explained to convince someone that Microsoft's mail software is a bad security choice.


    There are many more lessons to be learned by understanding hostile code. There are lessons about user interface design: many email viruses depend on getting the user to take some action (opening a message, running a macro, etc.) which unintentionally grants the virus trust and privilege (even the privilege to run code) that it should not have. To design secure systems for users, we must have user interfaces which do not promote such deception. There are lessons about system monitoring and the habits of sysadmins: Unix rootkits, which alter the system to conceal the tracks of an attacker, show just how easily a too-shallow maintenance or log-checking routine can be deceived. There are many lessons.

    Get yourself some virus source code. Google will help. Read rootkit code, and the analyses thereof which researchers on SecurityFocus [securityfocus.com] and other sites have published. Understand these attacks, and you will understand the systems they target better than you do now.

  • Re:Crackers (Score:3, Insightful)

    by ryanr ( 30917 ) * <ryan@thievco.com> on Thursday May 22, 2003 @10:06PM (#6020691) Homepage Journal
    You are wrong, I was there when the terms hacking and cracking came to be and people seem to have forgotten it.

    Wow, you were in the MIT model railroaders club in the 1950s? That must have been cool. What was it like?
  • by Microsofts slave ( 522033 ) on Thursday May 22, 2003 @10:06PM (#6020692) Homepage Journal
    canada has always had an amazing real Peackeeping force, perhaps this is the beginning of a virtual peace keeping force.

  • by Lord Ender ( 156273 ) on Thursday May 22, 2003 @10:07PM (#6020702) Homepage
    "the idea is not to teach just technical proficiency (something easily learned at a local community college) but to teach theory."

    I am about to graduate, and I am severly pissed at my university for just teaching me "theory." If they would have taught all the classes in C or Java, instead of an obscure, unused language, then I would actually be able to claim a high level of proficiency in a language on my resume. As it stands, I am now very good at the language my Uni uses to teach, but that is worthless on a resume!
  • Re:Crackers (Score:3, Insightful)

    by ProfessionalCookie ( 673314 ) on Thursday May 22, 2003 @10:19PM (#6020742) Journal
    Crackers, not hackers.
    Ummm...Are you just saying that because you've heard it said?
    The University of Calgary is going to start teaching select computer science students to write software viruses in a special new disconnected lab.

    Is there anything in there at all that in the slightest way implys cracking? Specifically: "Write Software" and Disconnected Lab"

    I don't like it when vandalist script kiddies call themselves hackers any more than the next guy, but these students wil be taught to be hardcore software engineers, not crackers. Jerk. *tee hee*
  • The best... (Score:2, Insightful)

    by voxel ( 70407 ) on Thursday May 22, 2003 @10:22PM (#6020755)
    The best bomb creators make the best bomb technitions.

    I'll take anti-virus software from the most "evil" virus creating minds in the industry over some programming wannabe's anti-virus software.

    This is granted that these "evil" virus creating minds arn't too "evil" and put back-doors in their anti-virus software :)

    - Jeff
  • by mix_master_mike ( 540678 ) on Thursday May 22, 2003 @10:38PM (#6020863) Homepage
    if ($Hacking == $VirusWriting)
    { print "the media has won"; }

    for goodness sake...
  • by Seek_1 ( 639070 ) on Thursday May 22, 2003 @11:06PM (#6021025)
    I think you're confusing hate with envy here....
  • Re:Crackers (Score:3, Insightful)

    by uberdave ( 526529 ) on Thursday May 22, 2003 @11:17PM (#6021073) Homepage
    So, we should stop using ram when referring to computer memory, because the majority of the English speaking world considers it to be a male sheep? Should we start referring to the system case as the "hard drive" and the monitor as the "computer"? Should we call 3.5" diskettes "hard disks" and 5" disks "floppies", simply because that's what the unwashed masses refer to them as? No, *WE* defined the term. The world misuses it. We need to keep the "cracker not hacker" cry up. Someday, the mundanes will be enlightened.
  • Hacker != Cracker

    Hackers are people who try to make computers do innovative new things. Bill Gates is a hacker (Manages to slow your computer down as fast as Moore's Law speeds it up...). Ok... Eh, bad example :). Crackers are malicious people who want to cause electronic anarchy and chaos. Now there is no denying that some of the hackers the university wants to train may go over to the dark side, but most of them will stay on the light side.

    A different analogy: Hiring a cracker is like putting a serial bomber on the SWAT bomb squad. Hiring a hacker is like hiring someone with a natural gift for diffusing bombs.
  • 10 years ago... (Score:5, Insightful)

    by dcollins ( 135727 ) on Friday May 23, 2003 @01:25AM (#6021673) Homepage
    Writing viruses was actually covered in the assembly language class I took at UMaine circa 1992, in the last chapter of the instructor-written textbook. The rationale in that case was that in informing CS students how easy it is to write viruses, they would no longer see them as technically impressive and therefore not be interested in pursuing their creation. (I just taught my first assembly class this past semester, and use this as an anecdote without actually covering it myself.)

    Since I have the text right here, I'll quote it: "...you do not have to be a genius to write a virus... Some people use virus writing to prove their programming skill, but this is poor proof of such skill in my opinion. It's about as much proof of genius as throwing a brick through a window."
  • by Anonymous Coward on Friday May 23, 2003 @02:38AM (#6021883)
    Nahhh .. good virus's are hard to make. It's not quite as easy as writing a simple program. It's good to see that initiative taken ..it's far overdue. It's the "right to bear arms" principle applied to software. This case of course the "arms" is knowledge.
  • by Saint Stephen ( 19450 ) on Friday May 23, 2003 @04:16AM (#6022140) Homepage Journal
    The fact that most viruses are so simple should scare the hell out of you. All virii to date just rely on the hosts ignorance -- the virus writer knows something the host doesn't. Plus, even the worst attacks are just annoyances. You haven't seen a really evil virus.

    Like, what if the next virus directs all the modems to dial 911 at the same time, and coordinates that with a real world terrorist attack?

    I use the analogy that current virus writers are like Palestinians strapping bombs to themselves and blowing themselves up -- any fool can do it, you just have to sneak past. You haven't seen the Al Quaeda of viruses yet.
  • by Anonymous Coward on Friday May 23, 2003 @10:18AM (#6023480)
    god, NO MORE terrorism jabbering! Thousands are killed every day by all kinds of other shit. Terrorism accounts for so little death it's insignificant. The likelyhood of getting killed by a terrorist is roughly the same as getting hit by lightning. So chill.
  • by DickBreath ( 207180 ) on Friday May 23, 2003 @10:44AM (#6023686) Homepage
    There's nothing inherently special about a virus or a worm. They're actually very simple, and most malware writers today are not very talented.

    Then we need to get some good HOWTO's and code examples of how to write more sophisticated viri out there.

    First, most viri use a single attack vector. That is, they use only one means to spread. What if a single program could use multiple different exploits? Any exploit that was effective would allow the program to spread.

    Even better, imagine, if the program could use exploits against several different architectures? For example, there is a vulnerability in program FOO. An x86 exploit is written. Why not use the exact same approach and weakness to also build a PowerPC, Sparc and Mips binary exploit? In some cases it would no doubt be possible to have multiple architecture binary exploits for the same source-level vulnerability.

    In fact, a core, reusable "engine" could carry a catalog or matrix of exploits and binary attacks of those. So we've identified a system to attack. We identify its OS and architecture. Select a range of attacks that match the target, and try them.

    Why is this so different than most viri? The only real difference I see is the amount of effort to assemble and package it. Plus the virus just seems to have a much bigger footprint or carries a much bigger set of binary baggage around.

    Such a program needs to also go to more effort to conceal itself. No matter what form the package arrives in and what OS it is running on, it should know how to "repackage" itself into something that looks like an executable program, or a library. Even better, on most platforms it should be possible to also piggyback onto another executable, dll or possibly kernel module or windows driver. What about as an Apache module, or a Gimp plug in, an Xscreensaver module, a KDE control center module, or other forms? (i.e. windows screensaver that might get randomly activated soon?)

    When the program "repackages" it should be able to do it in a non-deterministic way. That is, the order that various binary components are ordered within the "packaged" exe or elf file should not be predictable. Better yet, a trivial scrambling of the binary (psuedorandom xor, or maybe *real* crypto) helps reduce the detectable "signature" of the binary. When the program "lands" as an exe file on the hard drive, it should not have a predictable name. Variety is the spice of life. Genetic diversity helps to improve survival characteristics. When someone prepares a "cure" for the program, they may not realize that the way they "recognize" it may be flawed, or won't recognize it in all its various forms.

    There also needs to be various "modes" of repackaging. "Oh, I just arrived on a system where I don't have root privileges become someone is running Apache as wwwrun." So repackage as a "seed" or "spore" that may someday spring back to life. Self-reconfigure into a number of useful commands that try various local privilege escalation attacks. "Oh, I just landed on a system as a non-privileged user, but an actual user with a home directory, so reconfigure as a seed, alter the .bashrc, or put me into the Start->Programs->Startup folder, etc. so that my 'seed' is likely to get executed."

    You know, even a 1 MB sized virus could carry a lot of sophistication. I remember back in the day when a 64 K program was considered pretty darned big. Today a 1 MB file is getting easier by the day to hide and get "lost in the noise" on ever increasing 100 GB plus filesystems with ever higher inode counts.

    It would possibly take people from a range of interests (processors, platforms, OSes, kernel module interest, windows internals, etc.) in order to put such a beast together.

    If it could be made available in the form of an SDK such that you could just put your payload source code into the right place, and then the SDK can compile it for multiple platforms, archit
  • by Brad Cossette ( 319687 ) on Friday May 23, 2003 @12:12PM (#6024538)
    I'll second this as an almost grad of this program.

    You're right C isn't taught. You're expected to be able to figure it out due to exposure to C++ and assembler in 2nd year. You must know it though - you'll get nailed otherwise. I've taken the following courses where we used primarily or only C:
    - 2nd year: Architecture (assembler for PDP-11 via simulation, Intel x86, and integrating x86 assembler with C routines.
    - 3rd year: Another architecture course which involved writing device drivers for assignments. All C coding.
    - O/S course, projects consisting of at least one modification to the OpenBSD O/S and three other O/S related ones in Solaris (my 4 were implementing an md5 hash as a system call in OpenBSD, writing a process scheduler for Solaris, writing a parser that would translate a set of extensions into the appropriate POSIX calls, and writing a virtual memory simulation with sorting routines.) All code was in C
    - There's a number of 4th year courses that have a heavy C focus as well due to lower level work. Compared to some other CPSC programs, the U of C has a strong low-level focus. Your statements would be more true of other universities.

  • by SatanicPuppy ( 611928 ) <SatanicpuppyNO@SPAMgmail.com> on Friday May 23, 2003 @01:04PM (#6025054) Journal
    If you don't understand it, then your options in fighting it are limited. A noob running a blade cluster on a t3 line has only one option when some script kiddie takes over his system: unplugging it. Far from optimal.

    We have all this "anti-virus" software, but it is completely misnamed. If you get a flu shot, it's not an anti-virus, its a pallative. A weak shield against infection, not an active agent of protection. The same goes for the software that we currently use. I want to be able to unleash righteous nastyness against the damn viruses in my system, not poke around with fricking bloated software that's always playing catch up.

    Until we learn to beat them at their own game, then it will BE their game.

    Just my opinion.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...