Earlier quoted context omitted.
Ring would be cool if not for https://github.com/briansmith/ring#versioning--stability
This sounds like a nightmare for any downstream users of this library. Any one of those bullet points in that section would be a major concern for me using it in anything other than a hobby project, but all of them together seem almost willfully antagonistic to users. This is especially true given it’s a security library, which perhaps more than any other category I would want to be stable, compatible, and free of su…
This shouldn't have happened: A vulnerability postmortem
271–280 of 499 posts
Re: This shouldn't have happened: A vulnerability postmortem
#272Earlier quoted context omitted.
> Or are C/C++ benefits just too high to ever give up? FFI is inherently memory-unsafe. You get to rewrite security critical things from scratch, or accept some potentially memory-unsafe surface area for your security critical things for the benefit that the implementation behind it is sound. This is true even for memory-safe languages like Rust. The way around this is through process isolation and serializing/deseri…
> FFI is inherently memory-unsafe Maybe this specific problem needs attention. I wonder, is there a way we can make FFI safer while minimizing overhead? It'd be nice if an OS or userspace program could somehow verify or guarantee the soundness of function calls without doing it every time. If we moved to a model where everything was compiled AOT or JIT locally, couldn't that local system determine soundness from the…
Re: This shouldn't have happened: A vulnerability postmortem
#273When will we switch to memory safe (but reasonably performant) languages like Go/Rust/C#? Performance critical sections could remain in C/C++, but MOST code doesn’t need the kind of performance C/C++ provides. Hopefully C/C++ will go the way of assembly: present in TINY doses.
I don't think you need to explain to Mozilla about Just Rewriting It to Rust
Re: This shouldn't have happened: A vulnerability postmortem
#274I think the main surprising thing here is that people are putting smallish arbitrary limits on the sizes of inputs that they let their fuzzer generate. With the benefit of a little hindsight, that does feel rather like saying "please try not to find any problems involving overflows".
Re: This shouldn't have happened: A vulnerability postmortem
#275A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…
No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long.
Re: This shouldn't have happened: A vulnerability postmortem
#276Re: This shouldn't have happened: A vulnerability postmortem
#277Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…
You don't need to explain to Mozilla about rewriting code from C/C++ to Rust.
Re: This shouldn't have happened: A vulnerability postmortem
#278Earlier quoted context omitted.
There’s an old saying attributed to Abe Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” I contend that most software engineers (and most engineering houses) don’t spend any time sharpening the axe. Certainly not when it comes to optimizing for development speed. Nobody even talks about deliberate practice in software. Isn’t that weird? 1000 lines of code is way too…
I'm also really skeptical that one could maintain 1K/lines per day for more than a couple weeks if that. There have been a lot of studies that measure average output of new code at only ~15 or so LOC/day. One can manage more on small projects for a short amount of time. I could believe porting between two C-like languages is 1 order of magnitude easier, but not 2. Std library differences, porting idioms, it adds up.…
I agree with that LOC/day output figure for new code. I've been averaging somewhere around that (total) speed for the last few months - once you discard testing code and the code I'll end up deleting. Its slower than I usually code, but I'm writing some very deep, new algorithmic code. So I'm not beating myself up about it.
But porting is very different. You don't need to think about how the code works, or really how to structure the data structures or the program. You don't need much big picture reasoning at all, beyond being aware of how the data structures themselves map to the target language. Most of the work is mechanical. "This array is used as a vec, so it'll become Vec. This union maps to an enum. This destructor should actually work like this...". And for something like boringSSL I suspect you could re-expose a rust implementation via a C API and then reuse most of the BoringSSL test suite as-is. Debugging and fuzz testing is also much easier - since you just need to trace along the diff between two implementations until you find a point of divergence. If the library has tests, you can port them across in the same way.
The only data point I have for porting speed is from when I ported chipmunk2d in a month from C to JS. Chipmunk only has a few data structures and it was mostly written by one person. So understanding the code at a high level was reasonably easy. My ported-lines-per-day metric increased dramatically throughout the process as I got used to chipmunk, and as I developed norms around how I wanted to translate different idioms.
I have no idea how that porting speed would translate to a larger project, or with Rust as a target language. As I said, I'd love to hear some stories if people have them. I can't be the only one who's tried this.
Re: This shouldn't have happened: A vulnerability postmortem
#279Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…
My language selection checklist: 1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript. 2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++. 3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage c…
If no, then just use a GC'd language and preallocate everything and use object pooling. You won't have GC pauses because if you don't dynamically allocate memory, you don't need to GC anything. And don't laugh. Pretty much all realtime systems, especially the hardest of the hard real time systems, preallocate everything.
Re: This shouldn't have happened: A vulnerability postmortem
#280Since this comes up whenever there is a Project Zero article, here is a summary I made in summer 2020 on the distribution of the bugs they find/report: Since this always comes up, here's an overview I made several weeks ago about where Project Zero focuses their efforts: All counts are rough numbers. Project zero posts: Google: 24 Apple: 28 Microsoft: 36 I was curious, so I poked around the project zero bug tracker t…
Are you sure the numbers track where they put effort? I can think of a couple of confounding factors (including P0 methodologies, and number of low-hanging[1] bugs in target products)
1. Relatively speaking