131–140 of 177 posts
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.
Earlier quoted context omitted.
I don’t think our dependency tree is perfect, but I think our dependencies are reasonable overall. We use JSON for transferring metrics data from our NTP daemon to our prometheus metrics daemon. We’ve made this split for security reasons, why have all the attack surface of a HTTP server in your NTP daemon? That didn’t make sense to us. Which is why we added a readonly unix socket to our NTP daemon that on connecting…
If you're only dumping a string, couldn't you replace this dependency with some string concatenation?
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.…
It continues to astonish me how little people care (i.e., it triggers the $%&@ out of me). I really appreciate the professionalism and cool rationale when faced with absolute ignorance of how shaky a foundation our "modern" software stack is built upon. This is a huge service to the community, kudos to you and many others slowly grinding out progress!
Seems no digital system is truly secure. Moving foundational code to memory safe seems like a good first step.
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.
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…
Really? To me it's pretty obvious that not escaping properly is the issue, and therefore the same issue applies wherever you need escaping. I don't think I've ever heard anyone say that SQL itself was the problem with SQL injection. (Although you certainly could argue that - SQL could be designed in such a way that prepared statements are mandatory and there's simply no syntax for inline values.)
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?
> yet another poorly thought out, ad-hoc homegrown config file format OpenBSD style ntpd.conf: servers 0.gentoo.pool.ntp.org servers 1.gentoo.pool.ntp.org servers 2.gentoo.pool.ntp.org servers 3.gentoo.pool.ntp.org constraints from "https://www.google.com" listen on * I mean, there's always the possibility that they used a common, well known and pretty decent config file format. In this particular case, this shouldn'…
Earlier quoted context omitted.
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 .
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?
JSON is a terrible configuration format since it doesn't support comments.
Unlike say, coreutils, ntp is something very far from being a solved problem and the memory safety of the solution is unfortunately going to play second fiddle to its efficacy. For example, we only use chrony because it’s so much better than whatever came with your system (especially on virtual machines). ntpd-rs would have to come at least within spitting distance of chrony’s time keeping abilities to even be up for…
You might be doing too much work at the wrong level of abstraction. VMs should use host clock synchronization. It requires some work and coordination, but it eliminates the need for ntp in VMs entirely. Hosts should then be synced using PTP or a proper NTP local stratum (just get a proper GNSS source for each DC if you have then funds). https://tsn.readthedocs.io/timesync.html Deploy chrony to bare metal servers wher…
But last time I said that with some pretense of authority, someone shoved me a whitepaper from VMware that said the opposite. Best practice was stated be to sync each guest individually with a completely virtual clock.
I'm not sure I agree, but at least I try to be open to be possibility that there are situations I had not considered. If anyone else knows more about this, please share.
Earlier quoted context omitted.
> yet another poorly thought out, ad-hoc homegrown config file format OpenBSD style ntpd.conf: servers 0.gentoo.pool.ntp.org servers 1.gentoo.pool.ntp.org servers 2.gentoo.pool.ntp.org servers 3.gentoo.pool.ntp.org constraints from "https://www.google.com" listen on * I mean, there's always the possibility that they used a common, well known and pretty decent config file format. In this particular case, this shouldn'…
That config file perfectly illustrates the point. There's no need for it to be custom, and require me to waste time learning its syntax when it could just be JSON or TOML. Honestly I would even take YAML over that and YAML is the worst.
The configuration object will always and by definition be proprietary to ntp. Expressing it as plain text allows for a trivial parser, without any of the security implications of wrapping it in a general language language ("should this string be escaped?", "what should we do with invalid utf8?").
The more simple format has survived over thirty years, is trivial to parse by anyone, and does not bring any dependencies that needs maintaining. That should count for something.