Slashdot Mirror

← Back to Stories (view on slashdot.org)

Remotely Crash OpenBSD

Posted by CowboyNeal on from the even-the-best-of-us dept.

*no comment* writes "If you are running OpenBSD on your IPv6 install, it might be time to upgrade to -current. (just kidding) There is, however, a way to crash OpenBSD 3.4 with a couple of simple IPv6 commands. Georgi Guninski, found the problem. To quote Theo, 'it is just a crash.'" It is unknown if the bug could be used to execute arbitrary code, but it does require patching a Linux kernel (or rolling your own network stack) to exploit.

7 of 407 comments (clear)

  1. Does this count? by DNAspark99 · · Score: 5, Interesting

    Or can OpenBSD still boast "Only one remote hole in the default install, in more than 7 years!" ?

    --

    --
    Society has traditionally always tried to find scapegoats for its problems. Well, here I am.
    1. Re:Does this count? by Richard_at_work · · Score: 5, Interesting

      IPv6 is available in the base install, but you have to actually have an IPv6 address assigned that people can get to to exploit this issue. Its really a non issue for the 99% of people running OpenBSD out there, but for some, like myself, its time to upgrade.

  2. Patch for production systems? by agentZ · · Score: 5, Interesting

    I know that the problem has been fixed in -current, but I run a production box that I refuse to bring up to -current. There's no patch or even a mention of this problem on the errata page.

    What's a sane admin to do?

    1. Re:Patch for production systems? by Ryvar · · Score: 4, Interesting

      Do what I did last night before I even knew about this - comment IPV6 completely out of your kernel entirely for effiency's sake.

      One of the reasons OpenBSD tends to be more secure is because it ships with *almost* everything off. However, there's a solid 10+ default user accounts, 3-4 default services (sshd, sendmail, inetd/portmap), and 75+ kernal/device options you should remove/recompile out upon installation (this is all assuming your only purpose is to create an x86-based router).

      Yes, you'll need to muck about with /etc/mtree/special and /var/cron/tabs a bit to keep everything from whining to syslog constantly, but every unnecessary thing removed is a potential exploit avoided.

      --Ryv

    2. Re:Patch for production systems? by Ryvar · · Score: 3, Interesting

      Smart.

      If I setup the system for mail - which I don't do for a simple firewall - I also use Postfix. Only other alternative is qmail and DJB's stuff is just too much of a PITA/non-standard.

      --Ryv

  3. about ipv6 by MrLint · · Score: 4, Interesting

    Not log ago there was an article about not only how ipv6 isnt needed, but that since its 'new' code, it has a lot of problems that have long since been worked out of ipv4. Is this an example of that? Should we worry?

    I have to ask myself that with all of the decades of experience that has gone into ipv4 development and hacking and exploiting, are these fears justified? Have all the glitches in ipv4 been found? and if so isnt it trivial to avoid the same early mistakes in ipv6. Does this particular problem have a ipv4 analog? Is it even a stack theory issue? Is it just an implementation oversight?

    Does anyone have any insight?

  4. Re:Oh well... by kl76 · · Score: 4, Interesting

    Who the heck is Spyder Inc? The TCP/IP stack in NT 3.1 was the STREAMS-based SpiderTCP 6 (IIRC) from Spider Systems Ltd. (I used to work for them). This in turn used some BSD code. This stack was replaced in NT 3.5, with a stack alledgedly written from scratch at Microsoft according to this .