8 ms·

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?

Iolaum 4y ago
And the second question, would be: What is the cost for it and would we be willing to pay it?
- phoe-krk 4y ago
  And the third question, would be: What is the cost for using outdated technology and are we really willing to pay it?
  - eru 4y ago
    Well, in practice we are paying it.
    - phoe-krk 4y ago
      Yep, the real question is for how much longer.
      - jeroenhd 4y ago
        Until someone can come up with the time or money to fix the feature gap between the many safe rewrites and the standard coreutils (and convinces packagers to ship the safe ones).
        pjmlp 4y ago
        Or governments start to pay attention like the last US security bill.
  - selfmodruntime 4y ago
    The answer to the first question is „literal billions in damages“ and the answer to the second one is „seemingly yes“. Library / application maintainers and product companies rarely pay the cost if yet another memory safety issue leads to a new 0day. Perhaps changing that would finally turn people off of C/C++
    - pjmlp 4y ago
      Yes, when we aren't happy with physical goods there are laws and liabilities to take into account, same should apply to software products.
- hardware2win 4y ago
  You are talking about perf? People use fucking java in HFT dont worry, our basic tools are fine with Rust, go or even c#
  - MobiusHorizons 4y ago
    For cli tools startup performance matters a lot, and many languages struggle on that point (eg Java) go and rust would probably be acceptable though.
    - pjmlp 4y ago
      Apparently not, when so many of them are written in Python and Perl. As for Java, if the extra ms are the end of the world, one can JIT cache or AOT compile it anyway.
jerf 4y ago
Yes. 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.
- thr0wnawaytod4y 4y ago
  but if sudo was written in java we'd have other problems ;)
  - jerf 4y ago
    Yes, I agree. I did not mean to imply that literally any other language would have been better for sudo, which I see is a viable reading of my original post. Go, for instance, would be a terrible choice, because the way the runtime deeply assumes you're running in a multithread environment, even before it gets to your "main" function, means that exactly the sort of UNIX hackery sudo is designed to do is effectively impossible. I have a system myself that is otherwise entirely in Go, but we have a very small C-based wrapper whose job it is to be setuid, open a few files with the escalated privileges, do some user verification, then change its uid and gid and exec the "real" Go program, because Go just can't do those things. 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.
    - pjmlp 4y ago
      In a way it is kind of an ironic tragedy, that the followers of C church worship UNIX and Plan 9, while ignoring the end station from the priesters, Inferno and Limbo, where C was confined to the minimal trust base of the kernel and a couple of drivers, with everything else in userspace mostly written in Limbo. Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/cmd/runas.b https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...
  - 4y ago
cbrogrammer 4y ago
We could start by considering not writing stuff like > /* > * 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];
candiddevmike 4y ago
Related, but sudo is not in scope for this project: https://github.com/uutils/coreutils https://github.com/uutils/coreutils
userbinator 4y ago
The solution is simplicity, not more complexity. 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.
- insanitybit 4y ago
  > the "safest" and most "modern" shit won't help But it would
  - ehutch79 4y ago
    I'm pretty sure their point was that there are fundamental issues at play, and that switching languages does not make the problem go away. Rust/whatever is not a magic bullet
    - Shish2k 4y ago
      It wouldn’t solve every problem, but it would solve this problem, and this problem happens to be a regularly reoccurring problem with serious consequences
    - insanitybit 4y ago
      I get their point, it's just ironic since modern languages very much do not suffer from "I think a password needs to be dynamically allocated". 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.
    - selfmodruntime 4y ago
      This is complete nonsense. There aren‘t fundamental issues at play. The issue is time and time again memory safety and bounds checking. Avoiding that topic in favor of „fundamental issues“ is disingenuous at best. 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.
st_goliath 4y ago
> Could it be mitigated by safer, modern tech? 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 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).
postalrat 4y ago
Eventually it will be written in javascript.
pjmlp 4y ago
> ..array-out-of-bounds error that can result in a heap-based buffer over-read... 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.
Beltalowda 4y ago
sudo is almost 150k lines of code, has been developed since about 1980, and works (and is used!) on a wide array of systems. 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.
- selfmodruntime 4y ago
  Translating that one to one would take 10 developers at 100loc / day less than half a year. Surely that can‘t be that much in the name of security, no?
  - Beltalowda 4y ago
    I think that is a very optimistic estimate considering it's pretty difficult security-sensitive code which integrates with quite a number of system components in complex ways across a large number of different platforms (this particular bug was introduced for HP-UX compatibility for example). 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.
    - selfmodruntime 4y ago
      > But you're welcome to try of course 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.
chlorion 4y ago
Bounds checking would have prevented this outright. 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".
- pjmlp 4y ago
  Bounds checking in systems languages precedes C for a decade, making it worse their decision to ignore it.

Iolaum 4y ago

And the second question, would be: What is the cost for it and would we be willing to pay it?

phoe-krk 4y ago
And the third question, would be: What is the cost for using outdated technology and are we really willing to pay it?
- eru 4y ago
  Well, in practice we are paying it.
  - phoe-krk 4y ago
    Yep, the real question is for how much longer.
    - jeroenhd 4y ago
      Until someone can come up with the time or money to fix the feature gap between the many safe rewrites and the standard coreutils (and convinces packagers to ship the safe ones).
      - pjmlp 4y ago
        Or governments start to pay attention like the last US security bill.
- selfmodruntime 4y ago
  The answer to the first question is „literal billions in damages“ and the answer to the second one is „seemingly yes“. Library / application maintainers and product companies rarely pay the cost if yet another memory safety issue leads to a new 0day. Perhaps changing that would finally turn people off of C/C++
  - pjmlp 4y ago
    Yes, when we aren't happy with physical goods there are laws and liabilities to take into account, same should apply to software products.
hardware2win 4y ago
You are talking about perf? People use fucking java in HFT dont worry, our basic tools are fine with Rust, go or even c#
- MobiusHorizons 4y ago
  For cli tools startup performance matters a lot, and many languages struggle on that point (eg Java) go and rust would probably be acceptable though.
  - pjmlp 4y ago
    Apparently not, when so many of them are written in Python and Perl. As for Java, if the extra ms are the end of the world, one can JIT cache or AOT compile it anyway.

jerf 4y ago

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

thr0wnawaytod4y 4y ago
but if sudo was written in java we'd have other problems ;)
- jerf 4y ago
  Yes, I agree. I did not mean to imply that literally any other language would have been better for sudo, which I see is a viable reading of my original post. Go, for instance, would be a terrible choice, because the way the runtime deeply assumes you're running in a multithread environment, even before it gets to your "main" function, means that exactly the sort of UNIX hackery sudo is designed to do is effectively impossible. I have a system myself that is otherwise entirely in Go, but we have a very small C-based wrapper whose job it is to be setuid, open a few files with the escalated privileges, do some user verification, then change its uid and gid and exec the "real" Go program, because Go just can't do those things. 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.
  - pjmlp 4y ago
    In a way it is kind of an ironic tragedy, that the followers of C church worship UNIX and Plan 9, while ignoring the end station from the priesters, Inferno and Limbo, where C was confined to the minimal trust base of the kernel and a couple of drivers, with everything else in userspace mostly written in Limbo. Here is "runas" in Limbo, https://bitbucket.org/inferno-os/inferno-os/src/master/appl/cmd/runas.b https://bitbucket.org/inferno-os/inferno-os/src/master/appl/...
- 4y ago

cbrogrammer 4y ago

We could start by considering not writing stuff like > /* > * 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];

candiddevmike 4y ago

Related, but sudo is not in scope for this project: https://github.com/uutils/coreutils https://github.com/uutils/coreutils

userbinator 4y ago

The solution is simplicity, not more complexity. 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.

insanitybit 4y ago
> the "safest" and most "modern" shit won't help But it would
- ehutch79 4y ago
  I'm pretty sure their point was that there are fundamental issues at play, and that switching languages does not make the problem go away. Rust/whatever is not a magic bullet
  - Shish2k 4y ago
    It wouldn’t solve every problem, but it would solve this problem, and this problem happens to be a regularly reoccurring problem with serious consequences
  - insanitybit 4y ago
    I get their point, it's just ironic since modern languages very much do not suffer from "I think a password needs to be dynamically allocated". 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.
  - selfmodruntime 4y ago
    This is complete nonsense. There aren‘t fundamental issues at play. The issue is time and time again memory safety and bounds checking. Avoiding that topic in favor of „fundamental issues“ is disingenuous at best. 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.

st_goliath 4y ago

> Could it be mitigated by safer, modern tech? 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 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).

postalrat 4y ago

Eventually it will be written in javascript.

pjmlp 4y ago

> ..array-out-of-bounds error that can result in a heap-based buffer over-read... 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.

Beltalowda 4y ago

sudo is almost 150k lines of code, has been developed since about 1980, and works (and is used!) on a wide array of systems. 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.

selfmodruntime 4y ago
Translating that one to one would take 10 developers at 100loc / day less than half a year. Surely that can‘t be that much in the name of security, no?
- Beltalowda 4y ago
  I think that is a very optimistic estimate considering it's pretty difficult security-sensitive code which integrates with quite a number of system components in complex ways across a large number of different platforms (this particular bug was introduced for HP-UX compatibility for example). 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.
  - selfmodruntime 4y ago
    > But you're welcome to try of course 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.

chlorion 4y ago

Bounds checking would have prevented this outright. 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".

pjmlp 4y ago
Bounds checking in systems languages precedes C for a decade, making it worse their decision to ignore it.