Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This shouldn't have happened: A vulnerability postmortem

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

251–260 of 499 posts

Re: This shouldn't have happened: A vulnerability postmortem

#251

Post by FpUser »

ransom1538 wrote: post #120
slownews45 wrote: post #13

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

Dumb question: Do we need to use C++ anymore? Can we just leave it to die with video games? How many more years of this crap do we need before we stop using that language. Yes I know, C++ gurus are smart, but, you are GOING to mess up memory management. You are GOING to inject security issues with c/c++.

>"Dumb question..."

Yep

Re: This shouldn't have happened: A vulnerability postmortem

#252

Post by UncleMeat »

josephg wrote: post #202
jmull wrote: post #190

Earlier quoted context omitted.

It's more of whether Rust fits into every workflow, project, team, build chain, executable environment, etc., that C does. Does rust run everywhere C runs? Does rust build everywhere C builds? Can rust fit into every workflow C does? Are there rust programmers with all the same domain expertise as for C programmers? (Not to mention, the question here isn't whether to write in rust or write in C. It's whether to leave…

Rust does not run everywhere C runs. At least not yet - there's a couple efforts to allow rust to compile to all platforms GCC supports[1]. But we don't need rust to work everywhere C works to get value out of a native rust port of OpenSSL. Firefox and Chrome (as far as I know) only support platforms which have rust support already. As I said in another comment, in my experience, porting code directly between two C-l…

Speaking as a static analysis person, C and C++ are unholy nightmares for static analysis tools to work with. Even very very basic issues like separate compilation make a mess of things. If the world can successfully shift away from these languages, the supporting tools won't have trouble keeping up.

Re: This shouldn't have happened: A vulnerability postmortem

#253

Post by aoetalks »

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

Re: This shouldn't have happened: A vulnerability postmortem

#255

Post by josephg »

FpUser wrote: post #238
josephg wrote: post #202

Earlier quoted context omitted.

Rust does not run everywhere C runs. At least not yet - there's a couple efforts to allow rust to compile to all platforms GCC supports[1]. But we don't need rust to work everywhere C works to get value out of a native rust port of OpenSSL. Firefox and Chrome (as far as I know) only support platforms which have rust support already. As I said in another comment, in my experience, porting code directly between two C-l…

>"1kloc / day is a reasonable ballpark figure, landing us at about one person-year to port boringssl to rust." Porting 1k lines a day, testing and catching and fixing errors to language with incompatible memory model and doing it for a year is insanity. Programmers who propose this kind of productivity most likely have no idea about real world.

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 much code to write from scratch in a day, or code review. I claim it’s not a lot of code to port - especially once you’re familiar with the code base and you’ve built some momentum. The hardest part would be mapping C pointers into rust lifetimes.

> most likely have no idea about real world.

I have no doubt this sort of speed is unheard of in your office, with your processes. That doesn’t tell us anything about the upper bound of porting speed. If you have more real world experience than me, how fast did you port code last time you did it?

Mind you, going hell to leather is probably a terrible idea with something as security sensitive as BoringSSL. It’s not the project to skip code review. And code review would probably take as long again as porting the code itself.

Re: This shouldn't have happened: A vulnerability postmortem

#256

Post by ndesaulniers »

jmull wrote: post #155

To me, PORT_Memcpy is one problem here. There are two buffers and one size -- the amount of memory to copy. There should be PORT_Memcpy2(pDest, destSize, pSource, numBytesToCopy) (or whatever you want to call it) which at least prompts the programmer to account for the size destination buffer. Then flag all calls to PORT_Memcpy and at least make a dev look at it. (Same for the various similar functions like strcpy, e…

numBytesToCpy != sourceSize

Otherwise that's a potential read out of bounds.

Re: This shouldn't have happened: A vulnerability postmortem

#257

Post by pbohun »

fleventynine wrote: post #172
throwaway894345 wrote: post #158

Earlier quoted context omitted.

If your "deterministic amount of time" can tolerate single-digit microsecond pauses, then Go's GC is just fine. If you're building hard real time systems then you probably want to steer clear of GCs. Also, "developer velocity" is an important criteria for a lot of shops, and in my opinion that rules out Rust, C, C++, and every dynamically typed language I've ever used (of course, this is all relative, but in my exper…

If it can really guarantee single-digit microsecond pauses in my realtime thread no matter what happens in other threads of my application, that is indeed a game changer. But I'll believe it when I see it with my own eyes. I've never even used a garbage collector that can guarantee single-digit millisecond pauses.

I found this go.dev blog entry from 2018. It looks like the average pause time they were able to achieve was significantly less than 1ms back then.

"The SLO whisper number here is around 100-200 microseconds and we will push towards that. If you see anything over a couple hundred microseconds then we really want to talk to you.."

https://go.dev/blog/ismmkeynote

Re: This shouldn't have happened: A vulnerability postmortem

#258

Post by ndesaulniers »

rurban wrote: post #147

Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined. The applause goes to the glibc maintainers, who still think they are above that.

Doesn't memcpy_s not take into account the sources size though? You could still read past the end of an object with it, right?

Re: This shouldn't have happened: A vulnerability postmortem

#259

Post by saghm »

jschwartzi wrote: post #90
throwaway894345 wrote: post #61

Earlier quoted context omitted.

Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.

Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent month…

> Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case

On the other hand, more modern languages like Rust and Go tend to have a single standard library and compiler that can be used across basically any common operating system, whereas trying to use gcc/libstdc++ or clang/libc++ on Windows can be an ordeal, and using MSVC on Unix is essentially not an option at all. Cross compilation for other architectures might be a bit more work, but the majority of developers don't have to worry about that very much, whereas support across Linux, MacOS, and Windows is a lot more common.

Re: This shouldn't have happened: A vulnerability postmortem

#260

Post by Enhex »

slownews45 wrote: post #13

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

this is C code. stuff like void*, union and raw arrays do not belond in modern C++. while C++ is compatible with C it provides ways to write safer code that C doesn't. writing C code in a C++ project is similar to writing inline assembly.
Post reply on HN