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

101–110 of 177 posts

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

#101

Post by t3rra »

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?

[flagged]

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

#102

Post by kelnos »

amiga386 wrote: post #23
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?

Poorly thought out, ad-hoc homegrown config file format, please. Every time. 1. Code doesn't change at the whims of others. 2. The entire parser for an INI-style config can be in about 20 lines of C 3. Attacker doesn't also get to exploit code you've never read in the third party dependency (and its dependencies! The JSON dependency now wants to pull in the ICU library... I guess you're linking to that, too) 4. Compl…

I feel like using the incomprehensibly error-prone and inscrutable sudoers format as an example kinda argues against your point.

(I do agree that JSON is a terrible configuration file format, though.)

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

#103

Post by kelnos »

skilled wrote: post #2

[flagged]

> I struggle to understand why they would say that as the opening statement in such a matter-of-fact manner.

Because it is a fact. An obvious, obvious fact to anyone who has been working in this ecosystem for any amount of time.

> Drinking the Rust kool-aid by the sound of it.

Would you say the same thing if they'd instead decided to use golang, zig, nim, ocaml, etc.? If not, maybe consider that your emotional stance around Rust is coloring your judgment.

Our modern systems are built on a house of cards where security is concerned. I agree that the "RiiR" meme is tiresome and dumb, but I'm tired of seeing report after report of new vulnerabilities found in foundational libraries and programs. The majority of those vulnerabilities are of the type that Rust won't even let you compile. Languages like C and C++ have their place, but for most applications, there are safer alternatives that don't require harsh compromises or significant trade offs.

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

#104

Post by TeMPOraL »

kortilla wrote: post #68
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 ...)

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.

> It’s like asking why SQL query forming via string concatenation of user inputs is unsafe.

To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache?

In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part.

--

[0] - https://en.wikipedia.org/wiki/Template_processor

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

#105

Post by codetrotter »

1over137 wrote: post #81
timmytokyo wrote: post #41

Earlier quoted context omitted.

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.

Yeah. Seems it doesn’t even have its own article there.

Only a short mention in the main article about NTP itself:

> Network Time Security (NTS) is a secure version of NTPv4 with TLS and AEAD. The main improvement over previous attempts is that a separate "key establishment" server handles the heavy asymmetric cryptography, which needs to be done only once. If the server goes down, previous users would still be able to fetch time without fear of MITM. NTS is currently supported by several time servers, including Cloudflare. It is supported by NTPSec and chrony.

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

#106

Post by codetrotter »

TeMPOraL wrote: post #104
kortilla wrote: post #68

Earlier quoted context omitted.

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.

> It’s like asking why SQL query forming via string concatenation of user inputs is unsafe. To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache? In my experience, very few people appreciate that the issue w…

The problem that causes it is in photo cases that a flat string representation kind of mixes code and data. And therefore escaping (such as not allowing quotes in the user input to terminate quotes in your query, or not allowing html tags to be opened or closed by user input, nor allowing html attributes to be opened or closed by the user input, etc) is needed.

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

#108

Post by whytevuhuni »

amiga386 wrote: post #23
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?

Poorly thought out, ad-hoc homegrown config file format, please. Every time. 1. Code doesn't change at the whims of others. 2. The entire parser for an INI-style config can be in about 20 lines of C 3. Attacker doesn't also get to exploit code you've never read in the third party dependency (and its dependencies! The JSON dependency now wants to pull in the ICU library... I guess you're linking to that, too) 4. Compl…

I once saw an .ini for a log parser:

    [Alarm]
    Name=Nginx Errors
    Pattern="[error] #: "
The thing worked. Without any errors. And yet it took:

    Pattern="[error]
..and then considered the rest of the line a comment. It didn't even error on the fact that the quotes were not closed.

Hand-rolling config formats is hard.

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

#109

Post by runiq »

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?

Tcl

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

#110

Post by rnijveld »

NelsonMinar wrote: post #7

I like the idea of NTPD in Rust. Is there anything to read about how well ntpd-rs performs? Would love a new column for chrony's comparison: https://chrony-project.org/comparison.html Particularly interested in the performance stats, how well the daemon keeps time in the face of various network problems. Chrony is very good at this. Some of the other NTP implementations (not on that chart) are so bad they shouldn't b…

In our internal testing we are very close to Chrony with our synchronization performance, some of our testing data and an explanation of our algorithm is published in our repository: https://github.com/pendulum-project/ntpd-rs/tree/main/docs/a...

Given the amount of testing we (and other parties) have done, and given the strong theoretical foundation of our algorithm I’m pretty confident we’d do well in many production environments. If you do find any performance issues though, we’d love to hear about them!

Post reply on HN