Re: recvfrom(0.0.0.0) fd=51: Connection refused - NTP

This is a discussion on Re: recvfrom(0.0.0.0) fd=51: Connection refused - NTP ; Harlan Stenn wrote: > I'm not sure if multiple -I flags work or not. I know the command line > supports it, but I'm not sure if the underlying code does the right > thing or not. > The current ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Re: recvfrom(0.0.0.0) fd=51: Connection refused

  1. Re: recvfrom(0.0.0.0) fd=51: Connection refused



    Harlan Stenn wrote:
    > I'm not sure if multiple -I flags work or not. I know the command line
    > supports it, but I'm not sure if the underlying code does the right
    > thing or not.
    >


    The current code seems to have only one variable (grep
    specific_interface ntpd/*.c). In case of multiple -I flags it will
    retain only one (most likely the last).

    For this box, one -I is fine with me. For others, that might be a
    problem.

    In any case, it looks like it will always listen on 127.0.0.1 and
    on the wildcard interface, there is no way to disable those.


    >> I didn't want to report it, for several reasons. One is that I
    >> wanted that "connection refused" strangeness out of the way ASAP.
    >> Another one is I'm not even sure that this -I stuff is supposed to work
    >> already - after all I pulled it out of dev.

    >
    > If it is in -dev it will soon be in -stable.
    >


    Sure, but it might still be "work in progress". It seems so basic
    that, if the problem is real, anybody who tried -I must have seen it,
    including the developer(s). Usually that is an indication that the
    problem is at this end. I would want to rule that out before wasting
    people's time. Developers should develop sp we get new things to whine
    about .

    > If you see what you think is a problem, please report it.
    >
    > H



    Will do, but at this point I'm not sure it's even an ntpd problem,
    see above. Also, it might even be "working as designed", if the
    intention is to use it only with a local time source attached.

    Do you know if the -I switch is documented somewhere?

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: recvfrom(0.0.0.0) fd=51: Connection refused

    Luc Pardon wrote:
    >
    >
    > Harlan Stenn wrote:
    >> I'm not sure if multiple -I flags work or not. I know the command line
    >> supports it, but I'm not sure if the underlying code does the right
    >> thing or not.
    >>

    >
    > The current code seems to have only one variable (grep
    > specific_interface ntpd/*.c). In case of multiple -I flags it will
    > retain only one (most likely the last).
    >
    > For this box, one -I is fine with me. For others, that might be a
    > problem.
    >
    > In any case, it looks like it will always listen on 127.0.0.1 and on
    > the wildcard interface, there is no way to disable those.
    >


    Right. That was deliberate. You always want to listen on those addresses
    as well as ::1 and ::. Is there and issue with that?

    >
    >>> I didn't want to report it, for several reasons. One is that I
    >>> wanted that "connection refused" strangeness out of the way ASAP.
    >>> Another one is I'm not even sure that this -I stuff is supposed to
    >>> work already - after all I pulled it out of dev.

    >>
    >> If it is in -dev it will soon be in -stable.
    >>

    >
    > Sure, but it might still be "work in progress". It seems so basic
    > that, if the problem is real, anybody who tried -I must have seen it,
    > including the developer(s). Usually that is an indication that the
    > problem is at this end. I would want to rule that out before wasting
    > people's time. Developers should develop sp we get new things to whine
    > about .
    >


    No, currently it's not work-in-progress. It's awaiting time to get the
    listen-on address list into the config file as it really does not make a
    lot of sense to put those on the command line.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. "Listen on" semantics (was: Re: recvfrom(0.0.0.0)



    Danny Mayer wrote:
    > Luc Pardon wrote:
    >>
    >> In any case, it looks like it will always listen on 127.0.0.1 and on
    >> the wildcard interface, there is no way to disable those.
    >>

    >
    > Right. That was deliberate. You always want to listen on those addresses
    > as well as ::1 and ::. Is there and issue with that?
    >


    That depends on one's definition of "issue" .

    In my view it certainly does not meet the "principle of least
    surprise". It might be OK now because of the single -I limitation. But
    as soon as we can specify multiple addresses, if I want it to listen on
    127.0.0.1 I will tell it to. I mean, I would expect this to be "all or
    nothing": Either I let it use the defaults, or I take control. As it is
    now, it is a little bit of both and that is, well, surprising.

    There is also the issue of security. It is generally accepted as
    common sense that one should only install and run the services and open
    the ports that are absolutely needed.

    You may argue that in this particular case it doesn't hurt, and you
    may or may not have a point. But from the "common sense" point of view
    that is irrelevant. The only question is: do I absolutely need it under
    all circumstances? If not, don't open it.

    Just my 0.02 Euro.

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  4. Re: "Listen on" semantics

    Luc Pardon wrote:
    >
    >
    > Danny Mayer wrote:
    >> Luc Pardon wrote:
    >>>
    >>> In any case, it looks like it will always listen on 127.0.0.1 and on
    >>> the wildcard interface, there is no way to disable those.
    >>>

    >>
    >> Right. That was deliberate. You always want to listen on those addresses
    >> as well as ::1 and ::. Is there and issue with that?
    >>

    >
    > That depends on one's definition of "issue" .
    >
    > In my view it certainly does not meet the "principle of least
    > surprise". It might be OK now because of the single -I limitation. But
    > as soon as we can specify multiple addresses, if I want it to listen on
    > 127.0.0.1 I will tell it to. I mean, I would expect this to be "all or
    > nothing": Either I let it use the defaults, or I take control. As it is
    > now, it is a little bit of both and that is, well, surprising.
    >


    This is actually a bit more complicated than this. First let me explain
    what the -I interface option really means. The code binds to all
    available addresses on all interfaces irrespective of what options you
    specify. What -I really does is specify to ONLY accept those packets
    that arrive on that specific interface and it drops all packets arriving
    on all other interface. It's still listening on those addresses. More on
    this in a moment.

    Since you are able to only specify one interface this way it is
    important to be able to still listen on the loopback interface since you
    usually want to keep this enabled. You can if you want specify the
    loopback interface it it will only listen on that, not very useful.

    If you don't want to wait and REALLY want to disable the loopback
    interface you can just as effectively do that with restrict statements.
    The main difference between the two methodologies is that the -I option
    drops this right away while a restrict statement has to progress much
    further into the code before dropping the packet.

    Even when we allow you to specify multiple specific addresses or
    interfaces the code will still bind to ALL addresses but drop any packet
    arriving on an address you don't want.

    > There is also the issue of security. It is generally accepted as
    > common sense that one should only install and run the services and open
    > the ports that are absolutely needed.


    Here we are ahead of you. By binding to all interfaces and addresses we
    prevent other applications using them. The worst thing you can have is
    two different applications modifying the clock. The results would be
    totally unpredictable. Sometimes security involves doing more rather
    than less. In addition restrict statements allow you to refine the types
    of packets the server will accept and how it will respond and react to them.

    > You may argue that in this particular case it doesn't hurt, and you
    > may or may not have a point. But from the "common sense" point of view
    > that is irrelevant. The only question is: do I absolutely need it under
    > all circumstances? If not, don't open it.
    >


    No, on the contrary, you MUST open all of them or it WILL hurt. If you
    want to change the behavior in some way, use restrict statements. This
    is unlike almost any other application server where it doesn't matter if
    another application or a different instance of the same application
    could run. Here it DOES matter.

    My two shillings worth.

    Danny

    > Just my 0.02 Euro.
    >
    > Luc



    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: "Listen on" semantics


    Danny Mayer wrote:

    > ...
    > What -I really does is specify to ONLY accept those packets
    > that arrive on that specific interface and it drops all packets arriving
    > on all other interface. It's still listening on those addresses.
    > ...


    OK, thanks for the explanation. It's much clearer now.

    > By binding to all interfaces and addresses we
    > prevent other applications using them. The worst thing you can have is
    > two different applications modifying the clock.


    This is, I think, where we have fundamentally different perspectives.

    To you, the worst thing may well be a screwed-up clock (and
    incidentally that's a perfect mindset for a clock-daemon developer ).
    To me as an administrator, however, the Worst Thing is having the box
    hacked and rooted.

    Your reasoning makes sense, but you are reasoning from the
    assumption that there are no bugs in the code. Nobody can guarantee
    that, and certainly not an application with +73k lines of code (wc -l
    ntp-dev-4.2.3p39/ntpd/*.c). That's simply impossible.

    Your reasoning also assumes that every incoming packet is playing by
    the rules, or at least that the code can handle all kinds of malformed
    packets, that it will never cut its virtual fingers on the sharp edges
    of packets that were crafted on purpose by malicious minds. That is a
    dangerous assumption in today's world.

    Yes, the code path may be much shorter if you drop the packets right
    away. But it takes only one typo to create an exploitable vulnerability.
    If not today, then maybe tomorrow, after the next maintenance cycle.

    Besides, the -I switch won't help me with the most vulnerable
    interface on a two-NIC box acting as a stratum 3 time server for an
    internal network. I tried to disable the public interface (by specifying
    -I ) but then it can't seem to reach the stratum 2
    servers outside. The net result is that I have no choice but to let any
    "packet from hell" make its way through the "restrict" processing.

    In any case, the simple fact is: as soon as you accept packets, you
    are posing a security risk.


    Of course you are right that, if I run two different applications
    that modify the clock, I may have a problem, but at least it's a problem
    of my own making. If you really want to protect me from shooting myself
    in the foot by locking all unused interfaces, make it optional. Make it
    the default if you want, but at least give me the option to disable it.


    > My two shillings worth.
    >
    > Danny
    >
    >> Just my 0.02 Euro.
    >>
    >> Luc

    >

    At the current exchange rate, that gives your's more weight than
    mine .

    As far as I am concerned, we can leave it at that, and agree to
    disagree. I won't have an issue with that.

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: "Listen on" semantics

    Luc Pardon wrote:
    >
    > Danny Mayer wrote:
    >> By binding to all interfaces and addresses we
    >> prevent other applications using them. The worst thing you can have is
    >> two different applications modifying the clock.

    >
    > This is, I think, where we have fundamentally different perspectives.
    >
    > To you, the worst thing may well be a screwed-up clock (and
    > incidentally that's a perfect mindset for a clock-daemon developer ).
    > To me as an administrator, however, the Worst Thing is having the box
    > hacked and rooted.
    >


    At which point your log timestamps better be accurate so you can trace
    things back. This is *NOT* from a developer's viewpoint.

    > Your reasoning makes sense, but you are reasoning from the assumption
    > that there are no bugs in the code. Nobody can guarantee that, and
    > certainly not an application with +73k lines of code (wc -l
    > ntp-dev-4.2.3p39/ntpd/*.c). That's simply impossible.
    >


    No, there *ARE* bugs in the code, that's not even speculation, but
    that's not in any way related to the question at hand.

    > Your reasoning also assumes that every incoming packet is playing by
    > the rules, or at least that the code can handle all kinds of malformed
    > packets, that it will never cut its virtual fingers on the sharp edges
    > of packets that were crafted on purpose by malicious minds. That is a
    > dangerous assumption in today's world.
    >


    No, the code actual spends a lot of time checking the packet that comes
    in before it uses the contents. malformed packets will be immediately
    rejected. The only other thing you can do to an NTP packet is put in bad
    timestamps, which if it is incoming to a client will be dismissed as way
    out of range. The only other parts in an NTP packet deals with security
    but you won't get far with that.

    Are there other ways of doing something nasty to a packet? Undoubtedly
    there are things we haven't thought of but there's not a lot in the
    packet that you can change in the first place. None of this has anything
    to do with binding to all interface addresses.

    > Yes, the code path may be much shorter if you drop the packets right
    > away. But it takes only one typo to create an exploitable vulnerability.
    > If not today, then maybe tomorrow, after the next maintenance cycle.
    >


    Very true, but what has this to do with binding to all interface addresses?

    > Besides, the -I switch won't help me with the most vulnerable
    > interface on a two-NIC box acting as a stratum 3 time server for an
    > internal network. I tried to disable the public interface (by specifying
    > -I ) but then it can't seem to reach the stratum 2
    > servers outside. The net result is that I have no choice but to let any
    > "packet from hell" make its way through the "restrict" processing.
    >


    This does you no good, either way. The *ONLY* solution here is to use
    the restrict processing since you *MUST* accept packets on both NIC's.
    This is even if we had the ability to allow you to select which
    interface addressess to bind to you'd still have the same problem.

    If you are suggesting that you want to run two copies of ntpd on your
    server then you have a bigger problem since ntpd is not designed to work
    that way and it would be hard to support such a situation.

    > In any case, the simple fact is: as soon as you accept packets, you
    > are posing a security risk.
    >

    Well the alternative to that is not to connect to anything.

    >
    > Of course you are right that, if I run two different applications
    > that modify the clock, I may have a problem, but at least it's a problem
    > of my own making. If you really want to protect me from shooting myself
    > in the foot by locking all unused interfaces, make it optional. Make it
    > the default if you want, but at least give me the option to disable it.
    >


    You have that option today by modifying the code to your liking. Not the
    answer you want but it's even more fraught with potential security
    issues that I wouldn't want to support such a configuration.

    >
    >> My two shillings worth.
    >>
    >> Danny
    >>
    >>> Just my 0.02 Euro.
    >>>
    >>> Luc

    >>

    > At the current exchange rate, that gives your's more weight than mine
    > .
    >
    > As far as I am concerned, we can leave it at that, and agree to
    > disagree. I won't have an issue with that.
    >


    Well this is an important discussion. Mine is only one opinion. Others
    on the project have their own opinions.

    Danny

    > Luc
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  7. Re: "Listen on" semantics

    There are mechanism issues here that are separate from policy issues.

    As I understand it (and I am probably wrong on several of these points, but
    hey, it's a start):

    - We do not have a mechanism to specify exactly which interfaces we listen
    to.

    - there are good policy reasons for this, and I can see that these policy
    reasons are not universal.

    If we could tell ntpd to "not listen" to certain interfaces, there is no way
    a Bad Guy could send packets to ntpd via those interfaces (regardless of
    whether or not ntpd would be vulnerable to those packets).

    If we could limit which interfaces an ntpd process listened to, it might be
    possible to run multiple ntpd's on a box, with one of them in primary
    control, and the others using something like a local refclock in 'prefer'
    mode. This might be a useful way to do some testing of ntpd.

    There are pros/cons to additional flexibility, and it is Useful to discuss
    and understand these tradeoffs.

    H



  8. Re: "Listen on" semantics



    Danny Mayer wrote:
    > Luc Pardon wrote:
    >> Danny Mayer wrote:
    >>> By binding to all interfaces and addresses we
    >>> prevent other applications using them. The worst thing you can have is
    >>> two different applications modifying the clock.

    >> This is, I think, where we have fundamentally different perspectives.
    >>
    >> To you, the worst thing may well be a screwed-up clock (and
    >> incidentally that's a perfect mindset for a clock-daemon developer ).
    >> To me as an administrator, however, the Worst Thing is having the box
    >> hacked and rooted.
    >>

    >
    > At which point your log timestamps better be accurate so you can trace
    > things back. This is *NOT* from a developer's viewpoint.
    >

    Yes, when I get rooted it is important to find out how, and having
    accurate time does help, although we could argue about the need for
    absolute versus relative time. But that would get off topic.

    My point was that I'd prefer a hacker-proof fortified castle (I
    know: "pull the plug!") with less accurate time to a open house where I
    can determine with millisecond precision when exactly I got rooted.

    Of course I want both the super-castle _and_ the super-clock .

    >> Your reasoning makes sense, but you are reasoning from the assumption
    >> that there are no bugs in the code. Nobody can guarantee that, and
    >> certainly not an application with +73k lines of code (wc -l
    >> ntp-dev-4.2.3p39/ntpd/*.c). That's simply impossible.
    >>

    >
    > No, there *ARE* bugs in the code, that's not even speculation, but
    > that's not in any way related to the question at hand.
    >


    Quite to the contrary, it is. If there are bugs, it's dangerous to
    take candy from strangers, as (x)ntpd does.

    >> Your reasoning also assumes that every incoming packet is playing by
    >> the rules, or at least that the code can handle all kinds of malformed
    >> packets, that it will never cut its virtual fingers on the sharp edges
    >> of packets that were crafted on purpose by malicious minds. That is a
    >> dangerous assumption in today's world.
    >>

    >
    > No, the code actual spends a lot of time checking the packet that comes
    > in before it uses the contents. malformed packets will be immediately
    > rejected. The only other thing you can do to an NTP packet is put in bad
    > timestamps, which if it is incoming to a client will be dismissed as way
    > out of range. The only other parts in an NTP packet deals with security
    > but you won't get far with that.
    >
    > Are there other ways of doing something nasty to a packet? Undoubtedly
    > there are things we haven't thought of but there's not a lot in the
    > packet that you can change in the first place. None of this has anything
    > to do with binding to all interface addresses.
    >


    Again, your reasoning is valid only if there are no bugs. There have
    been boatloads of exploits, precisely because of bugs in UDP packet
    processing code, many of them precisely in the code that was intended to
    check that the packet is valid. Because all code can be assumed to
    contain bugs, all code must be assumed to be potentially vulnerable.

    Case in point #1: back in 2001, there was a bug in - yes - (x)ntpd
    that allowed remote root access. See, for example:

    http://archive.cert.uni-stuttgart.de.../msg00064.html

    If (x)ntpd had not listened and accepted and processed all junk that
    comes in, it would not have happened.

    Case in point #2: only last week, my logs were being flooded because
    somebody sent icmp port unreachable packets to udp/123. Each packet is
    good for about 80 bytes of wasted disk space. A determined attacker,
    starting on Friday evening, could use a high-speed line to fill up a
    multi-gigabyte disk and have free game by Sunday afternoon. By that time
    none of his actions will be logged anymore because of disk full. By
    Monday morning, the sysadmin will scratch his head over the "connection
    refused"'s and may not even know he's been hacked.

    If (x)ntpd had not listened and accepted and processed all junk that
    comes in, this would not be possible.


    >> Yes, the code path may be much shorter if you drop the packets right
    >> away. But it takes only one typo to create an exploitable vulnerability.
    >> If not today, then maybe tomorrow, after the next maintenance cycle.
    >>

    >
    > Very true, but what has this to do with binding to all interface addresses?
    >


    If you accept packets, there is a potential vulnerability. (x)ntp
    unnecessarily accepts anything, junk and malicious packets included.

    If you'll allow me I'll give you an analogy (crippled like all of
    them). I am building a fortified castle and I'm letting you live in it.
    What you do is hanging a rope out of your window (of room 123 ) for
    the postman to climb in and bring you the packets that you order from a
    mail order company.

    When I object that my enemies can come in as easily as the mailman,
    you say: "no worry, I'll fend them off, and besides, I need to hang out
    that rope to protect you from other problems, and besides, there is no
    other way to get at my packets".

    Now:

    * we both know that you can't guarantee me that you'll fend them off
    (bugs, new tricks, ...).
    * I ask you to let me decide if I want to be protected from other
    problems or not.
    * Finally, there _is_ another way to get at your packets, see below.

    Because I'm the landlord, you're going to pull your rope back in or
    convince me it's needed. If you fail to do either, I'll kick you out .

    >> Besides, the -I switch won't help me with the most vulnerable
    >> interface on a two-NIC box acting as a stratum 3 time server for an
    >> internal network. I tried to disable the public interface (by specifying
    >> -I ) but then it can't seem to reach the stratum 2
    >> servers outside. The net result is that I have no choice but to let any
    >> "packet from hell" make its way through the "restrict" processing.
    >>

    >
    > This does you no good, either way.


    That sounds a little bit like we're talking different things ??

    > The *ONLY* solution here is to use
    > the restrict processing


    No, restrict rules, while helpful, are not a solution. First, they
    may have bugs themselves, and second, they are based on IP addresses,
    which are easily spoofed with UDP. If I know where your IP is located,
    it's a fair guess what time servers you'll be using. I can send you a
    few dozen packets with various faked sender IP's until one sails right
    through your restrict rules and into the processing code, where
    potentially more bugs are waiting to be exploited.

    > since you *MUST* accept packets on both NIC's.


    Yes but no . Obviously, I must accept responses from time
    servers that answer a request of mine, else no sync. But there is no
    reason to accept anything else.

    > This is even if we had the ability to allow you to select which
    > interface addressess to bind to you'd still have the same problem.
    >
    > If you are suggesting that you want to run two copies of ntpd on your
    > server then you have a bigger problem since ntpd is not designed to work
    > that way and it would be hard to support such a situation.
    >


    What I want is not so much two copies of ntpd as a separation
    between client and server functionality.

    The client should keep my clock on track. The server should tell all
    my other systems what time it is.

    The server should listen for incoming requests all right, but only
    on the interfaces that I specify. That interface would be the one
    connected to the internal network only. After all, that's the only one
    where valid queries may come in. Yes, that would leave me vulnerable to
    attacks from within, but I can deal with that - if need be with a wooden
    pole .

    The client, on the other hand, should not be listening all the time,
    otherwise it's not a client but a server. When it's time to ask public
    server ntp1.example.com what time it is, the client should create a
    socket, fill in the sockaddr with the IP of ntp1.example.com, send the
    packet down the socket, receive the reply from the socket, then close
    the socket again. Yes, until the reply comes in, the client _will_ be
    listening, but with three important distinctions: a) it will see only
    packets that (pretend to) come from ntp1.example.com, b) it will not be
    listening on port 123 but on a random port assigned by the OS and c) the
    socket will be gone as soon as the reply is in. An attacker would 1)
    have to guess the IP of the server I queried and fake it, 2) he would
    have to guess the random port number that I'm listening on, and 3) he
    would have to make the fake packet arrive after the request but ahead of
    the real response. Still vulnerable, but much harder to exploit.

    The problem is that ntpd currently does not seem to use client mode,
    or at least does it in asynchroneous mode. If it did things in the above
    way:

    * it would not have to do the "rebind" trick to detect changes of
    dynamic IP's

    * it would have no problems dealing with multi-IP servers

    * it would not have to listen on - and handle every single packet
    from - the public interface

    >> In any case, the simple fact is: as soon as you accept packets, you
    >> are posing a security risk.
    >>

    > Well the alternative to that is not to connect to anything.
    >


    There is an alternative in between, and that is to connect to the
    outside servers in the regular client/server way, as described above.

    >> Of course you are right that, if I run two different applications
    >> that modify the clock, I may have a problem, but at least it's a problem
    >> of my own making. If you really want to protect me from shooting myself
    >> in the foot by locking all unused interfaces, make it optional. Make it
    >> the default if you want, but at least give me the option to disable it.
    >>

    >
    > You have that option today by modifying the code to your liking. Not the
    > answer you want but it's even more fraught with potential security
    > issues that I wouldn't want to support such a configuration.
    >


    You're probably going to kill me for this but there is another
    option: I can switch to OpenNTPD. That does - or seems to do - precisely
    what I want. With that setup, things like the exploit that bit (x)ntpd
    in 2001, or the "connection refused" issue that cost me so much time to
    diagnose, are simply impossible.

    My only requirement is that all the clocks of my internal machines
    are in reasonable sync. I'm not running a Space Station, so as long as
    all the machines are off in the same way, I don't mind if their time is
    a little off the absolute time of the Universe.

    What I'm testing out right now is OpenNTPD on the internal stratum 3
    server with the internal clients running (x)ntpd. It's been running for
    a week or so. Up to now it seems to do what I want.

    That means I have to trade off a millisecond-accurate clock against
    more security. I'm afraid that is pretty much a no-brainer.

    >>> My two shillings worth.
    >>>
    >>> Danny
    >>>
    >>>> Just my 0.02 Euro.
    >>>>
    >>>> Luc

    >> At the current exchange rate, that gives your's more weight than mine
    >> .
    >>
    >> As far as I am concerned, we can leave it at that, and agree to
    >> disagree. I won't have an issue with that.
    >>

    >
    > Well this is an important discussion. Mine is only one opinion. Others
    > on the project have their own opinions.
    >
    > Danny
    >
    >> Luc
    >>


    Well, that's why I gave it another try. But please keep in mind that
    I have no stake in this discussion, I have an alternative (see above).

    Unless I am mistaken, what is at stake for you is no less than a
    redesign of ntpd, or at least of the socket handling code. I don't
    expect that to happen and I'm not willing to "fight" to make it happen.
    That is why I proposed to leave it at that.

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  9. Re: "Listen on" semantics

    "Luc Pardon" wrote in message
    news:45110BAE.8040106@skopos.be...
    [...]
    > What I want is not so much two copies of ntpd as a separation
    > between client and server functionality.
    >
    > The client should keep my clock on track. The server should
    > tell all my other systems what time it is.


    Forget mentioning OpenNTP, folks here will crucify you for that alone.
    Which is exactly why I want to express my moral support (from a safe
    distance). This would be a TREMENDOUSLY good idea.

    It's also not going to happen. NTP is never finished, it seems. Never
    any time for redesigns like this.

    Groetjes,
    Maarten Wiltink



  10. Re: "Listen on" semantics

    >>> In article <4511394d$0$4523$e4fe514c@news.xs4all.nl>, "Maarten Wiltink" writes:

    Maarten> "Luc Pardon" wrote in message
    Maarten> news:45110BAE.8040106@skopos.be... [...]
    >> What I want is not so much two copies of ntpd as a separation between
    >> client and server functionality.
    >>
    >> The client should keep my clock on track. The server should tell all my
    >> other systems what time it is.


    As I understand it, that is not the ntp model, that is the timed model.

    When peering, ntpd exchanges time packets with other ntpd processes on other
    machines.

    We can get close to what you want today - run ntpd on your peering/master
    machines, and sntp on your client/leaf machines.

    Maarten> Forget mentioning OpenNTP, folks here will crucify you for that
    Maarten> alone.

    OpenBSD's OpenNTP was, as I recall (and IMO), originally a malignantly
    broken SNTP implementation. The last time I checked, it was still
    effectively an SNTP implementation, even though it was advertised as an NTP
    implementation.

    I complain about what I consider to be "false advertising". I don't care
    beyond that.

    Maarten> Which is exactly why I want to express my moral support
    Maarten> (from a safe distance). This would be a TREMENDOUSLY good idea.

    Maarten> It's also not going to happen. NTP is never finished, it
    Maarten> seems. Never any time for redesigns like this.

    "Software isn't finished until the last user is dead".

    And I'd be happy to see ntpd redesigned to be better. I will actively help
    in the process, too.

    I believe Dave will also be interested, and I also belive that Dave will
    insist that the results of that effort be Robust; most of the time when I
    have seen Dave complain about somebody's idea it was because the idea was a
    good solution in a limited area, and behaved Badly under other conditions.

    Put another way, volunteers would be welcome.

    H

  11. Re: "Listen on" semantics

    >>> In article <45110BAE.8040106@skopos.be>, xntp@skopos.be (Luc Pardon) writes:

    Lots of good stuff.

    Luc> Case in point #1: back in 2001, there was a bug in - yes - (x)ntpd
    Luc> that allowed remote root access. See, for example:
    Luc> http://archive.cert.uni-stuttgart.de.../msg00064.html

    First, please compare this history to other root-running processes and tell
    me how (x)ntpd compares. Especially given the length of time (x)ntpd has
    been in the field.

    Second, thanks for that URL; as I recall I heard *claims* that a root
    exploit was possible but I never saw something that demonstrated it. I do
    recall looking at code that *claimed* to produce a root shell, but neither I
    nor any of the folks I talked to was able to reproduce this.

    I'll add this to my queue of things to look at, anyway.

    Luc> Case in point #2: only last week, my logs were being flooded
    Luc> because somebody sent icmp port unreachable packets to udp/123. Each
    Luc> packet is good for about 80 bytes of wasted disk space. A determined
    Luc> attacker, starting on Friday evening, could use a high-speed line to
    Luc> fill up a multi-gigabyte disk and have free game by Sunday
    Luc> afternoon. By that time none of his actions will be logged anymore
    Luc> because of disk full. By Monday morning, the sysadmin will scratch his
    Luc> head over the "connection refused"'s and may not even know he's been
    Luc> hacked.

    Fair point, and Real Soon Now we're going to have better configuration
    control over logfiles. And I thought syslog() was pretty good about "Last
    message repeated N times".

    Regardless, I would like to see all these issues resolved, and I'm happy to
    work cooperatively with anybody to see this happen.

    H

  12. Re: "Listen on" semantics



    Harlan Stenn wrote:
    >>>> In article <45110BAE.8040106@skopos.be>, xntp@skopos.be (Luc Pardon) writes:

    >
    > Lots of good stuff.
    >
    > Luc> Case in point #1: back in 2001, there was a bug in - yes - (x)ntpd
    > Luc> that allowed remote root access. See, for example:
    > Luc> http://archive.cert.uni-stuttgart.de.../msg00064.html
    >
    > First, please compare this history to other root-running processes and tell
    > me how (x)ntpd compares. Especially given the length of time (x)ntpd has
    > been in the field.
    >


    We wouldn't be having this discussion if I was of the opinion that
    (x)ntpd had a lousy track record. I wouldn't bother.

    I mentioned this only to show that there can be buffer overflow
    bugs in otherwise correct code.

    To put it another way: if I want to serve a web site, I _must_ have
    something listening at tcp/80. In that case, the track record _is_
    relevant: I'll select a server with a good one, hope for the best and
    prepare for the worst. Sooner or later, there _will_ be an exploit and
    then I have to patch as fast as I can. It is a risk, but I have no
    choice. In return for taking the risk, I have a website. Now, if I don't
    need a website on that machine, why run a web server, no matter how good
    its track record?

    To keep the time (in my setup, which I believe to be typical for
    the majority of users), there is no need to have a server on a public
    interface. Taking the risk buys me nothing and therefore I am not
    prepared to accept it, no matter how good the track record of the daemon.

    > Luc> Case in point #2: only last week, my logs were being flooded
    > Luc> because somebody sent icmp port unreachable packets to udp/123.
    >
    > Fair point, and Real Soon Now we're going to have better configuration
    > control over logfiles.


    The problem is that you can't distinguish between real and fake
    packets. If you suppress the fake "connection refused", you may be
    wiping real problems under the carpet as well.

    > And I thought syslog() was pretty good about "Last
    > message repeated N times".


    Point taken, I did forget that. It issues a "repeated" every
    second, so our attacker would not be ready by Sunday. Unless he can find
    another way - preferably with (x)ntpd - to generate a syslog entry and
    alternate that with the port unreachable packets. A "grep syslog *.c |
    grep LOG_ERR" yields some promising candidates.

    Out of curiosity, I had a quick look at the ntp-dev-4.2.3p39 code.



    At first sight, it seems possible to craft a packet that will end up
    in process_private() in ntp_request.c and trigger the sanity check in
    there.

    In ntp_proto.c(388), it says:

    hismode = (int)PKT_MODE(pkt->li_vn_mode);
    hisstratum = PKT_TO_STRATUM(pkt->stratum);
    if (hismode == MODE_PRIVATE) {
    if (restrict_mask & RES_NOQUERY) {
    sys_restricted++;
    return; /* no query private */
    }
    process_private(rbufp, ((restrict_mask &
    RES_NOMODIFY) == 0));
    return;
    }

    So I'd set the li_vn_mode to PRIVATE (whatever that means ) and
    I'd fake the source address to 127.0.0.1 to steer it past the restrict
    rules in most setups. If and when I make it into process_private(), I
    have a choice of 4 fields in the packet that I can load with invalid
    values, or I could make it too long or too short. In ntp_request.c(433)
    my malicious eyes see the following code that makes me drool:

    /*
    * Do some sanity checks on the packet. Return a format
    * error if it fails.
    */
    ec = 0;
    if ( (++ec, ISRESPONSE(inpkt->rm_vn_mode))
    || (++ec, ISMORE(inpkt->rm_vn_mode))
    || (++ec, INFO_VERSION(inpkt->rm_vn_mode) > NTP_VERSION)
    || (++ec, INFO_VERSION(inpkt->rm_vn_mode) < NTP_OLDVERSION)
    || (++ec, INFO_SEQ(inpkt->auth_seq) != 0)
    || (++ec, INFO_ERR(inpkt->err_nitems) != 0)
    || (++ec, INFO_MBZ(inpkt->mbz_itemsize) != 0)
    || (++ec, rbufp->recv_length < REQ_LEN_HDR)
    ) {
    msyslog(LOG_ERR, "process_private: INFO_ERR_FMT: test
    %d failed, pkt from %s", ec, stoa(srcadr));
    req_ack(srcadr, inter, inpkt, INFO_ERR_FMT);
    return;
    }

    Too bad the restrict rules are in front of it, otherwise I could use
    my own IP (or that of one of my zombies) and I'd get an ack if I
    succeeded, then start faking source IP's.



    Again: this is just the result of a quick look at unfamiliar code.
    More likely than not, I'm missing something obvious so that this won't
    fly. But it sure looks promising and if it should work, I have my siege
    engine complete. By alternating one of these with an icmp packet, I can
    flood the log just fine.

    Again, this would not be an issue at all if (x)ntpd didn't take
    candy from strangers.

    >
    > Regardless, I would like to see all these issues resolved, and I'm happy to
    > work cooperatively with anybody to see this happen.
    >
    > H
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  13. Re: "Listen on" semantics


    Harlan Stenn wrote:

    >>> The client should keep my clock on track. The server should tell all my
    >>> other systems what time it is.

    >
    > As I understand it, that is not the ntp model, that is the timed model.
    >

    My understanding is that timed is a master/slave model, where one
    host on a LAN takes the lead and the others take their time from it.
    When the master dies, the slaves hold an election among themselves and
    the winner becomes the new master.

    What I meant by "client" is a some process that obtains the time
    from another process that provides it. In that sense, the timed slave is
    a client to its master, ntpd (at lest the part that sets the local
    clock) is a client to multiple servers (selecting the best), and sntp is
    a client to a single predefined server.

    > When peering, ntpd exchanges time packets with other ntpd processes

    on other
    > machines.
    >

    True, and when in peer mode ntpd must indeed listen "in server
    mode" for packets from its peers. So, if you're peering across the open
    Internet, you must listen on the public interface. But if all the peers
    are internal, there is - again - no need to listen to the outside world.

    > We can get close to what you want today - run ntpd on your peering/master
    > machines, and sntp on your client/leaf machines.
    >

    Functionally, yes. But that doesn't make me sleep any better. It's
    precisely about ntpd on the master box that I'm concerned. The leafs are
    shielded from the open Internet anyway, I don't mind running (x)ntpd there.

    Luc

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  14. Re: "Listen on" semantics

    "Harlan Stenn" wrote in message
    news:ywn9k63y5gcl.fsf@ntp1.isc.org...
    >> "Luc Pardon" wrote in message
    >> news:45110BAE.8040106@skopos.be...


    >>> What I want is not so much two copies of ntpd as a separation
    >>> between client and server functionality.
    >>>
    >>> The client should keep my clock on track. The server should tell
    >>> all my other systems what time it is.

    >
    > As I understand it, that is not the ntp model, that is the timed model.


    You may be reading things into the terms 'client' and 'server' that
    weren't there. (I think) the terms are being used strictly in a network
    sense: a server is a process that only listens; a client is a process
    that may _start_ conversations. No mention of all the intricate math
    that goes on in a full NTP implementation; obviously it does have to
    go somewhere.

    There is nothing that says Luc's proposed NTP client mustn't be a
    continually running process; in fact, 'the NTP model' would require it
    to. But the server part would not need to do all the NTP work itself.
    It might simply assume (or check) that the clock is being disciplined,
    and return packets as requested by remote clients.

    The introduction of a 'client only' mode for NTP (not SNTP) would make
    many people happy already. That could use ports in such a manner that
    time service does not automatically become available from the machine,
    and could try not to get in the way of a separate simple NTP time server.

    The first version of such a separate NTP server could be _really_ simple.
    After all, all it has to do is read the clock for anyone who asks. To
    keep the clock running straight is the client's job.

    At this point, people will shriek 'that's an SNTP server! Not NTP!' But
    is it? What's the difference? The current definition seems to be that
    to be an NTP server, you have to implement the client functionality (the
    math) yourself. I think it's more important _that_ the math is being
    done. _Where_ is not that important.


    [...]
    > OpenBSD's OpenNTP was, as I recall (and IMO), originally a malignantly
    > broken SNTP implementation.


    Malignantly, no less? Come off it. Sure, they made mistakes, but that
    wasn't the intent. The intent was to build something with no exploits.
    If the question is what comes first, working right or not getting rooted,
    well, they _are_ OpenBSD.

    (Wouldn't a client-mode real NTP, combined with an OpenSNTP server, be
    the ideal configuration?)

    Groetjes,
    Maarten Wiltink



  15. Re: "Listen on" semantics



    Harlan Stenn wrote:
    > And I thought syslog() was pretty good about "Last
    > message repeated N times".
    >


    In addition to my last post (which I forgot to sign, sorry), it may
    be worth recalling that ntp 4.2.0 (and maybe later) had a bug that make
    it log bogus IP's:

    > Sep 3 04:07:36 gida ntpd[4796]: recvfrom(193.190.230.65) fd=9:

    Connection refused
    > Sep 3 04:08:40 gida ntpd[4796]: recvfrom(192.168.1.3) fd=9:

    Connection refused

    OK, though they are not the IP's that the packets really came from,
    they are not really bogus. Apparently it's the IP that a packet was last
    received from (client or server). The syslog daemon wouldn't be able to
    compress these two lines. Of course, in between two legitimate queries,
    the log lines will all have the same IP. So, instead of only two log
    lines ("connection refused" and "message repeated") the attacker may be
    able to get a few more, but he would still be wasting most of his bandwidth.

    Even so, it does help to make the smoke curtain thicker and it would
    make the sysadmin scratch his head even more - I know, first hand.

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  16. Re: "Listen on" semantics



    Maarten Wiltink wrote:
    > "Harlan Stenn" wrote in message
    > news:ywn9k63y5gcl.fsf@ntp1.isc.org...
    >>> "Luc Pardon" wrote in message
    >>> news:45110BAE.8040106@skopos.be...

    >
    >>>> What I want is not so much two copies of ntpd as a separation
    >>>> between client and server functionality.
    >>>>
    >>>> The client should keep my clock on track. The server should tell
    >>>> all my other systems what time it is.

    >> As I understand it, that is not the ntp model, that is the timed model.

    >
    > You may be reading things into the terms 'client' and 'server' that
    > weren't there. (I think) the terms are being used strictly in a network
    > sense: a server is a process that only listens; a client is a process
    > that may _start_ conversations. No mention of all the intricate math
    > that goes on in a full NTP implementation; obviously it does have to
    > go somewhere.
    >

    I must admit that I'm probably at the source of the confusion.

    What I meant in this paragraph was not in a network sense, i.e. at
    the transport or socket layer, but at the application layer. By "client"
    (i.e. "time client") I meant to include all the magic that (x)ntpd uses
    to determine the time from "time servers" at a higher stratum.

    In the other parts of the discussion, I was using the terms indeed
    in the network sense.

    To make it [clearer|more confusing] : currently, the (x)ntpd "time
    client" uses a "socket server" (listening) to receive its time info,
    i.e. it operates in async mode. I would like to see it use a regular
    "socket client" in synchroneous mode instead.


    > There is nothing that says Luc's proposed NTP client mustn't be a
    > continually running process; in fact, 'the NTP model' would require it
    > to. But the server part would not need to do all the NTP work itself.
    > It might simply assume (or check) that the clock is being disciplined,
    > and return packets as requested by remote clients.
    >

    Exactly. I don't care too much how the client and server are
    implemented, in separate processes or in one single process, although
    personally I'd go for separate if possible (KISS and security). But if
    they are in a single process, I'd do want to be able to switch the
    logical components (client, server, peer) on or off in the config file
    to suit my needs.

    > The introduction of a 'client only' mode for NTP (not SNTP) would make
    > many people happy already. That could use ports in such a manner that
    > time service does not automatically become available from the machine,
    > and could try not to get in the way of a separate simple NTP time server.
    >


    It certainly would make _me_ happy. What I miss in OpenNTPD is not
    so much the reduced precision as the lack of ntpq.

    In any case, I believe that "my" setup, i.e an stratum 3 server for
    an internal network, is a typical setup. It's Not Good to force all
    these admins to choose between better time and better security if they
    can have both.

    > Groetjes,
    > Maarten Wiltink
    >

    BTW: thanks for the moral support!

    Groetjes terug,

    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  17. Re: "Listen on" semantics

    Luc Pardon schrieb:
    > [... very interesting but long security discussion ...]
    >
    >
    > It certainly would make _me_ happy. What I miss in OpenNTPD is not
    > so much the reduced precision as the lack of ntpq.


    Sorry for eating all the quoted text, but I only wanted to ask you why
    there is no such thing as ntpq for OpenNTPD?

    Where do you think would the "server" part get all the information that
    ntpq shows to you?

    In order to provide this, the "client" part (ntpd in your scenario)
    would at least have to listen for ntpq queries.

    I would think that adding a configuration statement that specifies one
    or more interfaces ntpd should listen on would be the easiest solution, no?

    Best regards,
    Heiko



    --
    Meinberg radio clocks: 25 years of accurate time worldwide

    MEINBERG Radio Clocks
    www.meinberg.de

    Stand alone ntp time servers and radio clocks based on GPS, DCF77 and
    IRIG. Rackmount and desktop versions and PCI slot cards.

  18. Re: "Listen on" semantics



    Heiko Gerstung wrote:
    > Luc Pardon schrieb:
    >> [... very interesting but long security discussion ...]
    >>
    >>
    >> It certainly would make _me_ happy. What I miss in OpenNTPD is not
    >> so much the reduced precision as the lack of ntpq.

    >
    > Sorry for eating all the quoted text, but I only wanted to ask you why
    > there is no such thing as ntpq for OpenNTPD?
    >

    No problem about eating the text, I only hope you won't get stomach
    problems .

    > Where do you think would the "server" part get all the information that
    > ntpq shows to you?
    >
    > In order to provide this, the "client" part (ntpd in your scenario)
    > would at least have to listen for ntpq queries.
    >
    > I would think that adding a configuration statement that specifies one
    > or more interfaces ntpd should listen on would be the easiest solution, no?
    >


    This would in fact be one reason to combine client and server
    functionality in one daemon, so that the server part could easily look
    at the info that the time client keeps around. If you make the client
    listen to ntpq-queries, there is no real reason it can't answer the
    regular time queries as well.

    But in any case, yes, the interface where ntpq queries are accepted
    should be configurable.


    > Best regards,
    > Heiko


    Luc
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  19. Re: "Listen on" semantics

    Luc Pardon wrote:
    >
    >
    > Heiko Gerstung wrote:
    >> Luc Pardon schrieb:
    >>> [... very interesting but long security discussion ...]
    >>>
    >>>
    >>> It certainly would make _me_ happy. What I miss in OpenNTPD is
    >>> not so much the reduced precision as the lack of ntpq.

    >>
    >> Sorry for eating all the quoted text, but I only wanted to ask you why
    >> there is no such thing as ntpq for OpenNTPD?
    >>

    > No problem about eating the text, I only hope you won't get stomach
    > problems .
    >
    >> Where do you think would the "server" part get all the information
    >> that ntpq shows to you?
    >>
    >> In order to provide this, the "client" part (ntpd in your scenario)
    >> would at least have to listen for ntpq queries.
    >>
    >> I would think that adding a configuration statement that specifies one
    >> or more interfaces ntpd should listen on would be the easiest
    >> solution, no?
    >>

    >
    > This would in fact be one reason to combine client and server
    > functionality in one daemon, so that the server part could easily look
    > at the info that the time client keeps around. If you make the client
    > listen to ntpq-queries, there is no real reason it can't answer the
    > regular time queries as well.
    >
    > But in any case, yes, the interface where ntpq queries are accepted
    > should be configurable.
    >


    Now I wonder why you don't look at the restrict statement particularly
    the noquery option?

    Danny

    >
    >> Best regards,
    >> Heiko

    >
    > Luc
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  20. Re: "Listen on" semantics

    In article <45124ad1$0$4516$e4fe514c@news.xs4all.nl>,
    Maarten Wiltink wrote:

    > At this point, people will shriek 'that's an SNTP server! Not NTP!' But
    > is it? What's the difference? The current definition seems to be that


    The difference is that an NTP server reports more information obtained
    by the client part to its clients. Even an SNTP server is supposed
    to report the stratum, even if Microsoft, and the original OpenNTPD
    forgot to do this. NTP has to report root delay and root dispersion,
    and leap warnings.


+ Reply to Thread
Page 1 of 2 1 2 LastLast