Slashdot Mirror


Local Root Exploit in Linux 2.4 and 2.6

Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"

49 of 795 comments (clear)

  1. *sits back* by Anonymous Coward · · Score: 3, Funny

    *awaits justifications and explanations of why this is nothing like Microsoft*

    1. Re:*sits back* by ackthpt · · Score: 5, Funny
      *awaits justifications and explanations of why this is nothing like Microsoft*

      Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

      --

      A feeling of having made the same mistake before: Deja Foobar
    2. Re:*sits back* by Anonymous Coward · · Score: 4, Interesting

      Second, it'll probably be patched rather quickly.

      I can only laugh out loud. Read this story for example.

    3. Re:*sits back* by Jay+Carlson · · Score: 5, Insightful

      It's quite a bit like Microsoft in one way.

      The uselib() system call is quite old. It was introduced in Linux 0.12 as a quick way to support dynamically loaded, statically linked libraries.

      The way shared libraries worked was like this:

      libc was compiled and linked like a normal program would be, except that its start address was set to (say) 0x400b0000. printf() would be at (say) 0x400cb110.

      Main programs were linked down at 0x08048000 or so, and knew where in memory printf was. The kernel knew how to load your main program and jump to its start. However, there was nothing but a segfault waiting for you at 0x400cb110 initially. So how did the kernel know what shared libraries to load?

      Well, one possibility was to put a list of library paths into the executable and teach the kernel to load 'em. Ugh. Didn't SCO do that?

      Instead, the linker would add a little assembly language stub to start your main program. It looked a little like:

      uselib("/lib/libc.2.so")
      uselib("/lib/libm.2.so")

      and the uselib syscall would graft the contents of those files directly into memory, in the same fashion the kernel knew how to load the main program. Voila, calling printf at 0x400cb110 will now work.

      Eventually, this switched to a single uselib("/lib/ld.so") so we could have search paths and dynamic linking. But it was a pretty good start.

      After we all switched to ELF, uselib wasn't such a good idea, as ELF allows some more clever things than just direct-mapping the whole executable at a fixed address. /lib/ld-linux.so switched to using mmap(). If you haven't run an a.out or libc5 executable, it is extremely unlikely your machine has ever invoked this syscall.

      As part of the a.out->ELF transition, the uselib() syscall was preserved. It allowed old-style fixed location libraries to be dressed up in new ELF clothing. A few years ago I tried uselib() on MIPS, and had a miserable time trying to get GNU ld to make a library the kernel didn't reject. I gave up.

      So how is this bug like Microsoft? The bug is in a mechanism that is a holdover from an older, simpler time. Nobody saw a good reason to take it out. And it didn't get much security scrutiny until somebody said, "hey, what's THAT still doing in my OS? I bet it's got bugs!"

    4. Re:*sits back* by identity0 · · Score: 4, Funny

      I was going to make a comment about "rounding up workers for underground C mines", but I figured that didn't sound painful enough.

      So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines.

    5. Re:*sits back* by EvilAlien · · Score: 4, Insightful
      Compare apples to apples unless you are also willing to count vulnerabilities in all the GNU stuff, other opensource apps included in major distros, etc. There are far more vulnerabilities announced on a frequent basis for Open Source due to its strength: transparency. The actual numbers of vulnerabilities/flaws in Microsoft's closed source code is unknown until a vulnerability is detected and announced. Open Source also has the potential of a vulnerability coinciding with a patch since those who detect can also fix due to the openness of the code... Microsoft relies on "responsible disclosure" to ensure that they are able to release fixes with vulnerability announcements. Closed source means that announcements can be scheduled and planned for monthly "patch day"... open source means that a vulnerability and maybe the fix can be announced at any time, and therefore with greater frequency.

      So, as far as the number of vulnerabilities, you can't convince me (as someone in the industry) that Linux "wins". You also can't convince me that the Linux kernel has far fewer holes found than the Windows kernel. The available evidence does not support the claim. However, that doesn't mean that the Open Source development method tends towards greater potential quality than the closed source method.

      Also, remember that a local root vuln is only 1 remote non-root vuln away from becoming effectively a root vulnerability. Too many people who think they are responsible admins try to ignore or downplay the seriousness of local root vulnerabilities.

      Thats enough rambling for the day...

      --
      perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
    6. Re:*sits back* by Laur · · Score: 3, Insightful
      And dont forget, recompile the kernel!

      Then run a different distribution. On Debian a new kernel is just an apt-get away, no compiling required (unless you need something special of course). I'm sure other distros are similar.

      --
      When you lose something irreplaceable, you don't mourn for the thing you lost, you mourn for yourself. - Harpo Marx
    7. Re:*sits back* by darc · · Score: 4, Funny

      Yeah yeah, that's the responsible thing to say. But responsible stuff is sooooooooo boring. I mean, if we were all responsible people that wanted stability, we'd all be running kernel 2.2, Apache 1.1, many year old revisions of programs patched to all heck, never install any packages that aren't yet at least of legal age, and still tout ISA support as a bleeding edge feature.

      Hmm. Wait, I think I just described Debian Stable.

      *is hit by a gigantic potato from the debian crowd*

      (Yes, I am aware that stable is called Woody, and the last version was called Potato. But if I said "is hit by a gigantic woody..." i'd probably get murdered. Oops.)

      --
      Tired of legitimate data sources? Try UNCYCLOPEDIA
    8. Re:*sits back* by EnronHaliburton2004 · · Score: 3, Funny

      Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

      Dude, he was our new overlord like 10 years ago, get with the program...

  2. Copyright Poo Poo by Anonymous Coward · · Score: 5, Interesting

    Read down to the Credits on the link and you see this line:

    Credits:
    ========

    Paul Starzetz has identified the vulnerability and
    performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
    INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
    ONE OF THE AUTHORS.

    Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

    1. Re:Copyright Poo Poo by _Sprocket_ · · Score: 4, Informative


      Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.


      What's interesting is the preface that shows up on several lists:

      Hi all,

      first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiated by Stefan Esser from Ematters. The posting containing the plagiate will follow. Now I have been forced to release the full advisory however another disclosure timeline have been agreed on vendorsec. Sorry for the inconvenience.

      Followed by:

      Hi all,

      first of all I must comply about the handling of this vulnerability that I
      reported to vendorsec. Obviously my code posted there has been stolen and
      plagiarized in order to put the blame on Stefan Esser from Ematters and
      disturb the security community.

      I really apologize to Stefan Esser for the inconvenience and thank him
      for his cool reaction - the plagiarism did work.

      Further steps must be taken to investigate the security leak on vendorsec.
  3. How the hell by BoomerSooner · · Score: 3, Funny

    How do people find this stuff? Amazing. Open source is astounding.

    When do I get my kernel update?

    1. Re:How the hell by pasde · · Score: 3, Funny


      When do I get my kernel update?

      No worry. I ve already installed it for you.

  4. won't be exploted here! by Dominatus · · Score: 5, Funny

    It's a good thing I've got the patch downloa

  5. Re:Failed on RHEL by ericzundel · · Score: 3, Interesting

    I tried it on a couple of boxes. It tries to exploit a race condition, so it won't necessarily work all the time. However I have tried it a few dozen times and haven't gotten it to work yet. (One RH 7.3 box and one RH 9.0 box)

  6. Re:What, no remote exploit?!? by Ly0n · · Score: 4, Insightful

    since windows is more "single user" oriented, most local exploit flaws on windows do not get very much publicity.

    For instance, shatter attacks are still a very large threat for multi-user windows systems

  7. Funny you should mention... by Yaa+101 · · Score: 3, Funny

    I need no exploit to gain root privileges, I just login...

  8. Re:Failed on RHEL by ericzundel · · Score: 5, Interesting
    Hmm. right after I posted that, it came through on the RH 9 box:
    ./elflbl -n2

    [+] SLAB cleanup
    child 1 VMAs 65527
    child 2 VMAs 65527
    child 3 VMAs 65527
    ...
    child 18 VMAs 63322
    [+] moved stack bfffb000, task_size=0xc0000000, map_base=0xbf800000
    [+] vmalloc area 0xdf800000 - 0xfedbb000
    Wait... \
    [+] race won maps=49205
    expanded VMA (0xbfffc000-0xffffe000)
    [!] try to exploit 0xe2d25000
    [+] gate modified ( 0xffec903c 0x0804ec00 )
    [+] exploited, uid=0

    sh-2.05b#
  9. Local Access is always a trump card by Delusional · · Score: 4, Interesting

    Is there ever a time when you can consider your systems secure against an attacker with physical access?

    1. Re:Local Access is always a trump card by rjstanford · · Score: 4, Insightful

      Well, yes and no. There's a difference between being vulnerable to those with physical access (pretty much always true, but very limited) and vulnerable to those folks with the ability to run something on your machine locally (fewer than true remote users, but much higher in number than those folk with actual physical access). All you need for this exploit is a way to run unpriv. code on the machine. Note that using a network exploit to run said code is a great way of gaining access - suddenly the fact that your webserver is running as "nobody" doesn't really matter any more.

      --
      You're special forces then? That's great! I just love your olympics!
    2. Re:Local Access is always a trump card by arose · · Score: 4, Funny

      Local as in "need user level access" not "need screwdriver level access".

      --
      Analogies don't equal equalities, they are merely somewhat analogous.
  10. Only in select modules? by Leadhyena · · Score: 3, Insightful
    Doesn't this only work if you compile the ELF and a.out support into the kernel, or am I mistaken? If so, it's just yet another reason to be VERY CAREFUL what you enable in the kernel when you compile it, lest you enable something that you don't need and is yet exploitable.

    I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.

  11. making APIs secure takes time by jeif1k · · Score: 4, Insightful

    "uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.

    1. Re:making APIs secure takes time by Alan+Cox · · Score: 5, Informative

      No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.

      Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.

  12. Distribution restrictions by cperciva · · Score: 4, Insightful

    COPYING, DISTRIBUTION, AND MODIFICATION OF
    INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
    ONE OF THE AUTHORS.


    Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."

    Security advisories should be in the public domain.

    1. Re:Distribution restrictions by Jerf · · Score: 4, Interesting

      Is it just me, or is this mind-bogglingly stupid?

      It's irrelevant anyhow. If you didn't sign a contract to keep it secret, they have no grounds to gag you. They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within. And neither does anything else.

      For the same reason, when you are accidentally mailed something with one of those "you must delete this immediately if you are not the intended recipient", unless it is actually and literally classified, you have no obligations. It's just to scare people.

      The legal system has a ways to go before you can be obligated by an email out of the blue, or a random announcement on a webpage taking rights not granted to them by copyright but implementing no real access control (i.e., attempting to obligate you after you downloaded a page; it might work if you make it a condidion of reading but not just out of the blue, after the fact).

      *: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.

  13. Typical biased Slashdotter numbers by Anonymous Coward · · Score: 3, Insightful

    Right, let's compare the flaw in a single kernel versus the ENTIRE OPERATING SYSTEM of Windows, GUI, shell, and associated apps like Internet Explorer as well as user-ran executable attachments in Outlook, which have nothing to do with Microsoft.

    What happened to all the "Linux is just the kernel" stuff? Oh, that's right, we were bashing Microsoft.

    Besides, if you mean "past year" as 2005, then this means Linux is first out of the gate.

  14. Re:What, no remote exploit?!? by lakeland · · Score: 4, Interesting

    Incidentially, the finding of exploits found in bind and sendmail has really slowed to a crawl.

    It seems that, even though they were written in different times and without security as the first concern, a sufficiently large number of bug fixes will eventually result in code that is almost as secure.

  15. Re:Local vs. Remote by rewt66 · · Score: 4, Informative

    In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.

    A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.

  16. Re:What, no remote exploit?!? by mm0mm · · Score: 3, Funny
    where as every nearly every Windows flaw is remotely exploitable?

    Don't you think it's more convenient for you to be able to hack multiple machines over LAN? Another reason to choose Windows over Linux.

  17. isec.pl's guys rule by diegocgteleline.es · · Score: 5, Interesting

    Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

    Take a look at the impressive curriculum of those guys:
    d_path() truncating excessive long path name vulnerability
    Linux kernel do_brk() lacks argument bound checking
    Linux kernel do_mremap() local privilege escalation vulnerability
    Linux kernel do_mremap VMA limit local privilege escalation vulnerability
    Linux kernel setsockopt MCAST_MSFILTER integer overflow
    Linux kernel file offset pointer races
    Linux ELF loader vulnerabilities
    Linux kernel IGMP vulnerabilities
    Linux kernel scm_send local DoS
    Linux kernel uselib() privilege elevation


    Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

    Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


    (And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

  18. Here's the exploit (-; by MacJedi · · Score: 3, Funny
    #!/bin/sh
    echo "1|nux r007 3xp10|7 by 1c4m7uf"
    cd /tmp
    cat >ex.c <<eof
    int getuid() { return 0; }
    int geteuid() { return 0; }
    int getgid() { return 0; }
    int getegid() { return 0; }
    eof
    gcc -shared ex.c -oex.so
    LD_PRELOAD=/tmp/ex.so sh
    rm /tmp/ex.so /tmp/ex.c
    --
    2^5
    1. Re:Here's the exploit (-; by Erich · · Score: 3, Informative
      For those not so versed in the way things work, here's what this does:

      getuid() and geteuid() get the "user ID" and "effective User ID". This scripts makes a library that makes these functions return 0 -- signifying that you are the superuser. It doesn't actually make you the superuser, but it implements functions that pretend you are.

      Anyway, then it compiles these functions into a library and tells the loader to link that library first. So when you start up a shell, it will call getuid() to figure out your userid, and your new library will tell it that you are userid 0. The shell prints out the root prompt instead of the regular one.

      But this in no way actually gives you root privs, if you go to edit /etc/passwd you will not be able to.

      Pretty funny joke, though, kind of like telling everyone that they can ftp to 127.0.0.1 using their own regular userid and password and find all the porn they could ever want...

      --

      -- Erich

      Slashdot reader since 1997

  19. Re: bugs in code by AceCaseOR · · Score: 3, Informative
    3rd party developers make buggy software too

    And when some third-party developers write buggy code, they really write buggy code. Remember "Return to the Pool of Radience: Ruins of Myth Drannor". Now that was a buggy game!

    --
    Zagreus sits inside your head, Zagreus lives among the dead, Zagreus sees you in your bed and eats you in your sleep.
  20. what's that sound I hear? by Trepidity · · Score: 3, Funny

    It's the sysadmins of University email and webservers across the country going apeshit as suddenly the entire student body potentially has root...

    1. Re:what's that sound I hear? by scottking · · Score: 3, Funny

      I wish there was a +1 Used 'Apeshit' in a sentence modifier.

      --
      scott king
  21. Fix is merged in mainline already by spurious+cowherd · · Score: 4, Informative
    See the message on The kernel mailing list

    raw diffs to for those brave souls who want them

    --

    Time flies like an arrow, fruit flies like a banana.

  22. Thank God... by mackman · · Score: 3, Funny

    Thank God I run Firefox!

  23. For those who say "just a local exploit..." by erroneus · · Score: 4, Insightful

    This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.

    Yes it's serious but I expect a fix shortly...

  24. Is this real? by agurkan · · Score: 3, Interesting

    May I recommend that Do not run this code if you can not understand what it is doing.
    For all we know, this is a social engineering trick to spread some malicious code. Let's wait until some official folks eg. CERT, or your vendor/distribution responds. Are the people who released this code have some credibility that can be verified independently?

    --
    ato
  25. Re:What, no remote exploit?!? by Foolhardy · · Score: 4, Informative

    Shatter attack

    It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
    Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
    A creates a window on the interactive desktop (a big no-no) with a textbox in it.
    B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.

    First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
    Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
    MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
    Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.

  26. Unfortunately not the only one... by greppling · · Score: 4, Informative
    LWN article about some more local security holes in Linux published today. The advisory does contain some harsh words about Linux security as well.

    I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.

    And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.

    1. Re:Unfortunately not the only one... by Anonymous Coward · · Score: 3, Interesting

      From TFA:

      Between December 15th and today, Linus has committed many changes to
      the kernel. Between January 2nd and today, Andrew Morton has committed
      several changes to the kernel. 3 weeks is a sufficient amount of time
      to be able to expect even a reply about a given vulnerability. A patch
      for the vulnerability was attached to the mails, and in the PaX team's
      mails, a working exploit as well. Private notification of
      vulnerabilities is a privilege, and when that privilege is abused by not
      responding promptly, it deserves to be revoked.

      Yawn.. oh well. I'm sure someone will point out how this is MUCH faster than the turn around that M$ will give. But hey.. this is Slashdot after all.

  27. Re:Combined with another flaw, it could be bad. by sloanster · · Score: 4, Insightful

    All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).

    - and if we had some ham, we could make ham and eggs, if we had some eggs... seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion. It is what it is and nothing more, and at the end of the day it will have resulted in none of the sort of disasters we see on a regular basis with the microsoft platform...

  28. Re:Combined with another flaw, it could be bad. by sloanster · · Score: 4, Insightful

    I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!

    This sort of thing is not as easy as you suppose - in the windows world one can write a quick vbscript to cause all sorts of nonsense, but on a unixlike platform such as Linux there would be a considerably higher barrier to the success of such shenanigans.

    It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.

    I see you've failed to understand my statement. I'm at a loss as to how my meaning could have been contorted from "a potential local exploit isn't going to cause the sorts of internet disasters as we see regularly with windows" into the bizzare statement "hardly anybody uses linux" - (strokes beard thoughtfully). We can put the lie to that sort of thinking by simply considering the apache webserver, it's market share, and security record, compared to the microsoft iis web server, it's market share and it's security record. And by "security record", I don't mean "counting the number of advisories from all linux vendors and comparing them to the number of advisories from microsoft", which is a meaningless comparison. No, I mean "compare the frequency, scope and severity of the security incidents associated with the two platforms", which would be much more telling.

  29. Re:How do universities, etc. deal? by JonMartin · · Score: 3, Insightful
    Well, it's Friday at 1730 as I type this. I'm about to download 2.4.29-rc1 (which has a fix). Then I'll shoe horn some oddball patchballs into it (they haven't applied cleanly in a few kernel revs), config, make and test. If all goes well I'll be rolling it out and rebooting our ~150 Linux boxes by 1900.

    In short, this one is too big (too exploitable, too public) to wait until Monday.

    My life would be so much easier if profs didn't have such a hard on for Linux and let us admins install OpenBSD. Good thing I get paid overtime. Oh wait, I don't.

    --
    Serve Gonk.
  30. Re:What, no remote exploit?!? by Foolhardy · · Score: 3, Informative
    I thought MS issued a hotfix for this a couple of years ago, around about the time XP SP1 was released, I thought.
    Sending unsolicited WM_TIMER messages to another process has been blocked, but there are still other messages that can cause arbitrary code execution. The messaging model was inherited from versions of Windows way before security was considered. Sending messages (even the unsafe ones) to other processes can't be blocked or it would break way too many things. No security isn't an option in NT, so the solution is to break the environment into sandboxes. Inside each sandbox, however, there is no security; all the security is at the front door.
    So why, when security flaws are caused by applications doing something that the Windows API documentation specifically instructs them not to do, is this considered a flaw in Windows?
    It's not, but that doesn't stop some people from blaming Windows anyway. It also doesn't prevent 3rd party developers from writing insecure apps, that (when trusted by an admin) can break the system. Notice that Microsoft threatens to stop supporting interactive services in the docs, to try and get developers to clean up their act, but they will never do it, as Microsoft has compatibility as too high a priority.
  31. No, think about it ... by Seraphim_72 · · Score: 3, Interesting

    Actually copyrighting the exploit is kinda cool. Say you are a admin, and some kid gets fresh and tries this out. "Hey kid, not only am I nailing you to the wall for this, but I am turning you over to the guy who "owns" it and you get to pay him a nice fine." No, I think that is it pretty hilarious that the code is copyrighted.

    Sera

    --
    Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
  32. Dangit... by catdevnull · · Score: 3, Funny

    All those MCSE dorks down the hall are gonna give me sh*t for the next week.

    Reminds me of a punchline to my favorite Scottish joke:
    "Aye, lad...ya screw ONE goat..."

    --

    I might know what I'm talkin' about, but then again, this is Slashdot...