5 ms·

A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege le

by ck2 12y ago

A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. Geez, in a time sync program? Nothing is safe anymore.

tedunangst 12y ago
ntpd is a, uh, rather large time sync program.
- jandrese 12y ago
  Indeed. PHK noted that it's on the order of 100,000 lines of code. That's a staggering amount for something that queries a remote server and steers your clock.
  - nknighthb 12y ago
    100,000 lines of C is certainly unnecessary for the most common usage of ntpd, but it is far from staggering considering ntpd's full scope as a portable client, server, and peer-to-peer node attempting high precision synchronization on heterogeneous hardware across the globe. It doesn't just "query a remote server and steer your clock", and "steer your clock" is a lot more complicated than it sounds when you're trying to achieve such precision.
    - phkamp 12y ago
      Actually, you're wrong. Most of that source code is there for different and wrong reasons. It doesn't take much source code to steer your clock precisly, we are talking less than 100 lines. What takes up space is all the "extras" and "nice to haves".
      - nknighthb 12y ago
        I don't think I am, and you haven't given me any reason to believe I am. Why don't you list some of those "extras" and "nice to haves"? Some of them are probably absolutely critical to my services. All of them are probably critical to somebody's. I don't think you're understanding that I'm not in any way disputing that we need something orders of magnitude smaller for the most common case of a simple desktop or server keeping an approximately accurate clock. If your response to me talks about just steering a clock, you are not responding to me.
        phkamp 12y ago
        Apologies for being a bit terse, but I've got stuff to do, including buying X-mas presents for my family :-) I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html http://phk.freebsd.dk/time/index.html Feel free to ask any questions not already answered there. Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code. It really isn't rocket size. OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view. The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end. (I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.) Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-Link_and_Poul-Henning_Kamp http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...) Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-) But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time. If ntimed-client ever grows above 10KLOC, I've failed that goal. First preview release of the source code will happen this weekend.
  - xorcist 12y ago
    Most of code is hardware support for a multitude of GPS receivers and other clocks.

by ck2 12y ago

tedunangst 12y ago

ntpd is a, uh, rather large time sync program.

jandrese 12y ago
Indeed. PHK noted that it's on the order of 100,000 lines of code. That's a staggering amount for something that queries a remote server and steers your clock.
- nknighthb 12y ago
  100,000 lines of C is certainly unnecessary for the most common usage of ntpd, but it is far from staggering considering ntpd's full scope as a portable client, server, and peer-to-peer node attempting high precision synchronization on heterogeneous hardware across the globe. It doesn't just "query a remote server and steer your clock", and "steer your clock" is a lot more complicated than it sounds when you're trying to achieve such precision.
  - phkamp 12y ago
    Actually, you're wrong. Most of that source code is there for different and wrong reasons. It doesn't take much source code to steer your clock precisly, we are talking less than 100 lines. What takes up space is all the "extras" and "nice to haves".
    - nknighthb 12y ago
      I don't think I am, and you haven't given me any reason to believe I am. Why don't you list some of those "extras" and "nice to haves"? Some of them are probably absolutely critical to my services. All of them are probably critical to somebody's. I don't think you're understanding that I'm not in any way disputing that we need something orders of magnitude smaller for the most common case of a simple desktop or server keeping an approximately accurate clock. If your response to me talks about just steering a clock, you are not responding to me.
      - phkamp 12y ago
        Apologies for being a bit terse, but I've got stuff to do, including buying X-mas presents for my family :-) I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html http://phk.freebsd.dk/time/index.html Feel free to ask any questions not already answered there. Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code. It really isn't rocket size. OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view. The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end. (I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.) Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-Link_and_Poul-Henning_Kamp http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...) Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-) But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time. If ntimed-client ever grows above 10KLOC, I've failed that goal. First preview release of the source code will happen this weekend.
- xorcist 12y ago
  Most of code is hardware support for a multitude of GPS receivers and other clocks.