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

More Memory Safety for Let's Encrypt: Deploying ntpd-rs

letsencrypt.org

Post reply on HN
Print view View original

51–60 of 177 posts

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#51

Post by jaas »

landmarker10 wrote: post #42
jaas wrote: post #38

Earlier quoted context omitted.

I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply the first component that got to production status, a good place to start. NTP is a component worth moving to a memory safe language because it's a widely used critical service on a network boundary.…

[flagged]

People bring up postfix all the time in this context because supposedly nobody has ever found a memory safety vulnerability in it. Presumably this is supposed to make the point that it is possible to write complex programs in C safely.

The reason people know this about postfix and keep bringing this one specific example up is because it's so unusual! It's an example that almost stands alone, it's extraordinary.

I don't think this is making the point about the safety of C that you think it is.

There is a mountain of evidence suggesting that C is dangerous, particularly for network services, and one possible example to the contrary doesn't change that.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#52

Post by stouset »

kaql wrote: post #45
landmarker10 wrote: post #42

Earlier quoted context omitted.

[flagged]

[flagged]

Downvoting isn’t censorship. It’s disagreement.

“What about this one C project that hasn’t been a mess of exploitable vulnerabilities” is thoroughly unconvincing in a world where networked C programs are an unending source of severe vulnerabilities.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#53

Post by dmix »

lasjhdh wrote: post #50
devwastaken wrote: post #48

Earlier quoted context omitted.

It's not censorship to be downvoted for low quality posts. Please reference "intellectual honesty" and research how to have legitimate conversations. Reddit/Twitter/4chan esque communication is not appropriate for serious spaces.

[flagged]

> Intellectual honesty would be to point out the memory safety issue CVE of Postfix in the past decade.

this thread isn't about Postfix, you brought up Postfix as a counterpoint to a wider topic where such a anecdote doesn't hold up nearly as well in a broader scope. Don't purposefully narrow the topic and move goalposts just to win internet fights.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#54

Post by woodruffw »

cogman10 wrote: post #37
oconnor663 wrote: post #34

Earlier quoted context omitted.

> it's been running on many VMs without exploding memory for a while now Most of the security bugs we hear about don't cause random crashes on otherwise healthy machines, because that tends to get them noticed and fixed. It's the ones that require complicated steps to trigger that are really scary. When I look at NTP, I see a service that: - runs as root - talks to the network - doesn't usually authenticate its traff…

> runs as root ntpd can (and should) run as a user > talks to the network Makes outbound requests to the network. For it to be compromised, the network itself or a downstream server needs to be compromised. That's very different from something like hosting an http server. > doesn't usually authenticate its traffic Yes it does. ntp uses TLS to communicate with it's well known locations. > uses a bespoke binary packet…

I don’t think NTP uses TLS by default. The closest equivalent I can find online is NTS, which was only standardized in 2020 (and for which I can’t find clear adoption numbers).

(But regardless: “the transport layer is secure” is not a good reason to leave memory unsafe code on the network boundary. Conventional wisdom in these settings is to do the “defense in depth” thing and assume that transport security can be circumvented.)

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#55

Post by dheera »

jaas wrote: post #38
cogman10 wrote: post #28

This seems like a weird place to be touting memory safety. It's ntpd, it doesn't seem like a place for any sort of attack vector and it's been running on many VMs without exploding memory for a while now. I'd think there are far more critical components to rewrite in a memory safe language than the clock synchronizer.

I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply the first component that got to production status, a good place to start. NTP is a component worth moving to a memory safe language because it's a widely used critical service on a network boundary.…

Why are C and C++ all of a sudden unsafe? Did I miss something?

What is safe now? JavaScript? PyTorch?

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#56

Post by dequan »

dheera wrote: post #55
jaas wrote: post #38

Earlier quoted context omitted.

I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply the first component that got to production status, a good place to start. NTP is a component worth moving to a memory safe language because it's a widely used critical service on a network boundary.…

Why are C and C++ all of a sudden unsafe? Did I miss something? What is safe now? JavaScript? PyTorch?

All of a sudden? They've been unsafe for decades, it's just that you had less of a choice then.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#57

Post by dequan »

lasjhdh wrote: post #50
devwastaken wrote: post #48

Earlier quoted context omitted.

It's not censorship to be downvoted for low quality posts. Please reference "intellectual honesty" and research how to have legitimate conversations. Reddit/Twitter/4chan esque communication is not appropriate for serious spaces.

[flagged]

What an interesting coincidence that all three of these accounts were created within 15 minutes of each other. I'm sure all "three" users are being "intellectually honest" here.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#58

Post by mcpherrinm »

woodruffw wrote: post #54
cogman10 wrote: post #37

Earlier quoted context omitted.

> runs as root ntpd can (and should) run as a user > talks to the network Makes outbound requests to the network. For it to be compromised, the network itself or a downstream server needs to be compromised. That's very different from something like hosting an http server. > doesn't usually authenticate its traffic Yes it does. ntp uses TLS to communicate with it's well known locations. > uses a bespoke binary packet…

I don’t think NTP uses TLS by default. The closest equivalent I can find online is NTS, which was only standardized in 2020 (and for which I can’t find clear adoption numbers). (But regardless: “the transport layer is secure” is not a good reason to leave memory unsafe code on the network boundary. Conventional wisdom in these settings is to do the “defense in depth” thing and assume that transport security can be ci…

ntpd-rs supports NTS and we (Let’s Encrypt) are using it a little bit. But it is far from having any wide adoption yet.

There aren’t many public NTS servers: https://netfuture.ch/public-nts-server-list/ and https://github.com/jauderho/nts-servers have some listed.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#59

Post by ghshephard »

dheera wrote: post #55
jaas wrote: post #38

Earlier quoted context omitted.

I'm the person driving this. NTP is worth moving to a memory safe language but of course it's not the single most critical thing in our entire stack to make memory safe. I don't think anyone is claiming that. It's simply the first component that got to production status, a good place to start. NTP is a component worth moving to a memory safe language because it's a widely used critical service on a network boundary.…

Why are C and C++ all of a sudden unsafe? Did I miss something? What is safe now? JavaScript? PyTorch?

One of the major drivers (if not the driver) for the creation of Rust the fact that C is not a memory-safe language.

This has been known for decades, but it wasn't until 2010 that a serious attempt at writing a new system-language that was memory safe was attempted and got traction - Rust.

https://kruschecompany.com/rust-language-concise-overview/#:....

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#60

Post by hot_gril »

danudey wrote: post #10
pjmlp wrote: post #5

Earlier quoted context omitted.

Because since the Morris Worm in 1988, there are still plenty of networking facing services that keep being written in C and C++, and without the necessary sanitary precautions. True, there are plenty of alternatives for many of those networking services, not necessarily Rust.

I hate writing code in golang, because I have to pepper every single function call with `if err != nil`, but then I think about how much C code I've seen that doesn't do that and I wonder how much of it should.

Golang's error handling is safer than C's, but it's more cumbersome than it needs to be. In high-level code, nearly every func you write can return an error, and 99% of the time you're just going to pass the error up. Webserver will catch all and send 4xx or 5xx, for example. Exceptions are a lot more convenient and encourage solid error handling.

Rust chose a good in-between (the "?" unwrapping syntax). In mid or low level code, anything can still fail, but I suspect the performance impact of supporting exceptions or similar for basic operations (integer overflow, div by 0, etc) wouldn't be worthwhile vs just crashing the program or doing something else. Interestingly, Rust doesn't crash in this case: https://doc.rust-lang.org/book/ch03-02-data-types.html

Post reply on HN