+++ Sudo team adopting Adobe's Flash player, uniting security with design +++

Could we please stop pretending, that the choice of language has no security impact:
https://sudo.ws/alerts/...

i disagree with you.
C makes it too easy to create security holes.

@stop
That doesn't sound like disagreement to me.

@Oktokolo some languages sre safer with little effort, therefore safer. If you are bending backwards to make it safe code, the language itself is not safe.

Can we please stop pretending that C is somehow flawed.

If you don't understand why C is like it is, you don't truly understand how computers work. Sorry, I said it.

@junon
It isn't flawed where unintended execution of user-provided code is okay or when the coder is only writing flawless code.

@Oktokolo You're saying all C programs allow unintended user code execution? That's a bit naive. Any language allows you to write CI/1RCE vulnerable code.

@junon
No, not all - only the ones which are executed on 99% of the internet infrastructure...

And there is a difference between "allows to write backdoors" and "Defaults to becoming a backdoor when you miss a bounds check".

@Oktokolo

> 99%

Do you have a source for this or are you just biased against C?

@junon
I am just biased from browsing cvedetails.com...

@Oktokolo Seeing as how C was the most prolific language for systems development (and still arguably is) outside of the Web world, that would make sense.

If you have 100,000 projects in C and 1000 in Rust, and Rust has 10 CVEs whereas C has 1000, C is statistically equivalent to Rust in terms of CVE rate.

That's an oversimplification but you must remember that pretty much the entire _world_ runs on C.

@junon
Yes, that is part of it.

But most of that software should not be written in a memory-unsafe language in the first place. Most of that software doesn't profit from being written in C or C++.

The Kernel isn't written in pure assembly.
Tools which could be easily written in Java (or any other strongly-typed memory-safe language) should not be written in C or C++.
You can perform RCE genocide by just not using memory-unsafe languages for tasks which don't need them.

@Oktokolo That's an incredibly naive and simply untrue assertion. Rust crates have a number of RCE CVEs already, for example. A language isn't magically bug free either. Compilers have been known to compile vulnerable code. Look at Zig, for example. The standard library is rife with DOS surface area.

Please don't say thing that you aren't sure about. It causes misinformation and creates danger and makes the lives of security researchers just a little harder.

@junon
Of course you can do unsafe stuff in Rust.
People are used to microoptimize the shit out of their code for no reason. Some of them really just can't resist loading the gun before cleaning it...
Most of the Rust advisories seem to be about having the "unsafe" keyword in the code, not handling panics in user-provided callbacks, and passing uninitialized buffers around (because speed!!1).
And Rust isn't really a mature language right now. So better compare with Java.

Also, where i rant about the use of C or C++, most often even a Python script would be able to do the job and be still fast enough. Without strong typing there obviously are more DoS vulnerabilities because a lot of bugs isn't found at compile time anymore. But almost all of the RCEs are downgrading to DoS too - and that should still be worth it.

@Oktokolo There are so many issues with your comment that I know you're going to disagree with until the end of time, so I'm choosing not to address anything.

It's very clear to me that you have a very bizarre and dogmatic view of C that just isn't correct. Like, at all. I'm not sure what kind of C you've seen but the vast majority of respectible C developers I've met do not write things that could be Python scripts and be "fast enough".

Also, I stopped buying the "Rust isn't a mature language" cop-out when it went v1. The community loves to shit on other languages and then defend their own by saying "oh it's not done yet". Fuck off.

"Almost all of the RCEs are downgrading to DoS too" what does that even mean? Those are two VERY different classes of exploitation with two VERY different threat stories, I don't know what data you have to back up your generalization but I simply do not believe it.

To assume that people only write C for performance is wrong.

To assume that people micro-optimize in C as a rule is wrong.

To think that Rust and Java and C and Python are at all generally comparable is wrong.

To think that there is a causality relationship between strong typing and reduction of DoS vulnerabilities is just ridiculously wrong.

Literally nothing in your comment I agree with whatsoever...

@junon
"Literally nothing in your comment I agree with whatsoever"
I am not surprised after reading that
you don't see a causal relationship between more type-related bugs getting fixed before the first execution and less DoS bugs in the end product...

@Oktokolo Because a DoS has very little to do with typing...

@junon
Except when the bug gets catched by the compiler because of the availability of type information...

@Oktokolo do you know what a dos vulnerability is?

Probably not @junon.
So for you @Oktokolo:
The target of an DOS attack is an suspended Service of an System. The most powerful method against DOS-attacks are firewalls.
The effectiveness of an DOS is measured how much data needs to be send to suspend the service. Usually an DOS uses third party services to produce an high stream of data and to conceal the source of the attack. DNS over UDP with IP-spoofing is common Method to generate suchban stream. An other method to create an dos is through UDP spamming, TCP SYN Packets, HTTP Slow Posting and corrupted or legit ICMP Packets.

@stop
I don't see, how a firewall protects against saturation of a network connection (the most often used DoS attack). If it doesn't, it can't be the most powerful method of defense.

Also this rant isn't about that kind of DoS - for which the only really effctive defense is to put you server behind someone (most often cloudflare) who can absorb more traffic, than the attacker can generate.

@Oktokolo cloudflare does nothing more that a firewall with deep packet inspection. If an attacker gets behind cloudflare, that means he gets the hostname/ip of the server, cloudflare cannot help you.

@stop
They do another important thing without which the defense against that sort of DoS would not work: They ensure that they always have more network connection capacity than the attackers.
It doesn't matter how good your filter is when legitimate users's packets don't even reach the server.

Lots of misunderstanding here.

A DOS is any vulnerability that prevents a service from being used by other users, either via saturation (network or resource), hangs/stalls/deadlocks, or crashes.

RCE can be used to start a DOS but idk why an attacker would stop there.

A DOS isnt always done by a DDOS. Those are two separate things, the latter being a subset of DOS attacks.

Network saturation is a brute force method, but e.g. sending a payload that generates an uncaught exception in the server via faulty logic can also happen. In any language. With or without strict typings. Yes, even in [your favorite, perfect language here].

As of writing, we do not have a burrito Analysis tool that can detect such bugs. It encroaches the halting problem territory and such classes of Hard problems.

Further, of course a firewall can be overloaded. However, remember that firewalls have a relatively simple task compared to e.g. a frontend load balancer (level 7 especially).

All a firewall has to do is to evaluate the Level 3 or 4 packet frame to determine if the packet is allowed to pass. That's a constant time lookup and just a few instructions. On ASIC processors specific for firewall operations, these can be done at an incredible rate. Since packets are sent in small chunks (based on MTU) then the entire buffer can simply be dropped if just a few bytes don't pass inspection.

They're fast.

A DoS is most likely not happening at the firewall level, but at your edge nodes (a balancer, or worse, your API services). In my experience (take with grain of salt) most DoSes that happen now are the result of malicious payloads, not brute force. especially with the advent of managed cloud solutions.

A typing system catches bugs. No contest there. I would really argue against them finding DoS vulnerabilities, or helping prevent them any more than it helps fix other classes of bugs.

C is no different here.

Hueristic*, not burrito. Autocorrect is getting worse over the years.