Another day, another CVE in tool that we rely on everyday
The first question that we all want to ask
Could it be mitigated by safer, modern tech?
The first question that we all want to ask
Could it be mitigated by safer, modern tech?
One does not even need to reach for Rust. Literally any other language (in common use) other than very badly used C++ would not have had this problem.
C delenda est.
Is it that GNAT only became available relatively late in the lifetime of GNU/Linux? Or is there another technical reason for it?
Anything else required buying the product and justify why the compilers in the box wouldn't do it .
When UNIX SDKs became commercial, it was even worse, you would naturally one buy the main one, not pay twice for programming languages.
Then the UNIX clones also followed the same culture focusing on C for the clones. Early versions of the GNU manifesto explicitly refer that C should be the preferred language.
That is how we landed here.
Dynamically typed languages as a whole would be a bad idea.
Java's startup time for such a small executable would be a problem.
I'm just saying this problem is unique to C, and in my opinion, sufficiently endemic to security software to disqualify it entirely.
Mind you, you might well end up at Rust in the end anyhow. Perhaps D. It isn't necessarily a long list for a sudo replacement. But...
C delenda est.
Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...
PL/I does bounds checking by default.
Even the pseudo secure Annex K, requires separate arguments for actual length and max buffer length, thus defeating the purpose of being library functions for secure code.
Just having one of the many libraries that provide secure strings and vector handling, so that libraries can rely on a common vocabulary types would be an improvement.
I assume you actually think that sudo takes the time it does, but you just likely entered your password wrong and are made to wait deliberately through a sleep. Are we really that bad at ball parking code execution times?!
Or even the x100 from (G)GP, that's a half second. Sometimes spiking to a full second.
The person arguing also brought up that normally anything needing sudo should be automatized so that should be fine.
I'm not doing enough system administration to judge if that is a sane idea or not ;=)
def add_noise(t=10):
time.sleep(t-1)
time.sleep(
uniformrandom(min=0,max=1))
(Re: Short, DES passwords https://en.wikipedia.org/wiki/Triple_DES :
> A CVE released in 2016, CVE-2016-2183 disclosed a major security vulnerability in DES and 3DES encryption algorithms. This CVE, combined with the inadequate key size of DES and 3DES, NIST has deprecated DES and 3DES for new applications in 2017, and for all applications by the end of 2023.[1] It has been replaced with the more secure, more robust AES.
Except for PQ. For PQ in 2022: https://news.ycombinator.com/item?id=32760170 :
> NIST PQ algos are only just now announced: https://news.ycombinator.com/item?id=32281357 : Kyber, NTRU, {FIPS-140-3}? [TLS1.4/2.0?]
Adding a random amount of time seems like a reasonable thing to do.
Not sure what the links are all about, or the discussion of time complexity... I mean, there isn't an "input size" to talk about big-O scaling anyway, in the case of sudo.
Timing attacks > Avoidance https://en.wikipedia.org/wiki/Timing_attack
IO wouldn’t get slower though, and likely that takes the majority of its running time.
RH does have an interest in Rust, used in projects such as Stratis. It's just that the Linux dev ecosystem has been very C-reliant for a long time, and a massive amount of binding and other ecosystem work is still happening to make this possible.
*EDIT:* and the reason I mention Rust specifically is that, in these types of lower-level projects, a lot of things can start to get hairy very quickly in higher level languages. Things like some namespace APIs very much wanting to be run on a single thread, or trying to maintain performance when you're intercepting and examining every D-Bus message, or even just when you want your functionality to be in a reusable core library.
Meanwhile RedHat and others don't have infinite resources, and they inherited sudo.
They were also open about it, and thus created lint for validating the code, which most people ignore when writing C code.
And if either GCC or clang are supported, they support safer languages than C and C++ on their standard collection of frontends.
Languages like D even allow you to disable the garbage collector for specific methods, giving you the benefit of GC-less performance and characteristics in critical code paths and the YOLO memory management of GC languages in the wrappers around them.
I guess the answer is "because all the people over at Redhat know C"
Just to throw out some guesses:
1) "because dynamic linking", if you're an OS vendor being able to ship one package to fix a security vulnerability instead of 50 is a big deal
2) you probably want to have a C-compatible API anyway so that it's possible to use the code from other languages, so combined with 1) the benefit of a language like Rust or D would be dulled slightly. Not eliminated, just reduced.
3) Less common architectures POWER and s390x are still relevant platforms in enterprise and while languages like Rust do have some support for them, C compilers for those platforms definitely get more attention.
> /*
> * Truncate to 8 chars if standard DES since not all crypt()'s do this.
> * If this turns out not to be safe we will have to use OS #ifdef's (sigh).
> */
> sav = pass[8];
This bug was introduced by the latter.
If you seriously think a buffer for a password needs to be dynamically allocated, the "safest" and most "modern" shit won't help. It'll just contribute to the ongoing decline.
But it would
Rust/whatever is not a magic bullet
Rust / Go / Modern Language X is not a magic bullet for every problem, but it sure seems to be a magic solution for this very problem which occurs incredibly often and is easily fixed by avoiding archaic languages for security critical stuff.
It's also particularly silly since there are plenty of reasons why a dynamically allocated password could be quite nice.
So yeah, I get that their point is "bad devs will write unsafe code no matter what the language is", this is just a terrible case to try to make that argument.
This was already a solved problem in NEWP, JOVIAL and PL/I, no need for modern tech, only not to insist in using broken by design one.
Like... Coverity Scan?
In my experience, this bug looks like a classic example for something that Coverity should find.
And it looks like sudo is already on there: https://scan.coverity.com/projects/sudo
The last analysis was 2 weeks ago. I wonder if this CVE is among the outstanding memory corruption and illegal access defects (5 each).
Perhaps changing that would finally turn people off of C/C++
People use fucking java in HFT
dont worry, our basic tools are fine with Rust, go or even c#
As for Java, if the extra ms are the end of the world, one can JIT cache or AOT compile it anyway.
Bounds checking has been standard in every language other than C since 1970, but for some reason C programmers refuse to use it, normally using arguments like "just make sure the indexes are correct", which is basically "just don't write bugs".
Are you going to rewrite all of that in $other_language_than_c? How many hours of work do you think this will take to rewrite?
This is the real issue.
I'd argue that's (at least part of) the problem. More code = more surface area for bugs, and sudo has a lot of code.
(also, 150k lines of code is a little bit misleading, since not all code is for all platforms, sudo has a plugin architecture I believe, etc.)
Surely that can‘t be that much in the name of security, no?
But you're welcome to try of course. But if it was that easy I bet someone would have done so already. This is the classic "zomg look at how complex it is, let's just rewrite it from scratch!" and then you discover that the complexity is there because it solves a long list of edge cases.
> Surely that can‘t be that much in the name of security, no?
Meh; in reality, almost no one was affected by this particular bug, and even if they were, you needed system/shell access to be affected. Like many sudo security problems in reality they're often actually not that big of a deal. Of course, it could be improved, but there's a long list of other things that are more impactful.
Ah yes, the classic "do it yourself then" comeback argument. Thing is, I am a single developer with rent to pay and a family to feed. In all honesty, I would have little to gain when rewriting sudo / mission critical software in a secure language.
What I was going for is that gigantic companies with tens of thousands of people and manpower use tools like sudo / brew / sqlite / <security dependant tool x> every day. They are the ones who would benefit the most by rewriting critical software in something else than C, and they seem to be getting on that track for internal software.
But for open source stuff, no one cares and that's criminal in my mind.
Who are you or I to determine where others – including "gigantic companies with tens of thousands of people and manpower" – should spend their time and money?