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

 


Forgot your password?
Close
typodupeerror
×
Debian Software Linux

Kernel Exploit Cause Of Debian Compromise 673

Posted by simoniker from the slightly-disturbing dept.
mbanck writes "The cause of the recent Debian Project server compromise has been published by the Debian security team: 'Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space'. This issue has been fixed in 2.4.23. Thus, the Linux kernel compromise was not Debian specific."
This discussion has been archived. No new comments can be posted.

Kernel Exploit Cause Of Debian Compromise More

Kernel Exploit Cause Of Debian Compromise

Comments Filter:

  • A shift of focus (Score:5, Interesting)

    by chrysalis ( 50680 ) * on Monday December 01, 2003 @04:40PM (#7602876) Homepage
    It's fun to see how security research shifted from applications to kernels lately.

    • Re:A shift of focus (Score:5, Funny)

      by Anonymous Coward on Monday December 01, 2003 @05:00PM (#7603106)

      It's fun to see how security research shifted from applications to kernels lately.

      Fun!? You must be Klingon.

    • Re:A shift of focus (Score:5, Informative)

      by pclminion ( 145572 ) on Monday December 01, 2003 @05:02PM (#7603125)
      The "nice" thing about kernel exploits (from a cracker's perspective, of course), is that it doesn't matter what sort of userland software is running on the machine -- if you can get local access, by whatever means, it is very easy to boost yourself to root.

      Traditional local root exploits are all based on overflowing a setuid application or server. But if the box doesn't have any vulnerable apps installed, the attacker is SOL. However, if the kernel itself is exploitable, it no longer matters whether those setuid programs are present. All you need is to somehow acquire local access, and wham, you are root.

      To summarize, kernel exploits are very convenient for turning local user account compromises into full-blown root compromises.

      • Re:A shift of focus (Score:5, Funny)

        by Frymaster ( 171343 ) on Monday December 01, 2003 @05:25PM (#7603355) Homepage Journal
        what i want to know is...

        does this code belong to sco?

      • Re:A shift of focus (Score:5, Interesting)

        by GlassHeart ( 579618 ) on Monday December 01, 2003 @05:46PM (#7603606) Journal
        The "nice" thing about kernel exploits (from a cracker's perspective, of course), is that it doesn't matter what sort of userland software is running on the machine -- if you can get local access, by whatever means, it is very easy to boost yourself to root.

        We should point out that you're talking about common kernels like Linux today, not that this must apply to any OS kernel. For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries. The cracker's problem then becomes how to get an existing userland program (compiled by the trusted administrator) to issue the kernel call that results in the exploit, which is a much harder problem. A program may not ever make that system call, or may check its input so that you can't make it do the system call with (presumably) invalid parameters. In most cases, I expect that this means you have to insert a backdoor into a common program and wait for the trusted administrator to compile it for you.

        This sort of security is probably overkill and too tedious for a desktop box, but not unreasonable for a server which should only have a few programs installed and running anyway.

        • Re:A shift of focus (Score:5, Funny)

          by Sloppy ( 14984 ) * on Monday December 01, 2003 @05:56PM (#7603734) Homepage Journal
          That's why all the smart admins have been migrating their servers over to the best platform for the job: XBox.

        • Re:A shift of focus (Score:3, Interesting)

          by Querty ( 1128 )
          That's a silly reason for plugging DRM. Simply mount all user-writable space with option "noexec" and you have the same level of security.

          The reason this isn't done more often, is that it's a bit of a hassle for the power users.

          • Re:A shift of focus (Score:5, Informative)

            by John Whitley ( 6067 ) on Monday December 01, 2003 @06:16PM (#7603966) Homepage
            That's a silly reason for plugging DRM. Simply mount all user-writable space with option "noexec" and you have the same level of security.


            Life is more complicated than that. Regular binaries can be run as: /lib/ld-linux.so /noexeced_path/myprog

            Even locking this out, any available program that is itself an interpreter (e.g. Perl, etc.) can be used to run code. Assume that any attacker (or their scripts) know this and will leverage it.

            I'm seriously beginning to think that we won't be able to achieve secure systems that reliably push the security problem to the social boundary until ground-up designs such as the Extremely Reliable Operating System [eros-os.org] mature.
          • That's a silly reason for plugging DRM.

            Sorry, I must have been vague, although some responses have grasped the main point of what I'm talking about.

            The binaries are signed by the local root user (preferably on a separate box), at install time. The public key is installed in the kernel. This is about the root user preventing the box from running anything he did not install, not for the program's copyright owner or whoever else to control if it can run. As you can see, this has little to do with DRM, wh

        • Re:A shift of focus (Score:4, Insightful)

          by anthonyrcalgary ( 622205 ) on Monday December 01, 2003 @06:52PM (#7604332)
          With Linux Desktops being most popular in corporate settings, it's going to start being targetted by professional black hats, if it's not already. Security is a concern, even local exploits.

          A desktop system is exposed to tons of potentially hostile data. Strings are like acid, and a complex language like HTML is just asking for trouble.

          Don't get me wrong, OpenBSD is waaay into diminishing returns territory as far as security goes, but there's a few things that could be done to get 90% of the benefits, eg propolice in the kernel and W^X.

        • Re:A shift of focus (Score:4, Interesting)

          by BokLM ( 550487 ) <boklm@mars-attacks.org> on Monday December 01, 2003 @06:57PM (#7604397) Homepage Journal
          For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries.

          It's also possible to use SELinux [nsa.gov]. With this module you can in details give permissions to any object in the system. A web server would not be able for example to run /bin/sh ... it would be blocked by the kernel. It's also possible to tell what syscalls are allowed for a program.

        • Re:A shift of focus (Score:3, Interesting)

          by davecb ( 6526 ) *
          It may be overkill for some very small boxes, but a good barrier between my web server and my work account is not to be sneezed at.

          In a life long ago, I used a Multics system which was running AIM, the kind of military-grade security that's in NSA's Linux, and couldn't even tell it was in place. The sysadmins could, but us developers only saw the usual group-like facilities.

          This is prefectly reasonable for a machine that's hosting my current personal projects along with my homework (;-))

          --dave (DRBr

  • Shows the dangers of C (Score:4, Funny)

    by Anonymous Coward on Monday December 01, 2003 @04:42PM (#7602897)
    If the kernel was coded in visual basic, this wouldn't be happening.

  • what kind of person... (Score:5, Funny)

    by potpie ( 706881 ) on Monday December 01, 2003 @04:43PM (#7602906) Journal
    What kind of person spends that much time trying to find exploits in operating system kernels? Likewise, why do I spend so much time on www.thinkgeek.com/fortune.shtml? We are a sad people.

    • Re:what kind of person... (Score:4, Informative)

      by Smallpond ( 221300 ) on Monday December 01, 2003 @05:02PM (#7603123) Homepage Journal
      What kind of person?
      spammers [bbc.co.uk]

      People who expect to make money by hacking systems and using them to send millions of unsolicited emails.

    • Re:what kind of person... (Score:5, Informative)

      by ashridah ( 72567 ) on Monday December 01, 2003 @05:22PM (#7603325)
      The kind who only has to read through LKML to realise that a potential root bug was discovered in september, but wasn't fixed in 2.4.22, and doesn't appear to have been backported to the kernel?

      ashridah

    • Re:what kind of person... (Score:5, Insightful)

      by noda132 ( 531521 ) on Monday December 01, 2003 @06:01PM (#7603784) Homepage

      What kind of person spends that much time trying to find exploits in operating system kernels?

      The kernel developers, i.e., Andrew Morton. Good for him, too.

      There *was* a patch before the Debian systems were compromised. Hopefully in the future these things will be given more attention before they blow up.

  • Userland exploits (Score:5, Funny)

    by Hayzeus ( 596826 ) on Monday December 01, 2003 @04:44PM (#7602923) Homepage
    The evidence mounts: users should be eliminated.

  • Hurray for the Debian Security Team! (Score:3, Informative)

    by pegr ( 46683 ) * on Monday December 01, 2003 @04:44PM (#7602925) Homepage Journal
    And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?)

    Hats off to the Debian Security Team.

    • Re:Hurray for the Debian Security Team! (Score:4, Insightful)

      by __past__ ( 542467 ) on Monday December 01, 2003 @04:50PM (#7602978)
      Hats off to the Debian Security Team.
      And to the RedHat and SuSE security teams for helping them to track it down. In other words, hats off to the whole Free Software Community for collaborating when desaster strikes.
    • actually, the exploit was known (found by andrew morton) but didn't make it to 2.4.22 in time. RTA

    • Re:Hurray for the Debian Security Team! (Score:5, Informative)

      by Troed ( 102527 ) on Monday December 01, 2003 @04:50PM (#7602992) Homepage Journal
      The bug had been found by Andrew Morton before, and was already fixed in 2.4.23. Thus, it wasn't unknown. It might even the because it was known that it was exploited aswell, I assume.

      Quoting the Bugtraq post:

      This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
    • And thus, a previously unknown kernel exploit is discovered and patched! (Now how many more exist?) Hats off to the Debian Security Team.

      from the article: "This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release." Good work by the Debian team in catching it before REAL problems ensued.
      Hats off to Redhat and SuSe for reversing the code.
  • Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space'. This issue has been fixed in 2.4.23. Thus, the Linux kernel compromise was not Debian specific

    That still doesn't get you into the box; you still need to run something in userspace- and thus I think claiming(based solely upon the evidence presented in the /. story) that the compromise was not Debian specific to be premature. Has it been established how access was obtained into the

    • I believe an earlier article said that it appeared that he sniffed a password to the box.

    • RTFA (Score:5, Informative)

      by Stradenko ( 160417 ) on Monday December 01, 2003 @04:47PM (#7602954) Homepage

      Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.

      This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and 2.6.0-test6 kernel tree. For Debian it has been fixed in version 2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and version 2.4.18-11 of the alpha kernel images.

  • Will redhat provide an rpm??? (Score:5, Interesting)

    by cybrthng ( 22291 ) on Monday December 01, 2003 @04:49PM (#7602971) Homepage Journal
    Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.

    • Just wondering if they will still support us lowly 7.3 and 8.0 users anymore with a fix for this.

      Red Hat is supporting [redhat.com] these releases until the end of this year, so I'd expect them to.

    • Not yet (Score:5, Interesting)

      by dmeranda ( 120061 ) on Monday December 01, 2003 @05:42PM (#7603569) Homepage

      I just checked the current Red Hat 9 kernel source RPM and it does not have the patch yet [kernel-2.4.20-20.9.src.rpm]. I would expect a new kernel to show up soon though....I hope. The supposed patch which fixed this was in do_brk() [a /. comment further down provides the bk url]

      --- 1.31/mm/mmap.c Fri Sep 12 06:44:06 2003
      +++ 1.32/mm/mmap.c Thu Oct 2 01:18:19 2003
      @@ -1041,6 +1041,9 @@
      if (!len)
      return addr;

      + if ((addr + len) > TASK_SIZE || (addr + len) < addr)
      + return -EINVAL;
      +
      /*
      * mlock MCL_FUTURE?
      */

  • So it sounds like.... (Score:5, Informative)

    by satyap ( 670137 ) on Monday December 01, 2003 @04:50PM (#7602977)
    So it sounds like someone used a compromised user account to get in, ran a binary that exploited the bug, and got root that way. This is a local exploit, then.

  • Time for better security. (Score:5, Insightful)

    by Sheetrock ( 152993 ) on Monday December 01, 2003 @04:50PM (#7602981) Homepage Journal
    It's obvious that with the gradual acceptance of Linux by the business community, it's time for a stricter security model to be adopted. While OpenBSD has not shared in the commercial success of Linux, it does have one area of technical superiority: its security review process has yet to permit a remote root compromise in a standard install.

    Linux is a compelling choice in the Free Software world because of its pace of development and wide availability of software. However, it is this strength that is becoming a weakness. Perhaps it is time to slow down and review with more vigor to mimic the accomplishment of OpenBSD.

    • [OpenBSD's] security review process has yet to permit a remote root compromise in a standard install.


      Strictly true, but there has been one remote hole and many local root holes. Remote hole + local root hole = remote root hole.

      I'm not denying OpenBSD's superiority, but its security record isn't that much better than that of the other BSDs.

    • Re:Time for better security. (Score:5, Interesting)

      by chrysalis ( 50680 ) * on Monday December 01, 2003 @05:08PM (#7603192) Homepage
      Well... yes... and no.

      The strength of OpenBSD is that people continously audit the code and implement preventive stuff like privilege separation to reduce the risks in case of a vulnerability.

      On the other hand, the code of BSD kernels is a real mess. Some parts are really tricky, with glue between historic and new code and a lot of ugly, possible unsafe macros everywhere. The Linux kernel framework is way cleaner and more robust. When something goes wrong in a kernel thread, it can almost always properly recover and not just go to panic().

      And Linux has also some barriers like SELinux that theorically renders uncommon situations not exploitable. Theorically, because there can still be bugs in SELinux or other parts of the kernel that would bypass it.

      The "barriers" approach, although described as useless by some people is, in a real world, very efficient. Grsecurity (or recent OpenBSD with PaX and co) and SELinux make it very difficult to write reliable exploits. Still if an exploit would work, it will only work after having filled gigabytes of log files, giving a change to system administrators to take an action on time.

      The cons of the "barriers" approach is that it cures the implications of a problem, not the cause. The bug is still there, but instead of being exploitable to execute arbitrary code, it crashes the process (eventually immediately restarted with a tool like Monit or Supervise).

      The OpenBSD auditing approach aims at curing the bug itself, thus not causing any crash.

      Both approaches are actually complementary, but still not 100% efficient.

      The only way to make reliable and secure (even from a theoric point of view) is to prove the code. Unfortunately it's not a trivial task and it can't be made upon an existing unix-like base.

      But if you never heard about it, have a look at the very promizing EROS Project :
      http://www.eros-os.org/

      • And Linux has also some barriers like SELinux that theorically renders uncommon situations not exploitable. Theorically, because there can still be bugs in SELinux or other parts of the kernel that would bypass it.

        And in this case, SELinux wouldn't have helped, because the bug let user space programs into the kernel's memory space, and once that happens all bets are off, much like what would happen if any program could write to /dev/kmem.

      • I think BSD is better written... (Score:4, Interesting)

        by bluGill ( 862 ) on Monday December 01, 2003 @08:18PM (#7605024)

        Having looking at both sources for linux and BSD, I think that BSD is better written in total. That isn't to say that there are no ugly parts in BSD, or no nicer parts in linux, just as a whole BSD is nicer.

        To save you some time I present the next 3 replys to this post.

        Is not
        Is too
        Is Not

    • Re:Time for better security. (Score:5, Informative)

      by bahamat ( 187909 ) on Monday December 01, 2003 @05:09PM (#7603198) Homepage
      I don't mean to burst your bubble, bash Theo or OpenBSD, but I read Bugtraq daily, and I can't count the number of exploitable bugs reported in the OpenBSD kernel over the past few weeks, but it would probably take both hands and at least one foot. Linux however, iirc, had somewhere about 3. Given this info, I wouldn't be so hot to boast about OpenBSD's QA process.

      I repeat, I'm not trying to bash OpenBSD. Just trying to bring a little balance to the arguement. OpenBSD is an excellent choice for an operating system, but it's designed by humans. Humans make mistakes.

      The real flaw in what happened with this exploit is that there were no backport patches created. When the ptrace vuln came out I was able to patch my 2.4.19 and 2.4.20 systems right away, I didn't have to wait for the next release to come out in order to get a working fix.

      This should trun into a plea to the developers, if a bug is discovered through the normal course of development that is potentially serious enough for older kernels, it should be brought out into the open and the fix backported.

      • Re:Time for better security. (Score:4, Funny)

        by Pflipp ( 130638 ) on Monday December 01, 2003 @06:28PM (#7604089)
        bash Theo

        Never EVER put these words together. It's like keeping the Bible next to the Koran. You'll never know just when they will auto-ignite!
      • Your very own argument has a big fat hole through it. You are counting bugs which have been found. OpenBSD is subject to ongoing proactive review. Linux, on the other hand, primarily approaches security through "whoops, I just got rooted, here's a patch" or "I noticed this thing while I was working on this other thing, accidentally." Given the two different styles of code review, the fact that the OpenBSD team found more potentially exploitable bugs does not mean that OpenBSD has more of them. It doesn't me

      • Re:Time for better security. (Score:4, Insightful)

        by Homology ( 639438 ) on Tuesday December 02, 2003 @01:52AM (#7606983)
        don't mean to burst your bubble, bash Theo or OpenBSD, but I read Bugtraq daily, and I can't count the number of exploitable bugs reported in the OpenBSD kernel over the past few weeks, but it would probably take both hands and at least one foot.

        You appearantly don't pay much attention to what your read then, since for OpenBSD 3.4 there are two security fixes. One local and one remote denial of service. One of the security fixes are only relevant for i386.

        http://openbsd.org/errata.html

    • Re:Time for better security. (Score:5, Interesting)

      by jemfinch ( 94833 ) on Monday December 01, 2003 @05:17PM (#7603281) Homepage
      While OpenBSD has not shared in the commercial success of Linux, it does have one area of technical superiority: its security review process has yet to permit a remote root compromise in a standard install.

      You know, when I install a computer, I consider the "install" to be the files installed on my hard drive. "/bin/ls" is part of the "install." "/sbin/ifconfig" is part of the "install." "/usr/libexec/ftpd" is part of the "install."

      Apparently, however, the OpenBSD developers disagree. Something has to actually be running to be part of the "install." Thus, by their definition, none of those programs are part of the "install."

      Good thing, too. Because /usr/libexec/ftpd has sure as hell [openbsd.net] had a remotely-exploitable root hole.

      Jeremy

    • Re:Time for better security. (Score:4, Insightful)

      by wirelessbuzzers ( 552513 ) on Monday December 01, 2003 @05:21PM (#7603315)
      While I agree with your point, OpenBSD's numbers are a bit skewed. For one thing, there has been one remote root compromise, not none.

      Second, that "standard install" has most of the features turned off... No Apache, etc... I don't even know if SSHD is on by default. I mean, they could have zero remote root compromises if their standard install didn't include network drivers.

      I know that OpenBSD can't possible comb every line of apache and all the other contrib software ten times over, but this would be a problem for the Debian folks too.

  • The kernel patch... (Score:5, Informative)

    by lurp ( 124527 ) on Monday December 01, 2003 @04:57PM (#7603064)
    Here's the kernel patch that fixed the overflow in brk():
    http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mm ap.c@1.32?nav=cset@1.1148.2.2 [bkbits.net].

    The patch is from 9 weeks ago... I wonder if the exploit writer got the idea from looking at the kernel changelog...

  • There goes my Saturday (Score:5, Funny)

    by mariox19 ( 632969 ) on Monday December 01, 2003 @04:59PM (#7603100)

    I had just convinced myself there was no compelling reason to upgrade my kernel from 2.4.22.

    Actually, there still isn't, since the likelihood of my machine "coming under attack" is slight. But, what's the point of running Linux if you're not going to get all worked up over things like this ;-)

    Happy make menuconfig to all!

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Monday December 01, 2003 @05:00PM (#7603109)
    Comment removed based on user account deletion

    • Re:so are other distros possible infected? (Score:5, Informative)

      by Nothinman ( 22765 ) on Monday December 01, 2003 @05:18PM (#7603296)
      This is a local exploit, it can't be used until you have a shell. Debian had the misfortune of having a developer's password stolen and used to get a shell, other distros would have to have similar problems with either passwords or network accessable services.

      This isn't a special situation, everyone should be checking the integrity of their servers periodically anyway.

  • red hat and SUSE to the rescue (Score:3, Insightful)

    by 2057 ( 600541 ) on Monday December 01, 2003 @05:06PM (#7603168) Homepage Journal
    it seems everyones favorite whipping boys did alot of work in finding and fixing this bug. AND THEY SHARED THE INFO, who says corporate linux is evil now!@

  • The real question remains.... (Score:4, Interesting)

    by RedHat Rocky ( 94208 ) on Monday December 01, 2003 @05:14PM (#7603254)
    Any word on the parties behind the attack?

    The question remains, who is targetting Open Source? With this being the latest in several high-profile attacks, the evidence would suggest a determined effort is under way to put egg on the Open Source face.

    Who? Why?

    • Um, no (Score:4, Insightful)

      by Overly Critical Guy ( 663429 ) on Monday December 01, 2003 @05:39PM (#7603526)
      You know, people hack things. Kiddies hack servers.

      Why does it always have to be a "determined effort" against Open Source? Honestly...how paranoid do you have to be to think that? You do realize a lot of idiot kiddie (and professional) hackers are aware of Linux.

      Let me put your underlying implication to rest--no, it wasn't Microsoft. No reason to believe such. It was just some idiot hacker, like it always is.

  • Up 107 days... (Score:5, Funny)

    by jehreg ( 120485 ) on Monday December 01, 2003 @05:21PM (#7603318) Homepage
    kc grub # uptime 17:21:06 up 107 days, 22:45, 1 user, load average: 0.35, 0.82, 0.47

    Great..... there goes my uptime.....

    If I have to reboot more than once per year, I'm switching to Windows.

  • Mysteries of good system administration (Score:5, Interesting)

    by Pflipp ( 130638 ) on Monday December 01, 2003 @05:59PM (#7603763)
    What I find intriguing is that those fine folks at Debian have come this far at detecting the exploit and tracking down the who's and why's (with the who's still being left undecided for the public, anyway).

    Honestly, if I were smart enough to sniff a password, I'd also be smart enough not to let anyone know I've sniffed. Still, the folks at Debian were able to blame the unpriviledged account part on a sniffed password. Now how do you gain evidence for something like that?

    Likewise, if I'd be smart enough to gain local root access by flipping the kernel, I would also be smart enough to ditch the binary with which I did that. Nevertheless, though after a thorough research, the Debian team has found the binary and managed to understand its potentials.

    But still, what intrigues me the most is that they have found out that they were hijacked in the first place. Now I have a rock solid system for that at home, which is an 8 Mb RAM Sparc Classic, which starts to trash so hard at the least of activity, that I would well be alarmed if someone else than me was using that machine for whatever purposes. But as I may assume that those Debian machines weren't that low-end, how could you ever expect to know when you have been exploited?

  • What release did it APPEAR? (Score:3, Interesting)

    by whoever57 ( 658626 ) on Monday December 01, 2003 @09:00PM (#7605311) Journal
    What about 2.2.x series kernels, is there a similar patch?

  • How to decrypt a burneye encrypted exploit? (Score:3, Interesting)

    by TimFreeman ( 466789 ) <tim@fungible.com> on Monday December 01, 2003 @09:23PM (#7605449) Homepage
    The article saith:
    Forensics revealed a
    burneye [scene.at] encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit.
    Does anyone have an idea how he managed to do that? The only approach I can imagine is a dictionary attack.

    Here [securiteam.com] is a tool that may have been used.

  • Proof-of-concept exploit code (Score:3, Informative)

    by devine10 ( 661094 ) on Monday December 01, 2003 @09:27PM (#7605468)

    Grab it here [linuxfromscratch.org]

  • For the Security ANAL. (Score:3, Interesting)

    by 1lus10n ( 586635 ) on Monday December 01, 2003 @09:50PM (#7605639) Journal
    Say it with me ....

    There is no such thing as Utopian security. IF your hooked in your vulnerable. period.

    I don't know why people make such a big deal out of security for computers. Think about it. In real life things aren't very secure, I could break into most homes and steal things, or break things if i wanted to. but I don't. Why ? the threat of punishment, and not-so-common sense.

    If your a person who has deviant desires why wouldn't you break into a house ? VISIBLE security that would make punishment (ie jail) more likely would be the major reason. its not that the house is burglar proof, its that society has come to deal with criminals in the most effective way possible, and it doesn't usually hinder the average person. I think this is what we are lacking with computers, a clear cut enforcer. a "police" type body that could enforce laws such as "cracking and entering". and programs similar to an ADT-type of alarm system. We need a real solution. and Utopian code is not it. and making absurd laws are not it either.

  • Learning from your mistakes (Score:3, Insightful)

    by Walles ( 99143 ) <johan.walles@noSpAm.gmail.com> on Tuesday December 02, 2003 @03:38AM (#7607287)
    The question that should be asked now is:

    Imagine there is a buffer overflow in the kernel's brk() implementation that nobody knows about. What kind of security measures (other than finding the bug and fixing it) could prevent that buffer overflow from being exploited by an attacker?

    When that question has been answered, go implement the answer, and this won't happen again.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close