OpenBSD Journal

kernel exploits in the news

Contributed by jose on from the overflows? dept.

ronaldraymond writes:
"Any one aware of OpenBSD-Current's status in regards to these suggested exploits as noted on security wire:

*CERT WARNS OF POTENTIAL FOR TCP/IP EXPLOIT
CERT last week warned of exploits that may be circulating in the underground that could take advantage of vulnerabilities in the Linux, OpenBSD and FreeBSD implementations of TCP/IP. Without providing any additional details, CERT cautioned users to remain vigilant. "We are particularly concerned about these types of vulnerabilities because they have the potential to be exploited even if the target machine has no open ports," CERT says.

http://lists.netsys.com/pipermail/full-disclosure/2002-September/001667.html
http://lists.netsys.com/pipermail/full-disclosure/2002-September/001668.html
http://lists.netsys.com/pipermail/full-disclosure/2002-September/001664.html
http://lists.netsys.com/pipermail/full-disclosure/2002-September/001643.html "

Bear in mind that most of this is just speculation, but does anyone have any info to chare? CERT's not been terribly forthcoming. I already voiced my suspicions (check one of the links above). Thanks.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    Wouldn't surprise me if MS was behind all this, as a scare taktick.

    Comments

    1. By Anonymous Coward () on

      M$ uses the BSD TCP/IP stack.

      Comments

      1. By Anonymous Coward () on

        Not really. Windoze's stack was based on Spyglasses stack which was based on BSD. But that was a decade ago. I doubt their stack has much in common with the BSD's now.

      2. By Anonymous Coward () on

        Almost every TCP/IP-stack is derived from the BSD one.

      3. By Anonymous Coward () on

        I think that was Win98.

      4. By Anonymous Coward () on

        For those that don't believe me.. Just type "FTP"... Or "netstat", or "arp". It's pretty easy to see which programs have been taken directly from BSD... They are the only programs that use the "-" (dash) to seperate options, rather than the DOS/Windows standard "/" forward slash.

        Comments

        1. By Anonymous Coward () on

          That's great, because userland tools are related to the TCP/IP stack in so many ways.

          Comments

          1. By Anonymous Coward () on

            arp, netstat... Not what I would call 'userland tools' per se. They obviously can speak directly with the stack, and they are just slightly modified BSD tools...

            Comments

            1. By Too Lazy to get an Account () on

              I guess his point was that arp, netstat, et al, are _applications_, and the way they are coded to parse options is not necessarily related to the kernel-level TCP/IP stack. You can change these apps to parse options in any crazy way you want without impacting how they talk to the stack.

              Rule #1: correlation does not imply causation.

    2. By Dom De Vitto () dom-at-devitto.com@gov.uk. on mailto:dom-at-devitto.com@gov.uk.

      doh!

      Meanwhile some MS sales monkey emails a link to this site to his customer and, ch-ching!! that's another linux shop converted, and a tidy sales commission too.

    3. By Dom De Vitto () dom-at-devitto.com@gov.uk. on mailto:dom-at-devitto.com@gov.uk.

      like I said, until someone credible says otherwise.

      It just lucky that I trust Theo and Linus to actually tell folks the truth, poor of MS folk just get empty promises.

  2. By Anonymous Coward () on

    I suppose its POSSIBLE -- but I wouldent take it without a good portion of salt.

    Linux, FreeBSD, and OpenBSD's TCP stacks are quite different -- especially Linux -vs- BSD. And why isnt Solaris vulnerable? Why not NetBSD? NetBSD's TCP stack is _really_ close to OpenBSD's.

    Those "blackhat hackers" names sound fictional -- please tell me if you know otherwise, I'd be interested...

    Comments

    1. By Noryungi () n o r y u n g i @ y a h o o . c o m on http://www.noneofyourbusiness.com


      Yup.

      Seems strange that OpenBSD is affected and not NetBSD, given the fact these two were very closely related, not so long ago...

      On the other hand, NetBSD has released half a dozen security advisories in a couple of days -- but they seem to be un-related to this mysterious TCP/IP vulnerability.

      Personally, I still think it's nothing but rumors... until proven otherwise, with some serious evaluation of the problem.

      Comments

      1. By Gimlet () on

        I think it has to do with the facts that 1) Lots of people use Linux and FreeBSD and 2) a remote exploit in OpenBSD is a big deal.

        NetBSD is just not as visible than the other three, IMHO.

    2. By Anonymous Coward () on

      Where's OSX in that list? It's TCP/IP stack _is_ the FreeBSD stack.

  3. By SKULL () on


    Hmm, fourth hand rumors. Not much to work with.

  4. By Anonymous Coward () on

    This rumor could be true or it could be a hoax... but, one thing which would make security sense would be to remove tcp/ip from the kernel, and have it as a userland process. The kernel is running at the highest privilege state, and network input is the most untrusted input. This is not how it should be; the process which handles the most dangerous input should be at the lowest possible privilege level. I realize it would be a major change of things to get tcp/ip out of the kernel, and there could be some performance impact, but this would safer. In fact, it would be more secure if all the network stuff were taken out of the kernel.

    Comments

    1. By Anonymous Coward () on

      For apps to communicate then, you want them to talk directly to the "TCP Daemon"? Or should it go through the kernel and back to the "TCP Daemon"?

      Sorry, but IPC is about as trustable as leaving a dog alone in a house with a cat made entirely of bacon. You are creating a world of pain if you make a binary handle your TCP traffic -- not to mention that if TCP-work it's done between processes w/o kernel intervention, you are going to have to rewrite every network-enabled app in existance.

      This is only scratching the surface of the issues involved here.... AaH the headaches!

      Network code belongs in the kernel.

      Comments

      1. By Anonymous Coward () on

        How does the HURD handle networking then? I thought super modular kernels chunked everything off into its own existence.

        Comments

        1. By Anonymous Coward () on

          Yes, in the Hurd, tcp/ip is a plain old userland process. The Hurd is a very heavy user of ipc, but it has a different ipc model from Unix I think. I don't know how Unix ipc works so I can't comment on it. The cool thing about this is that you can have your up-and-running system, and if you want to try a totally different stack, you just kill the old one and start the new one, and you're set. Also if someone hacks into your stack, well, that's as far as he got. Of course it's still a serious intrusion because then he could presumably sniff all of the machine's network traffic, but that is still better than if he had gotten into the kernel.

          The Hurd is a very smart design, imho. I'm looking forward to someday being able to use it. I just got a new laptop with lots of cutting-edge features which aren't really support in Linux (or OpenBSD) yet so I have to muck around with compiling new kernels to get stuff to work. I was wondering to myself, "why should the mouse driver be in the kernel?" It makes no sense, but if you agree that the mouse driver shouldn't be there.... then a lot of things which are there shouldn't be there.

        2. By Anonymous Coward () on

          It is called a microkernel.

          Comments

          1. By Anonymous Coward () on

            plan9 does this and it's not a microkernel.

      2. By Anonymous Coward () on

        > as leaving a dog alone in a house with a cat made entirely of bacon.

        That must be quite a cat to be made entirely out of bacon.

        Comments

        1. By Gimlet () on

          >> as leaving a dog alone in a house with a cat made entirely of bacon.

          >That must be quite a cat to be made entirely out of bacon.

          Would that be a house made out of Milk Bones?

      3. By S/Kanker () on

        You propose OpenBSD should be using a microkernel? :) check the Hurd and Qnx

        Comments

        1. By Anonymous Coward () on

          hrrmm... that wouldn't be very "BSD", would it?

        2. By Anonymous Coward () on

          I'm not proposing that OpenBSD radically redesign itself... just pointing out a different design philosophy that has some advantages. I have noticed some shifts in OpenBSD's design philosophy over the past year. It has shifting from "squash all the bugs" to "separate privileges". Maybe it will stay there for a long time, or maybe a year from now OpenBSD (or some fork of it) will shift towards "isolate everything" and use a lot more fine-grained capabilities. Who knows. I'll keep monitoring progress of OpenBSD, EROS, the Hurd, TrustedBSD and probably some other things and I'll keep using the right one for the job.

  5. By W () on

    Maybe I'm just paranoid (no I'm not - yes I am - no I'm not - yes I am), but I believe there is an "underground community" that knows far more than "the overground community" and that they could strike almost anything. No, I'm not crazy (Yes I am - not I'm not - yes I am - no I'm not).

    I'm not kidding.

    Comments

    1. By ~el8 () on


      You're right: there's an underground world out there that doesn't release an advisory on bugtraq.

      Oh, that exploit is for true and works on Solaris, NetBSD, OpenBSD, FreeBSD, Linux 2.4 and Darwin.

      How could I say that ?
      Maybe because I wrote it ?

      Comments

      1. By W () on

        Maybe. And maybe I'm not paranoid; maybe I'm just realistic and everyone else naive.

        Comments

        1. By Anonymous Coward () on

          i agree

          Comments

          1. By W () on

            Really? :-)

            Comments

            1. By Anonymous Coward () on

              yes

              Comments

              1. By W () on

                Tell me more, cyperpal.

      2. By Free Bird () on

        Yep, sure you're the ~el8 guy. I suppose you'd just go to a random site and brag about your archievements...

        Yeah right.

        You're fake, and the same thing probably goes for those exploits.

        Oh, and BTW: Why isn't Linux 2.2 vulnerable?

      3. By Anonymous Coward () on

        lol ~el8, sure thing bud. How's your win98 boxen?

        Comments

        1. By W () on

          HEH HEH HEH HEH.

        2. By ~el8 () on


          No Win9X.

          WinXP/2000 are vulnerable because of the TCP/IP parts from FreeBSD.

          Comments

          1. By W () on

            It would be nice if you could prove that you know what you're talking about.

          2. By Free Bird () on

            Excuse me, but Win9X certainly has a BSD TCP/IP stack! Windows 2000, however, was said to have a "completely rewritten" (yeah, right) TCP/IP stack, but for some reason or another (namely that it was still the same) it behaved just like a BSD TCP/IP stack...

            IOW: You don't know what you're talking about!

            Comments

            1. By ~el8 () on


              -> http://info.iet.unipi.it/~luigi/

              "Some of my code apparently has also made it into Windows XP."

              Comments

              1. By Free Bird () on

                I know WinXP uses BSD code, however you said Win9X doesn't, which isn't true. You should've known that if this was all genuine.

                Comments

                1. By SUPERCOOLDUDE () on

                  OMGLOL! IS THERE A GOOD RECIPE FOR ONION SOUP YOU HAVE? I AM HUNGRY TONIGHTAND THW COMPUTERS WILL BE DOWN BLAH BLAH BLAH *bork*

      4. By Anonymous Coward () on

        Shouldn't you be doing your homework? Your mom is going to yell at you if she catches you playing on the computer again.

        Comments

        1. By W () on

          HEH HEH HEH HEH.
          HEH HEH HEH HEH.

        2. By W () on

          HEH HEH HEH HEH.
          HEH HEH HEH HEH.

    2. By RC () on

      As a former shady character, I'll field this one.

      What you are talking about is called 0day. But don't be fooled by your own paranoia... It's not that everything is exploitable, and it's not that you can't proactively protect yourself.

      I happen to remember a piece of (commerical) software that will kill & restart a service as soon as it acts badly, and ban the IP the cause it, for a configurable ammount of time. They ran software with known exploits, and still no-one could break-in. With some luck, someone managed to break in once, but that bug was fixed since.

      Can't recall the name or company, but I'd like to know if someone else does.

      Even if you don't buy the software, this example tells you exactly how to secure your machine... You run software with known exploit scripts available, and see if precautions you've put in place will negate any software exploits.

      My method would be at that point (where nothing short of a serious kernel bug could result in Root) if OpenBSD only had TCP/UDP port ACLs, so I could give certain (non-Root) users access only to certain ports. Until that gets added to the OpenBSD code base, I'll be running things like Tripwire, monitoring processes, and Root logins, so I'll at least know when someone does exploit services running as Root.

      I think, once TCP/UDP port ACLs are introduced, the security of any single piece of software won't even matter. (at least for myself, and whoever my current employer is :-) )

      Comments

      1. By Anonymous Coward () on

        if OpenBSD only had TCP/UDP port ACLs, so I could give certain (non-Root) users access only to certain ports.

        why not use nat and pf with user/group authentication?

        Comments

        1. By RC () on

          It's an additional piece of software in the loop.

          It adds quite a bit more overhead to every communication.

          There are several pieces of software that hard-code the port into the data.

      2. By W () on

        [QUOTE]I happen to remember a piece of (commerical) software that will kill & restart a service as soon as it acts badly, and ban the IP the cause it, for a configurable ammount of time. They ran software with known exploits, and still no-one could break-in. With some luck, someone managed to break in once, but that bug was fixed since.[/QUOTE]

        Cool. I'd like to get my hands on that one.

        Comments

        1. By Anonymous Coward () on

          Canīt systrace do that? Donīt know about banning the IP, maybe that could be accomplished?!

          []`s

          Comments

          1. By Anonymous Coward () on

            Canīt systrace do that? Donīt know about banning the IP, maybe that could be accomplished?!

            there's been talk about auto-generating deny rules in the past, generally w/ statements about the DoS potentials (someone spoofs ip of your important machines, like your workstation, and gets the firewall to block that, you're screwed).
            systrace can already log to syslog. you could have something parse syslog messages to block ips. whether this is feasible/realistic/appropriate will depend on your setup, otherwise a user running logger may really fuck you up.

            Comments

            1. By Jeroen () on

              Yep. PortSentry does that.

              But the future looks bright: IPv6

  6. By Dom De Vitto () dom-at-devitto.com@gov.uk. on mailto:dom-at-devitto.com@gov.uk.

    Firstly, technical analysis of the two code bases shows they are VERY different in just about every way. And exploit for one, being we're talking kernel overflows here, would be incompatible with even differently compiled kernels, let alone different OSes. period.

    Secondly just about everyone (since the ping-of-death days) has sent every concievable random illegal packet to various IP stacks to see what breaks.

    Thirdly, just because someone says that they have a mate, who stood next to a bloke on the train who knew a guy who said he woz a really e1it3 h4x0r and could break into any linux (*bsd, *ms, vax, bla, bla) box and delete it. c00l. I believe em, yea.

    Wot a load of bollox. And it was even posted to a full disclosure list WITHOUT ANY EVIDENCE OR EVEN VAUGE TECHNICAL DETAILS.
    Don't you think that's odd ???

    Last time that happened after a few weeks of scarmongering, posted, and then recalled press stories, before folks worked out that some MS sales guy is pissing himself laughing at us.....

  7. By Jedi/Sector One () j@pureftpd.org on http://www.pureftpd.org/

    Look at sys/netinet/ip_ipcomp.c . Because of a typo (ralen vs rblen), the buffer size check is broken. -current is still unfixed. Other little errors like that are fixed by this patch .

    Comments

    1. By Anonymous Coward () on

      I'm curious why hasn't this (and your other patches) been adopted by the developers? If they're good patches surely the core team would want to get them in ASAP.

    2. By Anonymous Coward () on

      Actually, ip_ipcomp.c was patched about a week ago.

      Comments

      1. By Jedi/Sector One () j@pureftpd.org on http://www.pureftpd.org

        Oh sorry. It would have been nice if people who submit bugs had some feedback once it has been fixed, though.

        Comments

        1. By Anonymous Coward () on

          Maybe it's because of your anti-spam not accepting emails ...

  8. By Walter Mitty () none on none

    Has anyone thought that it might be a problem with dhclient? This fits the description in the vague CERT notice (and the rumors I've heard).

    Comments

    1. By I Really Need to get an Account () on

      Well, DHCP is infinitely hackable, to be sure. The way most ISP implement it, anyway.

  9. By Anonymous Coward () on

    This is the biggest load I've ever seen in my life.

    * NO supporting facts
    * MY friend told me so
    * the last email in the list is OBVIOUSLY meant to mock all the others
    * The snippet that looks like a quote of a story about CERT isn't referenced and is probably crap.

    I can't believe this even showed up on the OpenBSD Journal page.

    This is sufficient for me to just stop reading this site altogether.

    Comments

    1. By Skull () on

      I agree, I would question the reasoning behind publishing this story.

      Comments

      1. By Anonymous Coward () on

        > the reasoning behind publishing this story

        mmm... To be more slashdot-like? To create "controversy" and add some "heat" to the usually slow and calm discussions?

        I don't know...

    2. By W () on

      Settle down, boys!

  10. By Sean () askshant@alloyant.com on mailto:askshant@alloyant.com

    This is most likely a hoax. It is rather interesting how do serious sources like CERT get involved, mentioning Bindview as well. When was the last time we saw a purely TCP/IP-based even-no-open-ports-needed vulnerability? Can't speak for other BSDs or other OSes but OpenBSD?!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]