[ntp:security] [Bug 3020] Refclock impersonation vulnerability

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Mon Feb 29 09:50:16 UTC 2016


http://bugs.ntp.org/show_bug.cgi?id=3020

--- Comment #3 from Harlan Stenn <stenn at ntp.org> 2016-02-29 09:50:16 UTC ---
(In reply to comment #2)
> Matt,
> 
> What OSes are known to be vulnerable to this?
> 
> Under what circumstances is this behavior a feature, and not a bug in the
> network stack implementation?

As I understand Matt's response, no general purpose OSes have this bug,
although they are waiting for confirmation of this on one OS that is not widely
used.  Matt suggests we say:

  Systems that do not block martian packets are affected.  Examples
  include:
    - Linux systems configured with
      sys.net.ipv4.conf.all.rp_filter=0 and
      sys.net.ipv4.conf.all.route_localnet=1
    - Custom IP stacks
    - Legacy Operating Systems

and I'm not sure that *all* Legacy OSes are affected by this, nor are *all*
systems with custom IP stacks.

Matt also says:

 I have seen large scale distributed hardware platforms which use
 multiple independent IP-connected processors internally but look like a
 single computer to the outside world.  In those systems, they need some
 way to address the different processors on the IP interconnect and an
 address space guaranteed to be available is 127/8.  To do so martian
 filtering must be disabled for inter-processor traffic and, well, it
 puts them at bigger risk of having someone ingress 127/8 traffic from
 outside the box.  It's really a bug here too but, well, it's an
 environment where such a bug more likely given the other design choices.

-- 
Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the security mailing list