Comment by jaas | Hacker News Reader

Comment by jaas | Hacker News Reader

Parent Full thread

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. A quick Google for NTP vulnerabilities will show you that there are plenty of memory safety vulnerabilities lurking in C NTP implementations:

https://www.cvedetails.com/vulnerability-list/vendor_id-2153...

Some of these are severe, some aren't. It's only a matter of time though until another severe one pops up.

I don't think any critical service on a network boundary should be written in C/C++, we know too much at this point to think that's a good idea. It will take a while to change that across the board though.

If I had to pick the most important thing in the context of Let's Encrypt to move to a memory safe language it would be DNS. We have been investing heavily in Hickory DNS but it's not ready for production at Let's Encrypt yet (our usage of DNS is a bit more complex than the average use case).

https://github.com/hickory-dns/hickory-dns

Work is proceeding at a rapid pace and I expect Hickory DNS to be deployed at Let's Encrypt in 2025.

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!

Lol, shaky indeed. A business person once said, "can you imagine if machine engineer (like auto makers) behave like software engineering?".

Seems no digital system is truly secure. Moving foundational code to memory safe seems like a good first step.

That's because there is no such thing as "truly secure", there can only be "secure under an assumed threat model, where the attacker has these specific capabilities: ...". I agree that software engineering is getting away with chaos and insanity compared to civil or other engineering practices, which have to obey the laws of physics.

Remind me of the One World Trade Center rebuild, and "if you want a 747-proof building, you're building a bunker".

Translate the internet to the real world, and basically every building (IP address) is getting shot at, hit by planes, nuked, bioweapons are stuffed into the mail slot, and lock-picked all day, every day.

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

I would consider that serious attempts have been made since 1961, however all of them failed in the presence of a free beer OS, with free beer unsafe compilers.

The getting traction part is the relevance part.

Yeah, all previous attempts at making such a language lacked two things:

1. They didn't have a big, well-known, company name with good enough reputation to attract contributors.

2. They didn't have brackets.

Success was because traction, traction was because appeal, and appeal was mostly because those two things. Nothing else was new AFAIK.

I take a slightly different view of this, though I do not deny that those things are important. #1 in particular was important to my early involvement in Rust, though I had also tinkered with several other "C replacement" languages in the past.

A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kinda close to C performance" was a thing that was said, but wasn't really actually true. Or rather, it was true in a different sense: as computers got faster, more application domains could deal with some overhead, and so the true domain of "low level programming languages" shrunk. And so finally, Rust came along, being able to tackle the true "last mile" for memory unsafety.

Rust even almost missed the boat on this up until as late as one year before Rust 1.0! We would have gotten closer than most if RFC 230 hadn't landed, but in retrospect this decision was absolutely pivotal for Rust to rise to the degree that it has.

That wasn't the case of Modula-2, Ada or Object Pascal.

Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable.

Note that for all the hype, Zig is basically Modula-2 features with C syntax, to certain extent.

> not comming with an OS to make their use unavoidable.

Early MacOS did use Pascal, though IIRC not Object Pascal.

You can still find documentation for Macos toolkit with Pascal bindings.

This is a bit of a nostalgia trip for me as I owned a copy of this book way back in the 90's

https://developer.apple.com/library/archive/documentation/ma...

No shared mutable state in an imperative language is common, as are memory safe languages with performance close to C's? Didn't see the latter in the language shootout benchmarks, in fact Rust is much closer to C than the next closest thing

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

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.

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

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

Really, the problem is in combining tainted input strings with string concatenation. If you have certain guarantees on the input strings, concatenation can be safe. That said, I still wouldn’t use it since there are few guarantees that future code wouldn’t introduce tainted strings.

I think you have a missunderstanding on what memory safety is.

Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.

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

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

If only the very competent people that decided to create Rust had thought of asking you for the solution instead...

Have a little humility.

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.

We have that already. There are still other problems that exist.

Highly recommend Alex Gaynor's intro to memory unsafety https://alexgaynor.net/2019/aug/12/introduction-to-memory-un...

That's not what memory safety refers to.

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

They have been unsafe from their very early days, Multics got a higher security score than UNIX thanks to PL/I, and C.A.R Hoare has addressed C's existence on his Turing Award in 1980, while Fran Allen has also made similar remarks back in the day.

All of a sudden? They've been unsafe for decades, it's just that you had less of a choice then.

Because you can cast a pointer to a number and back again. Then you can stuff that value into index [-4] of your array. More or less.

Tcl

Reply on news.ycombinator.com