OpenBSD Journal

Security Fix - All architectures

Contributed by deanna on from the with prejudice dept.

Marc Balmer (mbalmer@) writes:

IPv6 routing headers are a type of 'super source routing', and pose a significant and serious risk to hosts and the internet. That this host-controlled routing even came into existence once again shows how broken the IETF process is. Disable this source routing, with prejudice.

More info about the issue may be found in this set of slides presented by Philippe Biondi and Arnaud Ebalard last week at CanSecWest.

Source code patches are available for OpenBSD 4.0 and 3.9.

(Comments are closed)

Comments

  1. By Anonymous Coward (207.59.237.99) on

    We've known each other for a few years, and gotten pretty close in that time.

    Thus, it is with the best wishes and a heavy heart that I need to talk to you about your current relationship.

    Sure, your Engineering Task Force comes highly recommended, and has an impressive list of credentials. But, Internet, it's obvious that this relationship has been disastrous, leaving you insecure and in need of constant reinforcement in order to just hold yourself together.

    I love you, and you're better than that. I've SEEN you better than that. You need to find it within yourself to be the best internet you can be.

    Thanks for all the porn,

    - User

    Comments

    1. By Anonymous Coward (87.14.172.139) on

      Dude, you rock. That's just awesome.

  2. By Anonymous Coward (204.9.40.20) on

    What new security problems are present in the IPv6 routing header type 0 that were not already present in the IP LSRR and SSRR options?

    Comments

    1. By Igor Sobrado (sobrado) on

      > What new security problems are present in the IPv6 routing header type 0 that were not already present in the IP LSRR and SSRR options?

      The IPv6 type 0 routing header is comparable to IPv4 source routing but it *must* be processed by all nodes (not only by routers); that is the way the routing header has been defined and standardized. So, at least ingress and (conceivably) egress filtering is required to assure security. IPv4's loose and strict source routing must be done in multi-homed intermediate systems, so nodes and firewalls are usually not participating in LSRR and SSRR. The former opens a lot of ways to circumvent security.

      Sadly, the IPv6 type 2 routing header is not very secure either; it is required for MIPv6, a good approach to mobility. Up to my knowledge, IPv6 type 1 routing header never abandoned its experimental status.

      Comments

      1. By Anonymous Coward (204.9.40.20) on

        > > What new security problems are present in the IPv6 routing header type 0 that were not already present in the IP LSRR and SSRR options?
        >
        > The IPv6 type 0 routing header is comparable to IPv4 source routing but it *must* be processed by all nodes (not only by routers); that is the way the routing header has been defined and standardized. So, at least ingress and (conceivably) egress filtering is required to assure security. IPv4's loose and strict source routing must be done in multi-homed intermediate systems, so nodes and firewalls are usually not participating in LSRR and SSRR. The former opens a lot of ways to circumvent security.

        I read 791 to also require IP LSRR and SSRR to be processed by any implementations that claim to be compliant with 791, there's no distinction between host and router in the standard. 1123 doesn't say anything either way.

        If memory serves, BSD had a bad history with LSRR and SSRR, originally being supported always and without a knob to disable it. We got burned, we learned, and now there are knobs, off by default.

  3. By Cobalt (70.162.93.223) on

    I assume 4.1 is affected as well. Or will ftp-release be different than cd release?

    Comments

    1. By Matthew R. Dempsky (15.227.137.70) on

      4.1-RELEASE will be affected, 4.1-STABLE will have the fix once 4.1 is actually released. The files on the CD and that will be on the FTP mirrors are 4.1-RELEASE.

  4. By Rod Whitworth (yendor) rego@witworx.com on

    The problems with IPv6 are more numerous than the linked presentation shows. Last years Ruxcon (Sydney Australia) had a presentation by Mark Dowd which dealt with several "issues". It can be downloaded from HERE

  5. By Janos Mohacsi (194.67.205.95) on

    Your comment is rather unaligned. The problems of routing header type 0 well know by the community since long time. This has been documented for more than 2-3 years know (raised 4 years ago) The IETF process is different from the process what leader type of organisation - like OpenBSD: the leader say something, and everybody is nodding without questioning. IETF is based on consensus. Based on the consensus on IETF the type 0 routing header is not deprecated, but documented to be filtered if there is no need for it. The current patch provided by OpenBSD community makes OpenBSD IPv6 implemenation non-conformant to standard. I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. This is currently clearly not enough....

    Comments

    1. By art (84.79.228.107) on

      > Based on the consensus on IETF the type 0 routing header is not deprecated

      consensus is bullshit. It depends on how you ask the question. Simple example:
      - Should we remove the X header from the standard? No, because there is no consensus to remove it.
      - Should we keep the X header in the standard? No, because there is no consensus to keep it.

    2. By Anonymous Coward (87.210.142.234) on

      Ever hear about sane, safe defaults? Should every host in the world be properly configured to defy the attack? How is that ever going to work?

      You say the ipv6 community was aware of the dangers... but you decided to keep the mechanism anyway. Wow.

    3. By Anonymous Coward (81.57.42.108) on

      > Currently you can filter based existence/non-existence of routing header type.

      How to do this ?

      After a quick search through pf.conf(5), I didn't found anything.

      Comments

      1. By Janos Mohacsi (194.67.205.95) on

        > > Currently you can filter based existence/non-existence of routing header type.
        >
        > How to do this ?
        >
        > After a quick search through pf.conf(5), I didn't found anything.
        >

        block in quick inet6 proto ipv6-route from any to any

        Comments

        1. By sthen (85.158.44.149) on

          > block in quick inet6 proto ipv6-route from any to any

          This doesn't work on a plain OpenBSD installation (/etc/protocols doesn't list 43/ipv6-route). Does it work properly anyway (including the case where the routing header isn't the first extension header)?

    4. By Anonymous Coward (204.9.40.20) on

      >The current patch provided by OpenBSD community makes OpenBSD IPv6 implemenation non-conformant to standard. I would rather focus on pf changes - allow filtering based on the routing header type. Currently you can filter based existence/non-existence of routing header type. This is currently clearly not enough....

      Here's an opportunity for someone to do some good. There should be a good ability in PF to filter out IPv6 option headers.

      Comments

      1. By sthen (85.158.44.149) on

        > >The current patch provided by OpenBSD community makes OpenBSD IPv6 implemenation non-conformant to standard.

        Well, that happens sometimes when the standards are broken.

        > Here's an opportunity for someone to do some good. There should be a good ability in PF to filter out IPv6 option headers.

        An extension to 'scrub' might be a good place for this.

        Things over in Cisco-land aren't as safe as the slides would have you believe, btw.

        Comments

        1. By Anonymous Coward (194.67.205.95) on

          > The current patch provided by OpenBSD community makes OpenBSD IPv6 implemenation non-conformant to standard.
          >
          > Well, that happens sometimes when the standards are broken.
          >
          > Here's an opportunity for someone to do some good. There should be a good ability in PF to filter out IPv6 option headers.
          >
          > An extension to 'scrub' might be a good place for this.

          It is almost there:

          block in quick inet6 proto ipv6-route from any to any

          here I would like to see
          block in quick inet proto ipv6-route 0,1 from any to any

          Regards,

  6. By Anonymous Coward (194.25.2.250) on

    There`s a typo in patch 22 for 3.9
    Apply by doing:
    cd /usr/src
    patch -p0 < 012_route6.patch

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