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

91–100 of 177 posts

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

#91

Post by kelnos »

VancouverMan wrote: post #62
stouset wrote: post #52

Earlier quoted context omitted.

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.

I wouldn't call it "censorship", but sure, let's say it is.

There's a reason why "this is the exception that proves the rule" is a common saying. Picking out one exceptional example of something, and using that to argue against a general point, is at best lazy, and at worst actively dishonest. I'm fine with those kinds of comments being "censored". They -- and their replies that call people out for doing this -- are boring and don't further discussion.

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

#92

Post by kelnos »

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

No, that's a security vulnerability waiting for someone to exploit.

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

#93

Post by kelnos »

dheera wrote: post #84
koolba wrote: post #77

Earlier quoted context omitted.

> If I access memory I didn't allocate the OS shuts the program down. The real problem is when you access memory that did allocate.

So we need a new flag for gcc that writes zeros to any block of allocated memory before malloc returns, not a new language.

That wouldn't make it safe. It would just make it crash in a different way, and still be vulnerable to exploitation by an attacker.

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

#94

Post by kelnos »

cogman10 wrote: post #36
luma wrote: post #30

Earlier quoted context omitted.

It's present on loads of systems, it's a very common service to offer, it's a reasonably well-constrained use case, and the fact that nobody thinks about it might be a good reason to think about it. They can't boil the ocean but one service at a time is a reasonable approach. I'll flip the question around, why not start at ntpd?

> I'll flip the question around, why not start at ntpd? Easy, because there are loads of critical infrastructure written in C++ that is commonly executed on pretty much every VM and exposed in such a way that vulnerabilities are disasterous. For example, JEMalloc is used by nearly every app compiled in *nix. Perhaps systemd which is just about everywhere running everything. Maybe sshd, heaven knows it's been the root…

> For example, JEMalloc is used by nearly every app compiled in nix.*

JEmalloc is used by very very very few apps compiled for *nix. That's a conscious decision that an app developer needs to make (and few would bother without specialized needs) or a distro packager needs to shoehorn into their package builds (which most/all would not do).

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

#95

Post by maxbond »

landmarker11 wrote: post #69
jaas wrote: post #51

Earlier quoted context omitted.

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]

That's a bummer honestly, I would encourage you not to let Internet flamewars color your decisions about what languages you might learn. The well is seriously poisoned with regards to Rust in this community. That's more of a reflection on HN than the value of Rust as a technology or even the Rust community.

Don't learn Rust if you aren't interested, it's not a one true language, but don't cheat yourself on engaging with an interest because HN struggles to discuss it amicably.

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

#96

Post by kelnos »

chaoskitty wrote: post #78
dequan wrote: post #74

Earlier quoted context omitted.

I agree that it would be great if the ecosystem was a bit slower to use every new version and it does seem like things are beginning to tend in that direction as many foundational crates have begun declaring MSRVs of !LATEST. However I don't think the pace of updates really changes anything in terms of tool chain security. If Rust decided to go to a 36 week release cycle, each release would just have 6x as much stuff…

Serious question: why does it need to change so much and so often? I know nothing about rust development, so I'm curious about why it's worlds different from the development of other toolchains.

Consider that there's still a good amount of work being done on gcc & clang's C++ frontend despite how old these languages are. Wouldn't it stand to reason that Rust, a comparatively very new language, would have new features and compiler improvements added at an even faster pace?

I suspect if you were to look at other reasonably popular languages that are of the same era, you'll see a similar level of changes.

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

#97

Post by yjftsjthsd-h »

hedora wrote: post #83
cogman10 wrote: post #36

Earlier quoted context omitted.

> I'll flip the question around, why not start at ntpd? Easy, because there are loads of critical infrastructure written in C++ that is commonly executed on pretty much every VM and exposed in such a way that vulnerabilities are disasterous. For example, JEMalloc is used by nearly every app compiled in *nix. Perhaps systemd which is just about everywhere running everything. Maybe sshd, heaven knows it's been the root…

There’s a nice pure-rust ssh client/server already. Systemd should just be scrapped. This week’s wtf “systemd-tmpfile —-purge” intentionally changed its behavior to “rm -rf /home”. Confirmed not-a-bug. There are dozens of other comparable screwups in that stack, even ignoring the long list of CVEs (including dns and ntp, I think). Rust can’t fix that. I haven’t heard of any issues with jemalloc, though that seems rea…

> There’s a nice pure-rust ssh client/server already.

Prod ready, audited, non-buggy in actual use? And if so, do you have a link so I can start test-deploying it?

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

#98

Post by Spivak »

Gigachad wrote: post #88
motrm wrote: post #19

Earlier quoted context omitted.

If the pieces of state are all well known at build time - and trusted in terms of their content - it may be feasible to print out JSON 'manually' as it were, instead of needing to use a JSON library, print "{" print "\"some_state\": \""; print GlobalState.Something.to_text(); print "\", "; print "\"count_of_frobs\": "; print GlobalState.FrobsCounter; print "}"; Whether it's worth doing this just to rid yourself of a…

This looks like the exact kind of thing that results in unexpected exploits.

Hand rolled JSON input processing, yes. Hand rolled JSON output, no.

You're gonna have a hard time exploiting a text file output that happens to be JSON.

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

#99

Post by stouset »

chaoskitty wrote: post #78
dequan wrote: post #74

Earlier quoted context omitted.

I agree that it would be great if the ecosystem was a bit slower to use every new version and it does seem like things are beginning to tend in that direction as many foundational crates have begun declaring MSRVs of !LATEST. However I don't think the pace of updates really changes anything in terms of tool chain security. If Rust decided to go to a 36 week release cycle, each release would just have 6x as much stuff…

Serious question: why does it need to change so much and so often? I know nothing about rust development, so I'm curious about why it's worlds different from the development of other toolchains.

> why does it need to change so much and so often

I think a lot less is changing than you seem to think is.

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

#100

Post by wbl »

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…

The network is just a bunch of strangers in a meet me room.
Post reply on HN