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

61–70 of 177 posts

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

#61

Post by dheera »

ghshephard wrote: post #59
dheera wrote: post #55

Earlier quoted context omitted.

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/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety?

(Unless you're running it on bare metal ...)

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

#62

Post by VancouverMan »

stouset wrote: post #52
kaql wrote: post #45

Earlier quoted context omitted.

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

When even a very small number of downvotes here can result in a comment's text being coloured in a way that makes it harder to read, or even nearly impossible to read in extreme cases, I think it's reasonable to equate downvoting with censorship.

Censorship doesn't require content to be completely hidden or blocked; even just partially obscuring the content in some way is still censorship.

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

#64

Post by rictic »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

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/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

Memory errors can be exploited by a clever adversary to control your process in a variety of unpleasant ways, see: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_...

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

#65

Post by [deleted] »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

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/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

[deleted]

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

#66

Post by hot_gril »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

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/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

That's not what memory safety refers to.

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

#67

Post by orf »

itishappy wrote: post #16
orf wrote: post #15

Earlier quoted context omitted.

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

It uses TOML for configuration.

Cool, thats why this is a hypothetical question

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

#68

Post by kortilla »

dheera wrote: post #61
ghshephard wrote: post #59

Earlier quoted context omitted.

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/#:... .

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

This is not a question for HN at this point. It’s like asking why SQL query forming via string concatenation of user inputs is unsafe.

Google it, C memory boundary issues have been a problem for security forever.

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

#69

Post by landmarker11 »

jaas wrote: post #51
landmarker10 wrote: post #42

Earlier quoted context omitted.

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

[dead]

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

#70

Post by kortilla »

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…

Ntp does not use TLS widely. It’s also a UDP protocol which makes it subject to spoofing attacks without a compromised network (no protection from kernel network stack verifying TCP sequence numbers).
Post reply on HN