Forgot your password?
typodupeerror
Software Linux

Linux Kernel Back-Door Hack Attempt Discovered 687

Posted by simoniker
from the intrigue-and-skullduggery dept.
An anonymous reader writes "The BitKeeper to CVS gateway was apparently hacked in an attempt to add a root exploit back door to the Linux kernel, according to the linux-kernel archive. The change was in the file kernel/exit.c and changed the user ID of a process to root under the guise of checking the validity of some flags. The core Linux BitKeeper kernel repository was not at risk, and in fact it was the BitKeeper CVS export scripts that detected the unauthorized modifications to CVS. The changes were falsely attributed in CVS to long-time Linux developer davem (David Miller). Users of the BKCVS repository should resync their trees to remove the offending code if they had replicated it since yesterday."
This discussion has been archived. No new comments can be posted.

Linux Kernel Back-Door Hack Attempt Discovered

Comments Filter:
  • Well well (Score:5, Insightful)

    by toddhunter (659837) on Thursday November 06, 2003 @01:39AM (#7404305)
    Good to see the system works. You would wonder what would happen if said hacker was working for a company on a similar closed source program. Would it have been detected?
    • Re:Well well (Score:5, Interesting)

      by chill (34294) on Thursday November 06, 2003 @01:46AM (#7404358) Journal
      Good to see the system works. You would wonder what would happen if said hacker was working for a company on a similar closed source program. Would it have been detected?

      You mean like Borland's Interbase? The compiled in backdoor [cert.org] wasn't discovered until after the database opensourced.

      My favorite quote from the advisory is:

      "This vulnerability was not introduced by unauthorized modifications to the original vendor's source. It was introduced by maintainers of the code within Borland. The back door account password cannot be changed using normal operational commands, nor can the account be deleted from existing vulnerable servers [see References]."

      How long was it in there? "These security holes affect all version of InterBase shipped since 1994, on all platforms."

      The advisory dates from 2001 -- you do the math.
    • by Anonymous Coward on Thursday November 06, 2003 @01:53AM (#7404408)
      You would wonder what would happen if said hacker was working for a company on a similar closed source program. Would it have been detected?


      Well the 12 backdoors I put into the Windows XP kernel haven't been detected yet.

    • Re:Well well (Score:5, Interesting)

      by Narphorium (667794) on Thursday November 06, 2003 @02:03AM (#7404469)
      Although I see where you're going with this, I think a lot of people might ask whether this shows vulnerability in OSS instead. Sure, you and I appreciate this as a validation of the system but is that really how the media is going to portray it?

      All I'm saying is that I certainly won't be surprised when closed source vendors start using this in their anti-OSS campaigns.

    • Re:Well well (Score:5, Insightful)

      by The Munger (695154) on Thursday November 06, 2003 @02:04AM (#7404480) Homepage
      Good to see the system works.

      And what if we just haven't discovered the code that got through yet...

      You've got to ask - assume nothing.

      +5, Tin-foil hat.
      • Re:Well well (Score:4, Insightful)

        by Geek of Tech (678002) on Thursday November 06, 2003 @02:22AM (#7404570) Homepage Journal
        Well, I guess that means all the closed source developers have the same problem. And I guess they probably don't know either.

      • Re:Well well (Score:3, Insightful)

        by Filik (578890)
        Actually, the mere fact that these people saw the need to insert a new backdoor is a good sign (though not proof) that there aren't any old ones (or that they weren't very talented).
      • Re:Well well (Score:4, Insightful)

        by Haeleth (414428) on Thursday November 06, 2003 @06:44AM (#7405504) Journal
        > And what if we just haven't discovered the code that got through yet...

        1. We know that SCO have been looking very closely at the Linux source code.

        2. We also know that none of the Linux boxes which serve major anti-SCO websites have been hacked into.

        3. We can deduce therefore that SCO have not found any backdoors in the Linux source code.

        While given their general level of (in)competence this doesn't amount to proof that there aren't any, it's probably a fairly safe bet.
      • Re:Well well (Score:3, Insightful)

        by Anonymous Coward
        Two Brazilian expressions, for your delight:

        1) "Boi de piranha":

        When you want to make a cattle herd cross a piranha-infested river, you probably will lose many cows (or oxen) -- the trick is get a first ox inside the river for sacrifice; while the piranhas devour it, the rest can pass unharmed.

        2) "Porteira que passa um boi, passa uma boiada":

        If a gate is wide enough for passing an ox, it's wide enough for an entire herd.

        -//-

        Have a nice day!
        • by Greedo (304385)
          When you want to make a cattle herd cross a piranha-infested river, you probably will lose many cows (or oxen) -- the trick is get a first ox inside the river for sacrifice; while the piranhas devour it, the rest can pass unharmed.


          Well, in theory.

          Of course, you send in the first ox, and the pirannhas attack it. Then you try and get the other oxen to cross, and they are all like "Fuck this man, I ain't going in that freakin' river! Look at what's happenin' to Bob!!!"
    • Re:Well well (Score:5, Interesting)

      by blair1q (305137) on Thursday November 06, 2003 @02:24AM (#7404588) Journal
      It was only detected because software found a discrepancy.

      This would happen at any closed-source shop that had the same software.

      No human eyes discovered the problem, and if someone hadn't installed the checks, it might not have been discovered for months or years or ever.
      • Re:Well well (Score:5, Insightful)

        by danheskett (178529) <danheskett AT gmail DOT com> on Thursday November 06, 2003 @02:38AM (#7404652)
        Not only that, but imagine this. The hackers (in the real sense, not the TV-movie sense) who write the real low-level stuff that makes various OS's work - for example in Linux people like Alan Cox, Linus, RMS, ESR, davem, and the other regular kernel contributors submit a lot of code. Well, those people dont necessarily but a lot of code is in the kernel.

        Can anyone tell me for 100% certain that between GCC, the kernel, and various compile chain tools there isn't a subtle backdoor that creates an overrun, or a weak key, or anything like that somewhere along the line? Maybe what looks like an innocent bug or flaw or even stylistic change in one source combines with a similiar item in another source to create an exploit or a weak scheme.

        These people - real hackers - are so clever (I mean serously, writing and maintain an OS for fun puts these programmers in the top 1% of all advanced systems programmers) that what is to say that they couldn't dupe everyone even with the source available to all?

        I can imagine a situation where a corrupted/corruptable individual works hard to gain legitimate comitt access to certian tools that are widespread. GCC, the kernel, a shell or two, OpenSSL. That person starts making small changes that when aggregated expose a large exploit but when examined piece-mail are completely benign, or even benficical.

        Does anyone doubt that its technically possible? How could any automated system or person ever discover this? I am a fairly competent programmer in some areas and there have been numerous times that I've had to dissect large pieces of code painstakingly over the course of days or weeks to trace back a nasty bug. Can anyone say that its not possible that this is *already* happening in the OSS world today?
        • Re:Well well (Score:5, Informative)

          by sartin (238198) <sartin@aPLANCKcm.org minus physicist> on Thursday November 06, 2003 @03:06AM (#7404775) Homepage
          what is to say that they couldn't dupe everyone even with the source available to all?

          You mean like this [acm.org]?

        • Re:Well well (Score:5, Insightful)

          by rodgerd (402) on Thursday November 06, 2003 @06:10AM (#7405404) Homepage
          As anoth poster has pointed, this is a well-known thought experiment, and what it boils down to is: at some point, you have to trust someone.

          Have you audited your motherboard BIOS? What about your network card - how do you know it doesn't have an IP stack on the ROM that dials home and dumps your network activity to someone? Hubs? Switches? Routers?

          Do you really know what lives in your hard drive controller?
        • The hackers [...] who write the real low-level stuff that makes various OS's work - for example in Linux people like Alan Cox, Linus, RMS, ESR, davem

          Ha ha ha. Yep, Cox, Linus and DaveM are without doubt low level hackers. But RMS and ESR? RMS is admittedly somewhere between high and low level, getting down to compilers and linkers, but not down to kernel level. But ESR is strictly a userland programmer.

          • by Khazunga (176423) * on Thursday November 06, 2003 @06:55AM (#7405532)
            RMS *must* be a low level hacker. He shows all the signs: long beard, long hair, smells, can't behave in front of people, yawns at conferences. Heck, he even farted at a conference at my Uni.

            If he isn't a lowest level hacker, my world foundations are crumbling...

            • Re:Well well (Score:3, Insightful)

              by blowdart (31458)
              RMS *must* be a low level hacker

              No, he's a low level heckler ... "Shut up! It's GNU linux." "Shut up! It's GNU linux." (repeat ad nauseum)

        • by muonzoo (106581) on Thursday November 06, 2003 @09:31AM (#7406180) Homepage
          Of course, at some point, we do have to trust someone.
          Ken Thompson [bell-labs.com] wrote an original speculative essay [acm.org] on this for CACM [acm.org] back in 1984 of all years.

          It is really well worth the read. The short form is that there exists a way to subvert the compiler such that it is no longer trustable and it will build a back door into the OS forevermore. This paper is a must read.
          • I wonder if there is not a way to defeat such a method?

            For those who didn't read the article by Ken Thompson ( read it here [acm.org]) a compiler is corrupted so that it inserts a bug into all compilers that it compiles, and the purpose of that bug is to insert a bug into another program (such as login) when it compiles it (such as accepting a certain password as the root password)

            Both bugs have to be a pattern based search method. They look for some string or some sequence of characters that the original hacker be
    • Would it have been detected?

      A better question, assuming it was detected, is:
      Would the consumers at risk have even been told about the attempt?

    • by Johnno74 (252399)
      Maybe it was someone from SCO, inserting code from UnixWare to give them the 'evidence' they need...

      Has anyone tried sys_wait4(__WCLONE|__WALL) on Unixware? ;)
  • by NegativeK (547688) <tekarien@NoSpam.hotmail.com> on Thursday November 06, 2003 @01:40AM (#7404310) Homepage
    Someone has some damned big balls to do something like that...

    Let's hope they're cut off.
  • Microsoft (Score:3, Funny)

    by mr100percent (57156) * on Thursday November 06, 2003 @01:40AM (#7404311) Homepage Journal
    Anybody point fingers at Microsoft yet? SCO?

    • by Cobralisk (666114) on Thursday November 06, 2003 @01:43AM (#7404339)
      No, but I'd like to see them claim copyright infringement on back-door code.
      • Dunno if there is anything here of public value:

        if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;

        • by Krellan (107440) <(moc.nallerk) (ta) (nallerk)> on Thursday November 06, 2003 @06:53AM (#7405531) Homepage Journal
          The vandal who put this in the CVS code tree obviously had a lot of skill.

          It's a clever backdoor, and might have gone unnoticed, if not for those those good automated checks in the BitKeeper-to-CVS gateway. Notice that the particular coding style is a common C gotcha (using "=", assignment, instead of "==", comparison). At first glance it looks like the value of uid is being compared with 0, when in actuality it is being assigned the value of 0: root! The gcc compiler is good about warning for this, except that this too has been defeated: as mentioned on the mailing list, notice the unusual high number of parenthesis around this expression. That high number of parenthesis has the effect of suppressing the gcc compiler warning.

          So, whoever did this obviously knew what they were doing and tried to obfuscate it. As somebody else mentioned on the kernel mailing list, if somebody is going to put in a backdoor like this, why not make it a remote root hack?

          As it is now, the above hack is only locally exploitable. A process on the local system still has to call the wait system call with that particular combination of flags, in order to trigger the exploit and get root. To my knowledge, no known applications do this, because the combination of flags is supposed to be invalid.

          If a spammer or somebody else was trying to backdoor the Linux kernel in order to gain a large number of machines to infest, then one wonders why they didn't put in a remote root exploit. It seems strange to go to all the trouble. Since this backdoor attempt has been caught and blocked, security will now only become tighter, and they might not ever get another chance like this.

          Maybe it was intended to be used with another application, also backdoored in the same manner? It might be insightful to scan other open source applications and search for this particular usage of flags to the wait system call.

          In any case, I'm glad this hack was caught!
          • Who says this wasn't one part of a larger plan?

            Slip in a priveledge escalation bug that's hard to catch. Wait a week or two for it to make its way into the main repository unnoticed, then go back and add a little bit of code to the networking stack or Apache, etc, that allows you to execute arbitrary code as the user running the service.

            what is creepy is that the latter may have preceeded the former, and some remote execution exploit has gone unnoticed somewhere.
          • Nonsense, you're talkin out of your arse.

            The brackets are necessary to even get the thing to compile as the precedence of '=' is below that of the logical operators.

            bash-2.05a$ cat > test.c
            int foo() {
            extern int x,y,z;
            if(x>y && z=0) x=y;
            }
            bash-2.05a$ gcc test.c
            test.c: In function `foo':
            test.c:3: invalid lvalue in assignment

            YAW.
    • Anybody point fingers at Microsoft yet? SCO?

      Why stop there? ... you have six more!

      And two thumbs too! :P :D
    • Of course neither MS not SCO has ever acted unethically. It would be absurd to suspect companies of such high morals. I for one would be SHOCKED if somebody told me that MS or SCO might do something sleazy in order to undermine Linux.
    • Re:Microsoft (Score:3, Interesting)

      by MrLint (519792)
      My guess is more likely DDoS and spam hackers. Looking for ways to get in and grab more things to attack with.
    • Re:Microsoft (Score:5, Insightful)

      by iabervon (1971) on Thursday November 06, 2003 @01:59AM (#7404445) Homepage Journal
      The actual lines of code and the method by which they got there were far too clever for either Microsoft or SCO. In particular, it looked like a check for an invalid combination of flags by root, but would actually set the process to root in the case of the invalid combination of flags (and the error return value would be overwritten).

      The intent was probably that a CVS user get the bad version, work on other stuff, and send the diff (including the bad lines) to a maintainer in an otherwise good patch. However, the BKCVS gateway got confused by someone other than it changing the CVS, and complained, and Larry McVoy pointed out the issue, someone asked what the lines were, and other people figured out what they'd do. Now, of course, if someone had gotten that bit accidentally and submitted it to a maintainer, they'd notice, so the attempt seems to have failed.

      Linus pointed out a benefit to using BK: even if the official BK repository were changed, he doesn't pull from it (because his local copy has all of his changes), and he would get an error the next time he pushed to it. The repository that would have to be attacked is actually his local disk, behind a firewall and not set up for anyone else to access at all.

      If RMS wants to rant about revision control systems, he'll need to say that CVS needs to be replaced with a more functional alternative (Subversion, perhaps), not BK.
      • Re:Microsoft (Score:5, Informative)

        by Tailhook (98486) on Thursday November 06, 2003 @04:13AM (#7405022)
        The actual lines of code and the method by which they got there were far too clever for either Microsoft or SCO

        It was a subtle change but I think it would have been caught if it had been submitted to Linus. He does review code and often catches mistakes. In this case assignment was used in a condition. To good C programmers this is bad taste. I noticed that right off and I haven't written a line of C in about 6 years. Linus isn't just a good C programmer. After half a decade of watching him catch stuff like this in just his public LKML messages, I'm convinced he would have seen this if he were reading braille hardcopy of it from across the room while drunk.
    • Anybody point fingers at Microsoft yet? SCO?

      Now why would SCO backdoor their own code... because all your Linux is belongs to SCO.

  • by Mipsalawishus (674206) on Thursday November 06, 2003 @01:42AM (#7404325)
    This is the reason I trust open source software. The power of peer review (in one form or another) catches these kinds of things before they are sent into the wild.
    • Peer review did not catch this. This was detected because people injected code into a specific place where inconsistencies are complained about by the revision control software.

      Had this code come in through proper channels, I wouldn't be so sure that it would've been spotted. Most of the source code trojans people have found in the past were not well hidden, and were turned up relatively shortly. The cases I'm referring to are the trojaned configure scripts, that happened to, I believe, irssi and dsniff, o
      • Had this code come in through proper channels, I wouldn't be so sure that it would've been spotted.

        I doubt it, too. For example, in 1998, the CORE SDI put a backdoor into most SSH 1 implementations, which was included in their CRC32 attack decompensator. Of course, they didn't do it on purpose, but it happened nevertheless, and peer review didn't catch it.
  • !!! rag (Score:3, Funny)

    by VAXGeek (3443) on Thursday November 06, 2003 @01:42AM (#7404326) Homepage
    Imagine if this had sneaked into some Longhorn code right before shipping. Many eyes make few mistakes.
  • hmm (Score:4, Funny)

    by Anonymous Coward on Thursday November 06, 2003 @01:43AM (#7404333)
    Sounds like a plan to get the dirty GNU/hippies to upgrade to the real BitKeeper instead of using the communist CVS gateway.

    That McVoy is a smart one!

    Did you know his programmers need to feed their families and pay their mortgages? Very sad situation, I hope everybody buys 10-15 licenses ASAP.
  • by tomstdenis (446163) <tomstdenis@gmaiCHEETAHl.com minus cat> on Thursday November 06, 2003 @01:43AM (#7404344) Homepage
    Why not just establish a web-o-trust and sign patches?

    That way people who hack in won't be able to send in signed patches to the system [e.g. even if they physicially update the tree others can trivially spot the unsigned patches].

    That would of course, require people to actually think about security in terms of "oh sure people won't hack it because it hasn't been done...much...before."

    Tom
  • by nereid666 (533498) <spam@damia.net> on Thursday November 06, 2003 @01:47AM (#7404371) Homepage
    i want to know if the hack was a remote backdoor or "only" a local root compromise. In order to how bad was the hacker that try to do this.
    Thanks to the admins and developers that detect that!
  • Alright.... (Score:4, Funny)

    by aws4y (648874) on Thursday November 06, 2003 @01:55AM (#7404421) Homepage Journal
    I'll call ESR, he's got the guns.
    You guys get Linus and make sure he brings Tove, since she could probly kick all our asses.

    Once thats done we'll Larry McVoy, by this time hopefully he will have the IP of the slimeball.

    The Pose rides at Dawn, we can kill some Trolls along the way.
  • by dreadlord76 (562584) on Thursday November 06, 2003 @01:57AM (#7404433)
    Ok, so the scripts caught an attempt to install a back door. Everybody jumps up and down and sings the praise of the mighty Open Source Movement.

    What if a backdoor was installed last week, or last month, but was not caught?

    The fact that this was possible once, should really make people think about the possibility of it happened ALREADY, and determine if it is necessary to hunt through the code for a systematic review.

    Instead, all we get is Microsoft Bashing...
    Ugh
    • necessary to hunt through the code for a systematic review.

      At least we're allowed to if we wish...

    • The fact that this was possible once, should really make people think about the possibility of it happened ALREADY, and determine if it is necessary to hunt through the code for a systematic review.

      Instead, all we get is Microsoft Bashing...

      Yea - because we all know that as soon as this was discovered, all the kernel developers and assorted dabblers decided to spend all their time on Slashdot thinking up MS-bash jokes. Heck. Its amazing that ANY development is being done these days while Slashdot

    • There are three kinds of backdoors. There are those which are found right away and thus do no damage. There are those which ship and may cause damage but are eventually found. And there are those which ship and are never found.

      We can only ever know about the first two kinds, of course.

      Open Source software has had a few of the first kind, and this is one of them. It has had a very, very, very few of the second kind (the classic compiler backdoor is the only one I know of).

      Closed source software has had so
  • by Anonymous Coward on Thursday November 06, 2003 @01:58AM (#7404436)
    In my code I always put the constant on the lhs so that the difference between the equality (==) and assignment (=) operator are caught by the compiler by accident.

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

    In this case, it would make an attempted root hole more visible, as (0 = current->uid) would not compile.
    • In my code I always put the constant on the lhs so that the difference between the equality (==) and assignment (=) operator are caught by the compiler by accident.

      Good style.

      But this was apparently not an accident, but a deliberate attempt to disguise a trapdoor. As such the author would, of course, just "forget" to use that piece of defensive programming. B-)
  • The more eyes... (Score:3, Interesting)

    by Sean Clifford (322444) on Thursday November 06, 2003 @02:00AM (#7404453) Journal
    > Setting current->uid to zero when options __WCLONE and __WALL are set? The
    > retval is dead code because of the next line, but it looks like an attempt
    > to backdoor the kernel, does it not?

    It sure does. Note "current->uid = 0", not "current->uid == 0". Good eyes, I missed that. This function is sys_wait4() so by passing in __WCLONE|__WALL you are root. How nice.

    And this is exactly why folks should insist on open source code.

    Assuming it was noticed, and I have little reason to think that modification of a project's cvs tree would go unnoticed, a closed source product would have to go up and down the development chain of command. Then likely up and down the marketing chain of command while a decision was made whether to say anything about it (yeah, right) was made. Meetings would be held, blame would be assigned, and - oh yeah - a discussion about a fix would ensue.

    Perhaps I exaggerate, but only a little.

    I remember when a beta of a game [unnamed software publisher] was working on got ripped off our company ftp site and passed around. There was so much hype about our game that the leaked late beta was a serious disappointment and effectively killed the good buzz the marketing folks had whipped up. [It blew anyway, got shredded by the gaming rags, had a lot of potential but an inexperienced crew and very little financial support.]

    Of course, this situation is nothing like that.

    There's always going to be someone trying to backdoor the linux kernel, windows, osx, apps galore. Having the source on-hand to look at gives you that added level of confidence that "hey, worst case we can fix it - deal with it ourselves" rather than go through the denial, silence, lame excuse, patch cycle you go through with closed source products.

  • Ebay-style attacks (Score:3, Interesting)

    by blastedtokyo (540215) on Thursday November 06, 2003 @02:00AM (#7404454)
    While this attempt was thwarted, it makes you wonder though if someone could do an Ebay style 'attack.'

    In other words: 1) Work on the code for a long time, developing good features and build up virtual reputation points so that people trust you. 2) One day decide to insert your backdoor amidst some big checkin. 3) Disappear.

    It doesn't seem hard for someone to pay some random third world programmer to do this so. For example, if Red Hat had a guy in russia doing this they could, after the latest kernel was widely distributed, use it to attack Novell/SUSE.

    • Disappearing would only raise suspicion, not abate it. And it doesn't change the fact that this code gets reviewed a lot by a lot of different people. It would get noticed pretty quickly, methinks.

      Think about how often your own code gets reviewed, debugged, optimised - not necessarily by you, but by Joe Coder on the same project or Wilma Coder some time down the road.

      I doubt that someone sociopathic enough to work on something for years under a legitimate guise, then "one day" would be able to keep it

      • Re:disappear? (Score:2, Flamebait)

        by malakai (136531) *

        Disappearing would only raise suspicion, not abate it. And it doesn't change the fact that this code gets reviewed a lot by a lot of different people. It would get noticed pretty quickly, methinks.

        Ha ha ha hah. yeah, right, because in the opensource world people _rarely_ are given CVS access, do some work, and then dissapear into the void.

        While linux kernel may be more guarded, 98% of projects on sourceforge probably has people with CVS write access that are no longer active in the project. This is a hug

    • I sure hope your not suggesting Russia is a third world country. You must be American eh?
  • by nmoog (701216) on Thursday November 06, 2003 @02:28AM (#7404605) Homepage Journal
    Keep reading the thread - you'll read a bid of Linus, and a comforting explaination [iu.edu] of whats happenin' back there.
  • Trusting Trust (Score:5, Informative)

    by ceswiedler (165311) * <chris@swiedler.org> on Thursday November 06, 2003 @02:30AM (#7404617)
    The Ultimate Backdoor, if anyone hasn't read about it:

    Reflections on Trusting Trust [wbglinks.net].

    You might want to doublecheck that gcc code you're compiling the kernel with...
  • by temojen (678985) on Thursday November 06, 2003 @02:43AM (#7404676) Journal

    The "backdoor" that someone attempted to submit was a local privilege elevation bug, not a remote compromise.

  • by RouterSlayer (229806) on Thursday November 06, 2003 @03:29AM (#7404866)
    I see some people posting some negative replies, or lamenting on OSS process, etc and saying how it didnt work, or how a psuedo-trusted patch would get in, if it went through proper channels, or some such crap.

    this couldn't be further from the truth, you are all forgetting many things, #1 - the checking scripts run daily now, and Larry has mentioned he's going to step that up, still fixed within 24hrs is a damn good response time! closed-source could never be this fast.

    #2 - all this talk of peer review, saying it didn't catch this or whatever nonsense, yes in a way it did, and whats more it's exactly what will keep semi-valid attempts or those through "proper channels" out of the code. You forget, millions of people around the world review this stuff, and someone, somewhere will find it relatively quickly, and not just because all the good developers (which is most of the millions) really LIKE linux and do their utmost to protect it, and ensure that no twits do things like this.

    on the oft-side billions to one chance someone does something stupid like people said hire someone to do good patches for a long time, get trusted, and submit a patch with this kind of code in it, well, first of all, this is just stupid, it would take years to get that trusted from "zero", second, even assuming all that, the code would still get caught very quickly.

    Like I said, someone, somewhere is gonna notice real quick, because the millions of us out in the world really happen to LIKE linux, and protect the kernel most of all, and I'm sure as the code worked its way into the tree, one of the people would catch it, and I'd be willing to bet several would see it at the same moment, including Linus, et all.

    You simply can't pull a fast one over the great coders we have, these aren't your average coders, and remember, not just them, but all of us, really, in a way, put our heart and soul into supporting Linux, its a confidence we dont share lightly, the kernel is the most protected of it all, yes, for obvious reasons, its the most critical code.

    But even outside the kernel, remember millions of people around the world are reviewing code 24hrs a day, every day, and posting notes about issues, patches, etc.

    It's simply much harder to get by all that. Like I said, and I'll say it again, someone's gonna notice, and probably LONG before it even gets into the main BK tree, because even those reviewers ain't slouches!

    Closed source has a smaller review team, and I know for a fact internal developers add back-doors to code all the time. I know many closed-source coders (not necessarily personally) that as a matter of habit throw in back-doors into every piece of code they write, because they hate their job, and the people they work for, and hate the product. Since very few people ever review the code, things can sit there indefinately and never get found.

    remember this is a work of pride, something the community really cares about, we really want to see it succeed, and not have the issues like this, or that others have, we want to protect it at all costs, in any way, to ensure a good future, and protect the users out there.

    remember, we're users too! If it means that much to you, wouldn't you be checking it too? damn straight! This is exactly why the OSS model is so damn important,

    and its exactly why Microcrap, SCO, etc will never "get" it. I'd even add Intel to this list, because I think AMD is really "getting" it.

    summary - we like it, we care about it, and aint no way we gonna let some dork attempt to ruin something we've worked so damn hard to build, not just for ourselves, but for everyone, its a matter of pride.

    and yes, anyone found out (and they will be!) doing this shit is gonna get their ass kicked into next week...

  • by RichardX (457979) on Thursday November 06, 2003 @03:38AM (#7404910) Homepage
    Microsoft insists the timing of their bounty (pay deal) on (for) virus writers (hackers) [slashdot.org] "entirely coincidental" (damned convenient)
  • Anyone that thinks security is easy (apparently some people still do) really needs to read Ken Thompson's 1984 Turing Award Lecture "Reflections on Trusting Trust": http://www.acm.org/classics/sep95/ As Bruce Schneier says, security is a process, not a product.
  • by Rogerborg (306625) on Thursday November 06, 2003 @07:50AM (#7405677) Homepage
    Should end the old argument about which is better, the habitual, easy to read, but easy to screw up or abuse:

    if(variable == CONSTANT) { }

    Or the safe version that's so much harder to screw up and which turns out to be just as easy to read with practice:

    if(CONSTANT == variable) { }

    Do we all understand the real world significance of this now?

    If you still want to advocate (variable == CONSTANT), then please feel free to prove that no accidental or abusive (variable = CONSTANT) exist in the kernel.

"Only the hypocrite is really rotten to the core." -- Hannah Arendt.

Working...