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

81–90 of 177 posts

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

#81

Post by 1over137 »

timmytokyo wrote: post #41
syncsynchalt wrote: post #25

Earlier quoted context omitted.

The biggest danger in NTP isn't memory safety (though good on this project for tackling it), it's (a) the inherent risks in implementing a protocol based on trivially spoofable UDP that can be used to do amplification and reflection and (b) emergent resonant behavior from your implementation that will inadvertently DDOS critical infrastructure when all 100m installed copies of your daemon decide to send a packet to N…

I really wish more internet infrastructure would switch to using NTS. It addresses these kinds of issues.

Never heard of it. Shockingly little on wikipedia for example.

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

#82

Post by sans-seraph »

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.

Let us be clear that the notion of "change" being referred to here is forward compatibility, not backward compatibility. The user is commenting on the fact that Rust library authors make use of new features as they become available, and as a result in order to compile Rust code you will often need a recent version of the compiler, or otherwise you will need to find an older version of the library in question.

In addition Rust was born from Mozilla and imitates Firefox's rapid release schedule of one release per six weeks. This does not mean that Rust releases are substantial or that they are traumatizing, only that they are frequent. The contract with users is that Rust releases must be painless so as to not fatigue users and discourage them from upgrading. The success of this painless upgrade strategy is proved by the fact that library authors are so quick to upgrade, as mentioned.

This is in contrast to other languages where historically a new version of their compiler might only be released as infrequently as once per three years. It seems that these languages have begun taking queues from Rust as even Java now releases once per six months.

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

#83

Post by hedora »

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…

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 reasonable (assuming calling rust from C doesn’t break compiler inlining, etc).

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

#84

Post by dheera »

koolba wrote: post #77
dheera wrote: post #61

Earlier quoted context omitted.

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

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

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

#85

Post by sans-seraph »

akaletF wrote: post #18
dralley wrote: post #14

Earlier quoted context omitted.

I would venture to say that most C programs don't check the return value of printf, including ones that ought not to be "toys"

I don't know. Most serious programs will use write() and then check the return value. In locations where it does not matter (say a test suite that is guaranteed to signal an error but an fprintf() error message could fail in theory) not checking is fine I think. You will not see the message if you get a panic either ...

> Most serious programs will use write() and then check the return value.

Similarly in Rust, serious programs will use writeln rather than println, and will receive the standard compiler warning if the Result produced by writeln is ignored.

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

#86

Post by cozzyd »

orf wrote: post #15
akira2501 wrote: post #6

Why does your ntpd have a json dependency?

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?

JSON is a terrible configuration format since it doesn't support comments.

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

#87

Post by forbiddenlake »

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…

> Confirmed not-a-bug.

Initially closed not a bug, but then Poettering overruled that decision and implemented a fix which is already released.

https://github.com/systemd/systemd/commit/e76015738942246db7...

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

#88

Post by Gigachad »

motrm wrote: post #19
danudey wrote: post #9

Earlier quoted context omitted.

This is a good question to ask, especially in the age of everything pulling in every possible dependency just to get one library function or an `isNumeric()` convenience function. The answer is that there is observability functionality which provides its results as JSON output via a UNIX socket[0]. As far as I can see, there's no other JSON functionality anywhere else in the code, so this is just to allow for easily…

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.

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

#89

Post by KMag »

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.

You'd probably want an alternative libc implementation rather than a compiler flag.

However, calloc everywhere won't save you from smashing the stack or pointer type confusion (a common source of JavaScript exploits). Very rarely is leftover data from freed memory the source of an exploit.

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

#90

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 the comments calling people out for doing this -- are boring and don't further discussion.

Post reply on HN