311–320 of 427 posts
I'm cynically thinking "because they can now target the runtimes instead, and get far more value from their exploits".
One wolf that wants to help ensure that American computers are secure
And one wolf that wants to hoard as many 0-days as possible
Earlier quoted context omitted.
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...
Go was released in 2009 and I've never heard about any exploit and what not , by the way this is known and by design it's not new. It's all about the multi word for interface. I mean if in 14 years there was nothing it's a proof that it's not an issue. Even the attacker ack that it's not a threat. "As said before, while a fun exercise it's pretty useless in the current Go threat mode"
Or bash before shellshock
I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). no wonder so many bugs here and there.
Back in the day people with SVN/CVS commit access would push directly to the main branch after testing locally, and testing would be done as part of preparing a release, so it was more necessary to have a "safety" period where new people could get used to the new codebase.
Earlier quoted context omitted.
Fortran does not end up where I'm too worried about its security. C and C++ does. At the scale I'm talking about I'm not sure we'd even say Fortran is "in use". Assembly is in use, yes, but in 2023 I feel there is generally an understanding of the risks and I haven't seen the "write everything in assembly" crew in about 15 years. The problem is that there's still too many programmers blithely using C and C++ without…
SQLite is able to carry most of the justification for C itself at this point. Duplicating the DO-178B certification that it has obtained in an endorsed language will be an incredible burden for any who attempt it.
Earlier quoted context omitted.
> Rust certainly performs runtime bounds-checking as well as some other tasks, so there is runtime code (even if it's just compiled into executables.) I don't think I've ever seen anyone reference "C with bounds checks enabled" as "having a runtime". Does having stack probes also imply having a runtime? I guess I'd be less surprised if it had been worded as "some mitigations/features have a runtime cost". > If you wa…
For sure C programs have a runtime. I'm debugging an issue right now that is to do with Windows not shipping VCRUNTIME140_1.DLL on out-of-the-box or old versions of Win10, so in that case it's very clear because you can make C programs that won't start due to a missing runtime library. The runtime isn't all that large but every OS has one. On UNIX it's spread over libc, libpthread, libgcc, libm and so on. On Linux st…
Earlier quoted context omitted.
Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.
This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc e…
Because that's what "safe" in Rust means. No memory safety errors, no undefined behaviour.
Earlier quoted context omitted.
It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
That's fine. Safety with concurrency doesn't exist in any language. Only rust is special in that it tries to provide safety with concurrency as well. I haven't seen any other language besides rust actually do this. The reason is obvious. There's a high cost to this type of safety. Rust is hard to use and learn and many times it's safety forces users to awkwardly organize code. And there's still the potential for race…
Earlier quoted context omitted.
The article mentions: > Memory safety vulnerabilities are coding errors affecting software’s memory management code in which memory can be accessed, written, allocated, or deallocated in unintended ways. How can you do any of this without software running in the local machine? Honestly asking.
To take a very simple example (which won't work on modern OS with ASLR): 1. You have a service that takes some user input 2. The service allocates a buffer on the stack for 20 bytes (the max input allowed) 3. Service doesn't actually validate that the user input is 4. It writes the input into the buffer, but keeps writing past the end of the buffer. 5. It eventually overwrites the return pointer so now the user input…