when a CVE is discovered that is caused by a structural issue, after the first hotfix is issued new CVEs will keep popping up immediately after until the structural issue is fixed.


Yes, log4j is currently very instructive when it comes to format string parsing and interpretation.

But I'd posit that NULL dereference or off-by-one errors in C are structural issues in every C and C++ programme that we are trained not to see

the amount of times i've talked to a C programmer who was convinced they would never make such mistakes and it's all those other C programmers who produce all these bugs

@meena as a C programmer I would be shocked if there isn't at least one array indexing bug in my current project

@imyxh every time i looked at a trivial C programme of mine thru valgrind and it had no holes i was very, very surprised.

@meena Fuzzing has fundamentally broken the CVE system, because every minor bug, no matter how difficult to exploit in the real world, is treated exactly the same as an actually-proven RCE. And obnoxious programming language evangelists clearly *love* to use this to shit on people

@n if your software can't handle shit input don't connect it to the internet.

@n @meena CVEs usually come with a severity score attached.

And just because something isn't an RCE doesn't mean it isn't as serious. If I can DOS attack a heart monitoring device by sending it spicy strings over the network repeatedly, I'd call that pretty bad. Considering, that fuzzers most often find crashes, it's sensible to treat these as critical by default.

@n @meena Decades of experience have shown us that it is practically impossible to write secure and moderately sized software in languages like C and C++.

With the ever increasing digitalisation of the world, people continuing to use those languages for critical software components despite that is a thing worth pointing out.

@johannes @n @meena what other languages would you suggest, then?

I won’t argue that it’s easy to leave holes in C/++ programs. Cuz it is. It’s a mid level language that can have lots of lower level control.

That being said, that control is important in some use cases. And the speed can be really important too.

I don’t disagree that giant security holes are bad. But C is very deeply engrained in the industry and hard to replace at the drop of a hat.

@wholesomedonut here's a dangling pointer, because n@ deleted their post(s)

please don't @ them anymore.

either way, i'm thoroughly enjoying @johannes's links, and i'm currently reading: alexgaynor.net/2019/apr/21/mod

And if you ever wondered why C is so fast, maybe you should read: m-cacm.acm.org/magazines/2018/

@meena Yes. C and C++ are big problems and we are creating a legacy problem way bigger than that of COBOL. The tools for safe(r) code are there, they are called Go (which is at least more useful in userspace than C++) and Rust, which is safer than C in Kernel (or trusted/reliable/... user space applications).

New code should always be developed using a safe(r) language, ideally everything in rust, but that is unrealistic.

I mean... JavaScript is its own legacy problem and growing fast...

@snaums having worked on a relatively large code base in Go, i find it inadequate. The error handling, kind of the most important aspect for network code, which Go long billed itself to be especially suited for, is abysmal in Go.

For complex network software i recommend Elixir / Erlang. Rust too has excellent error handling. And it's getting better at async code, too. However, i wouldn't recommend Rust to replace C, only C++.

For people looking for a good alternative to C in a systems programming context, i recommend looking into Zig.

@meena Error handling in Go is a bit explicit. I miss exceptions too, yes. But I like how useful Go feels in relation to C++. Garbage Collected and loads of stuff built in, that make my life a bit easier.

With rust.. if you want a language, that forbids all the fun "shooting in the leg"-stuff, then use Rust. While I see, that some (most) C/C++ developers will never use or appreciate rust, I think at least in Kernel code Rust is a very strong contender. More useful and more safe than C.

@snaums i don't think that Exceptions are always a good way to handle errors.

Joe Duffy has written a lot about handling errors (in Midori)

Also see Common Lisp's error handling and Erlang's

the fact that you can just not handle Errors, and the fact that Error handling is always the same pattern that cannot be sensibly abstracted is just not ergonomic.

Just think about how much code is error handling.
How much of it is handling the same type of error? why?
now go back and (re)read Joe Duffy's article.

misinfo but kinda true 

@meena it's called C Vulnerabilities and Exposures for a reason

misinfo but kinda true 

@f0x did you just tell my own joke back to me? :P

misinfo but kinda true 

@meena oops lol I totally read over the image

@meena Though is it necessarily a structural issue which needs to be fixed when its kinda important to the programming language itself to allow such low level access?

@x44203 then we need to reevaluate if C or any such language is the right tool to programme large scale programmes or widely used libraries.

It's one thing to write a small 500 line long tool that you can completely hold in your head, and that valgrind can fully evaluate. But should we really be writing regex libraries or mail servers in this language?

It's like using a stripped down military bus as schoolbus, or instead of having a lift that goes down, we insert a mattress. Fast and cheap. And hardly anyone dies – most of the time.

@meena Hm, I guess maybe a RegEx parser could be written in a language thats as fast as C/C++ but doesn't have these issues, yeah (though it shouldn't be any slower, especially if its used on a large scale, that would just be such a huge waste of resources)

@x44203 maybe if we built computer architectures optimized for anything other than C m-cacm.acm.org/magazines/2018/ we could have fast libraries or programmes written in any other language?

@meena I agree that these are severe problems, but you can mitigate them, at least in C++. First, don't do manual memory management except in the small part of a program where you really need it (if, in fact, you do). For everything else, use STL containers, smart pointers, etc. Second, establish the convention that any pointer must be checked against nullptr before being used; if you want to pass by reference, use a reference, not a pointer. Null references are forbidden by the language.

@markusl yes, modern C++ is a whole different world. However, the tricky bit is securing the boundaries to C libraries, especially when it comes to String handling.

Rust does a lot correct here that C++ cannot do, due to its backwards compatibility to C

Sign in to participate in the conversation
Cathode Church

A place for trans makers, coders, tinkerers and dreamers.