OpenBSD Journal

y Patch 011: IPv6

Contributed by jose on from the MTU-problems dept.

From the security-announce list: 



Date: Sun, 8 Feb 2004 00:54:54 +0100
From: Daniel Hartmeier


To: security-announce@openbsd.org
Subject: IPv6 MTU handling problem

An IPv6 MTU handling problem has been reported by Georgi Guninski[1],
which could be used by an attacker to cause a denial of service attack
against hosts reachable through IPv6.

When the MTU (maximum transfer unit) for an IPv6 route is set very low,
the TCP stack will enter an endless recursion when the next TCP packet
is sent. This can be exploited remotely by sending ICMP6 'packet too
big' messages containing such low MTU values. The kernel will
effectively lock up, causing denial of service. It is not believed that
this problem can be used to execute arbitrary code.

IPv6 is enabled by default, but the problem can only be exploited
remotely against hosts which are reachable through IPv6. Hosts with
IPv4 connectivity only are not affected.

The problem is fixed in -current, patches for 3.4-stable and 3.3-stable
are available at

ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/common/011_ip6.patch

ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.3/common/016_ip6.patch


[1]
http://www.guninski.com/obsdmtu.html

(Comments are closed)

Comments

  1. By theCatInTheHat () cat@mole.com on none

    I am a troll and this is not a hole
    said the the fat cat looking through the net.
    The IP stack is all in tack and really that is the fact, he continued. You see for one to hack he would have to say IP6 and we all know he would be the one in a fix ;)

    Comments

    1. By Anonymous Coward () on

      Huh?

    2. By Anonymous Coward () on

      > The IP stack is all in tack and

      that's 'intact'... but you knew that, didn't you.

      Comments

      1. By Anonymous Coward () on

        that's 'intact'... but you knew that, didn't you.

        that's poetry... but you knew that, didn't you.

    3. By Anonymous Coward () on

      i reckon this guy should write the advisories.

      Comments

      1. By ssc () on

        >i reckon this guy should write the advisories.

        yeah, that would be kinda neat
        secure by poetry :)

  2. By David Coppa () caff@openbeer.it on http://www.openbeer.it/


    openbsd# sysctl -w net.inet.ip.mtudisc=1
    net.inet.ip.mtudisc: 0 -> 1

    openbsd# ifconfig rl0 mtu 64

    anothermachine$ ssh openbsd

    openbsd reboot.

    So, it's not only ipv6 related...

    Comments

    1. By Daniel Hartmeier () daniel@benzedrine.cx on mailto:daniel@benzedrine.cx

      Only through IPv6 a remote peer can set your MTU that low. For IPv4 (where you could try ICMP 'need to frag' errors), the stack already ignores MTU values sent by the peer lower than 296 octets.

      What you describe is a DoS only exploitable by the local root. It'll be eventually fixed, too. But if you got local root, there are a couple of other ways to take the host down intentionally (like, uh, halt(8)) ;)

  3. By Arrigo () on http://www.alchemistowl.org/arrigo

    I haven't been able to replicate it with OpenBSD 3.0 and the patch doesn't backport as it looks like a newer version of the KAME IPv6 stack was imported.

    Has anyone got a patch for older versions of OpenBSD ?

    Comments

    1. By Daniel Hartmeier () daniel@benzedrine.cx on mailto:daniel@benzedrine.cx

      I'm not sure 3.0 is vulnerable at all, you'd have to check that first (see Guninski's advisory for instructions). Backporting the proper ip_output6.c fix is probably harder for 3.0, as the KAME code has changed since then. There's a simpler fix for the problem, just ignore ICMP6 'packet too big' messages with MTU sys/netinet6/icmp6.c r1.78 , simple to backport. Again, for 3.3 and 3.4, the ip6_output.c patches are superior (RFC compliant), use this only when you can't apply the real patches.

      Comments

      1. By Arrigo () on http://www.alchemistowl.org/arrigo

        Sorry, I should have said: I tried the exploit against obsd 3.0 and it didn't work as in the machine is still up and running but this is one particular i386 box, the test is far from generic and the conditions were ideal (two systems on a local LAN).

        As I have no means to perform better testing I am wondering if the bug is still there, just not triggered so far.

        Comments

        1. By Daniel Hartmeier () daniel@benzedrine.cx on mailto:daniel@benzedrine.cx

          First ensure that your exploit is correct and working, by successfully crashing an unpatched 3.4-release, for instance.

          Then apply it to the 3.0 box, using the same procedure repeatedly, until you're sure it doesn't affect it. You can't really be sure, but if all you have at your disposal is empiric tests, that's as good as it gets.

          At some point, backporting patches to no longer supported releases (and 3.0 unsupported for quite a while, I'm sure you're aware of that) just isn't worth the effort anymore, and upgrading becomes cheaper.

          And since this is only relevant for IPv6 enabled hosts, and you mentioned one particular host only, I can't imagine a sane reason not to upgrade it. There must have been dozens of small IPv6 fixes and improvents during those years which never caused an errata, which you're missing.

          Comments

          1. By Arrigo () on http://www.alchemistowl.org/arrigo

            Sadly there is one good reason: the box is in a closet, with no serial console and approximately 2000km from where I am with nobody BSD-knowledgeable around. Hence I can't risk an upgrade.

            For the trolls: I appreciate that mine is a limit case but there are boxes which can't be upgraded, either because there are too many of them (e.g. large farm) or because you can't reboot the box and still have access to it if it doesn't work...

            Still, I've definitely tried a 3.4 brand new install from CD at home (which keels over) but haven't been able to reproduce with a 3.0. I feel uneasy about calling it "safe" so I'll leave the box running with IPv6-only traffic overnight to see if I have indeed touched something sensitive which breaks in the long run.

  4. By chas () on

    Is this the best source of binary patches for OpenBSD?

    Comments

    1. By Peter Hessler () spambox@theapt.org on http://www.theapt.org

      The best way is to make them yourself. Not talking trash about the openbsd.org.mx guys, but I don't know them. I don't trust them. (Then again, there are very few people I trust).

  5. By inglf00 () on

    as always ... /security.html is't up-to-date :-/

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.]