Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple vulnerabilities released in NTP

support.ntp.org

Post reply on HN
Print view View original

91–100 of 120 posts

Re: Multiple vulnerabilities released in NTP

#91

Post by zzzcpan »

SCdF wrote: post #66

Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completel…

Nowadays it is possible to catch these kinds of errors ahead of time and at runtime with some help from static analyzers and other special tools, like AddressSanitizer. This report itself is likely to be the result of such work. So, rewrite is not worthwhile if your reasoning is to prevent edge cases in managing memory.

Re: Multiple vulnerabilities released in NTP

#92

Post by zzzcpan »

lawnchair_larry wrote: post #84
SCdF wrote: post #66

Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completel…

No, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore. Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.

Ntpd should be replaced with something different, not rewritten. There is no reason to rewrite it. But I agree, there is no good reason to write such things in C anymore.

Re: Multiple vulnerabilities released in NTP

#93

Post by phkamp »

nknighthb wrote: post #56
jandrese wrote: post #46

Earlier quoted context omitted.

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.

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 tryin…

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

Re: Multiple vulnerabilities released in NTP

#94

Post by xorcist »

mbq wrote: post #41
dfc wrote: post #35

Earlier quoted context omitted.

systemd-timesyncd is not much of an alternative. It is simply an sntp client, it does not serve time to other hosts nor can it use reference clocks.

Sure, but IMO enough many systems use NTP only in a sntp manner to mention it.

SNTP is close to useless. Your time server could be off and you'd happily follow along.

Re: Multiple vulnerabilities released in NTP

#95

Post by xorcist »

agwa wrote: post #33
NoMoreNicksLeft wrote: post #28

Earlier quoted context omitted.

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late? Or can you circumvent certificate revocations this way?

You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked. You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise. And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.

For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack.

NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.

Unless you use SNTP on your servers. Don't do that. Ever.

Re: Multiple vulnerabilities released in NTP

#96

Post by nknighthb »

phkamp wrote: post #93
nknighthb wrote: post #56

Earlier quoted context omitted.

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 tryin…

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

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.

Re: Multiple vulnerabilities released in NTP

#97

Post by xorcist »

jandrese wrote: post #46
tedunangst wrote: post #19

Earlier quoted context omitted.

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

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.

Most of code is hardware support for a multitude of GPS receivers and other clocks.

Re: Multiple vulnerabilities released in NTP

#98

Post by xorcist »

It is important to know how NTP works before you set it up. Several of the comments seem to be misguided. NTP is a peer-to-peer protocol, there are no such thing as an "NTP server" or an "NTP client".

NTP measures clock drift over a server group. It discovers enough about your topology to assign a statistical factor to each peer, so that a rogue or broken server can not bring down the whole group.

Known good time (which is what the stratum value is, a measure of distance to known good time) is then sprinkled in from several sources to drift the time in the direction of true time.

Exactly as you should have a number of secondary DNS servers in different AS, you should use several different time sources from different organizations. If you are bigger than a closet shop, you might as well put your own GPS receiver in there too when sparkfun sells them for $40, and enable authentication on it.

Re: Multiple vulnerabilities released in NTP

#99

Post by rian »

lawnchair_larry wrote: post #84
SCdF wrote: post #66

Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completel…

No, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore. Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.

Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous.

I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language.

Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/. Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.

Re: Multiple vulnerabilities released in NTP

#100

Post by [deleted] »

rian wrote: post #99
lawnchair_larry wrote: post #84

Earlier quoted context omitted.

No, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore. Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.

Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous. I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language. Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/ . Adds a…

[deleted]
Post reply on HN