Access Denied
You don't have permission to access "http://www.nsa.gov/Press-Room/Press-Releases-Statements/Pres..." on this server.
Judging from the 409 comments right now it seems I am the only one have this problem?
The Case for Memory Safe Roadmaps
421–427 of 427 posts
Re: The Case for Memory Safe Roadmaps
#422Earlier quoted context omitted.
The industry did not abandon C and C++ for Ada in the past, likely it will do the same to Rust. Not to mention C and C++ are both evolving and their toolchains are getting much better nowadays. After using Rust for a while, I actually decided to stay with to c/c++ for the rest of my career.
> I actually decided to stay with to c/c++ for the rest of my career. Care to expand?
I’m not op of course, but from a career perspective you have to make choices based on what will give you the most opportunities in the future.
Right now Rust is technically safer language but it doesn’t have the same amount of job postings and career opportunities as C++. That’s just an inertia problem.
The conundrum is if you jump in early and risk the language becoming yet another language or do you wait and see.
I haven’t coded C++ in 4 years, but my understanding is that the language is evolving to answer the threat Rust poses to it.
Re: The Case for Memory Safe Roadmaps
#423Earlier quoted context omitted.
Go is memory safe, that post does not means anything in real life scenario. Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.
The same author has a post from 2022 [1]. > Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity. 1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
Wow, that's super interesting. As you say, it's a contrived CTF example, but I'm pretty shocked that it's possible to read and write arbitrary process memory without importing any packages (especially unsafe, of course).
I'm also surprised that a fix has been theorized at least as far back as 2010[1], but not implemented. Is adding one layer of internal pointer redirection for interfaces, slices, and strings really that much of a performance concern?
Re: The Case for Memory Safe Roadmaps
#424Earlier quoted context omitted.
Write javascript engines in memory safe languages. I'd vote for rust as rust and javascript's APIs are pretty similar in style, structure, consistency and security/other issues that are not memory safety. On that note, try valgrind on existing javascript engines, you might be "entertained". (I certainly was, but that was some years back.
How are Rust and JS APIs similar, and why would it matter? AFAIK the only competitive JS engines written in memory safe languages are GraalJS and other JS-on-the-JVM runtimes. GraalJS has the advantage of being fully up to date, not having any memory unsafe code in it (the JIT compiler that makes it fast is a separate module, also written in a memory safe language, and the JS impl does not have low level code in it).…
Rust and JS - er in short, there's a lot more to security than "memory safety". But then I've been in groups burned by NPM hacks in the past. I've tried Rust some but it looks like the same problems yet again. I'm wary, and going to give it time to mature - it's not interesting enough on its own - especially for someone more used to embedded programming spaces (C centric spaces, for good reasons).
As for the second - good to know! Seriously appreciate knowing that - not sure if/when I'll need it myself, but it's good to hear, and good that it's visible here!
Re: The Case for Memory Safe Roadmaps
#425Earlier quoted context omitted.
I was shocked to learn that reaching an end of a function without returning is actually UB and the compiler doesn't stop you; only warns. For example: ``` class Foo; Foo get_foo() { std::cout int main() { const auto foo = get_foo(); } ```
(HN weak markdown, indent 2 spaces for code-block)
noted for next time, thanks
Re: The Case for Memory Safe Roadmaps
#426Earlier quoted context omitted.
so what you’re saying is proper C++ is fine?
What I'm saying is that if you are sufficiently smart then you could concievably write perfectly safe C++. But since almost no one in practice has ever been able to be sufficiently smart consistently enough to ship C or C++ code that doesn't have memory safety issues, I don't trust anyone to do so and would rather people stop writing stuff in them when there are better languages to use where I don't have to trust you…
Here’s what Stroustrup says:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p26...
Re: The Case for Memory Safe Roadmaps
#427Earlier quoted context omitted.
>Java it's a pest fest for exploits. Sure, if you haven't used it since the nineties and pay zero attention to new development.
I’ve only used Java in the last ten years. I helped deal with the log4j incident at a few companies. We specifically had to patch systems that were running newer versions of Java and older versions of Spring. The exploit relied on a new method of adding code to the JVM at runtime that newer versions of Spring had locked down to prevent people from using. I’ve never seen an explanation for why this mechanism was added…
The fact that everyone in these comments points at the one major incident in years is more telling than anything else.