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

61–70 of 120 posts

Re: Multiple vulnerabilities released in NTP

#61

Post by rudolf0 »

AgentME wrote: post #57

All of the buffer overflows are on the stack, right? Shouldn't the default stack protector that most compilers today enable should stop that from being exploitable for remote code execution? I'm just trying to estimate the likelihood that anyone was hacked through this vulnerability. Even with stack protection the vulnerability could be used to crash ntp, so upgrading is a very good idea still.

There are ways of bypassing stack canaries, depending on the specific application and environment. No exploitation mitigation is ever fool-proof.

Also, in many cases applications will be distributed or have Makefiles without enabling stack canaries or sometimes even DEP and ASLR.

Re: Multiple vulnerabilities released in NTP

#62

Post by AgentME »

rudolf0 wrote: post #61
AgentME wrote: post #57

All of the buffer overflows are on the stack, right? Shouldn't the default stack protector that most compilers today enable should stop that from being exploitable for remote code execution? I'm just trying to estimate the likelihood that anyone was hacked through this vulnerability. Even with stack protection the vulnerability could be used to crash ntp, so upgrading is a very good idea still.

There are ways of bypassing stack canaries, depending on the specific application and environment. No exploitation mitigation is ever fool-proof. Also, in many cases applications will be distributed or have Makefiles without enabling stack canaries or sometimes even DEP and ASLR.

>There are ways of bypassing stack canaries, depending on the specific application and environment.

Bypassing a stack canary generally requires a separate memory disclosure vulnerability if I remember right. (Or an interesting local variable in the same function as the buffer like a function pointer, but I think compilers now are smart enough to try to arrange buffers to be the last thing on the stack before the canary.) It wouldn't be surprising if one existed, but I don't think any were publicly disclosed now.

I guess what I'm asking is: 1) Are there any public exploits that get remote code execution against NTP on modern systems (Should we expect that the average MITM is popping shells with this already on most systems?), and 2) do all modern distributions (like say Debian) containing NTP have the standard default mitigations (DEP, stack canaries, etc) enabled on NTP, or why not?

Re: Multiple vulnerabilities released in NTP

#63

Post by tedunangst »

imanaccount247 wrote: post #47
feld wrote: post #15

Earlier quoted context omitted.

I've talked to several developers about the state of NTP daemons and neither OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those support NTP Authentication nor do they have all of the required algorithms required for proper timekeeping.

>nor do they have all of the required algorithms required for proper timekeeping. I hear something like that a lot, yet all my systems run openntpd and all of them are keeping proper time without issue. What exactly is so not proper about it, and which algorithm exactly does it need to be "proper"?

People who are into timekeeping are like, really, really into timekeeping. I've been skating by with improper timekeeping, too (whatever that means), but I only need to correlate web log entries and not hadron collisions.

Re: Multiple vulnerabilities released in NTP

#65

Post by Bino »

cheeseprocedure wrote: post #23

Do these vulnerabilities impact a local ntpd instance responsible only for local timekeeping? (In other words, does a compromised machine in pool.ntp.org pose a threat?)

This should be stated more clearly. Should we all panic?

Does it affect any ntpd asking for time?

Does it affect a ntpd asking a compromised server for time?

Does it only affect ntpds answering to time requests?

Re: Multiple vulnerabilities released in NTP

#66

Post by SCdF »

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 completely?

My reasoning comes from the vast majority of problems I notice being from the edge cases in managing memory, and so if I understand correctly there is a whole suite of languages that mostly remove these problems.

Re: Multiple vulnerabilities released in NTP

#67

Post by zeeg »

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…

If you think introducing Rust (as an example) solves these kinds of problems you are sorely mistaken.

Languages can make it easier for some things, but they're not a magical fix all. If it weren't this problem it would be something else, something that even "the great mythical Rust" can't prevent.

Re: Multiple vulnerabilities released in NTP

#68

Post by cbsmith »

Ricapar wrote: post #29
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?

There is still a lot of crypto out there that works off of using the current timestamp as a seed. Being able to control he time could theoretically let you control any PRNGs that rely on it.

It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

Re: Multiple vulnerabilities released in NTP

#69

Post by cbsmith »

hannob wrote: post #27

The best solution is not to use ntp anyway. It's an unencrypted, unauthenticated protocol vulnerable to Man in the Middle attacks. There was a pretty neat attack presented at BH Europe circumventing HSTS with a MitM-attack on NTP. Better just replace it with tlsdate.

Actually, NTP has (limited) support for authentication and encryption. I would agree it's pretty lame though.

Re: Multiple vulnerabilities released in NTP

#70

Post by cbsmith »

tedunangst wrote: post #39
Ricapar wrote: post #29

Earlier quoted context omitted.

There is still a lot of crypto out there that works off of using the current timestamp as a seed. Being able to control he time could theoretically let you control any PRNGs that rely on it.

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.
Post reply on HN