11 ms·

Sudo: Heap-based overflow with small passwords

279 points by thewavelength 4y ago

zitterbewegung 4y ago
Overflow should be named hunter2 or sudoer2
Flocular 4y ago
Come on :D CVSS of 7.1, Complexity Low, Availability and Confidentiality High. sure...
- BeefWellington 4y ago
  What do you think is an appropriate score? Looks reasonable to me.
  - Flocular 4y ago
    Attack complexity High (chance for an attacker to get anything at all is very low), Availability None (you're not crashing any service that's running in the background) and Confidentiality Low (data leaked is not in the attackers control and not likely to be interesting). Adds up to a score of 2.9
    - BeefWellington 4y ago
      IF you can execute code this way (which is an IF) then it's way more severe than a 2.9, and you could absolutely do anything you want with the system (you'll be root). Complexity High isn't about what an attacker gets, it's about whether or not any specific configuration must exist for the attack to happen. For instance, if an app that talks to several services over different file transfer protocols has a vulnerability in only the FTP component, and these are not under attacker control, that's Complexity High.
erk__ 4y ago
Fixed upstream here: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127...
phoe-krk 4y ago
A fun one. Buffer overflows tend to usually get associated with providing too much data; here's a nice case in which an overflow is triggered by providing too little. Seems like the buffer for storing the password was changed to be dynamically allocated, but only in some parts of the code; other parts still treated it as something that is at least nine bytes long (including the null terminator). In practice, this means that if your password is only one char, then the actual buffer is two bytes long, and the seventh byte past the buffer is then zeroed/set to the null terminator. I wonder if and how this is exploitable.
- _kbh_ 4y ago
  > I wonder if and how this is exploitable. Would be at worst a memory read past the inputted password, which wouldn't be super useful outside of a leak for another vulnerability but even that seems unlikely.
  - TonyTrapp 4y ago
    No, the code overwrote the 9th byte of the buffer to add a null terminator: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127... So it's not just reading past the end of the buffer, but it's overwriting a single byte potentially belonging to another object. It may still cause a crash but it's relatively unlikely that it could cause something more severe.
    - Someone 4y ago
      I don’t understand how this can be correct: if (pw_len == DESLEN || HAS_AGEINFO(pw_epasswd, pw_len)) { strlcpy(des_pass, pass, sizeof(des_pass)); pass = des_pass; } Doesn’t that truncate your password if it happens to have DESLEN characters?
    - _kbh_ 4y ago
      > No, the code overwrote the 9th byte of the buffer to add a null terminator: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127... Ah that makes a lot more sense. > So it's not just reading past the end of the buffer, but it's overwriting a single byte potentially belonging to another object. It may still cause a crash but it's relatively unlikely that it could cause something more severe. Yeah I agree that nothing severe should come from it. The allocations are probably larger then the size of the buffer being used so it may not even right off the end of its own allocation.
teddyh 4y ago
https://www.cve.org/CVERecord?id=CVE-2022-43995 https://www.cve.org/CVERecord?id=CVE-2022-43995
hardware2win 4y ago
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?
  - 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.
  - 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.
stabbles 4y ago
sudo feels like a broken concept to me in general. sudo make install, ok, great, some of the many operations you need to do requires privileges? Better give elevated privileges to all operations! Even worse with GUI: enter your password to install. Now I have absolutely no clue what the scope of sudo is. Of course I don't want to enter my password for all individual cp and mv operations, but if sudo had a better/smaller scope that'd be great.
- ccouzens 4y ago
  Sudo feels like a broken concept to me because it's there to protect the machine and other users. But these days many computers are only used by one user. Everything I care about on my computer is readable by my user and a program running as my user could put fake binaries in my path.
  - ccouzens 4y ago
    To be fair, it's the permission model that's not kept up with use cases. On a multiuser system sudo makes a lot of sense.
  - hjanssen 4y ago
    This is why the concept of "granular permissions" is so important on modern pcs, and I personally think linux is severely lacking in this regard. Flatpack et al. have improved this situation somewhat, but come with their own drawbacks. Linux needs a central application-level permission system like Android, where I can grant/revoke e.g. internet access to applications. Frankly, I should never have to use sudo to install anything in my daily life, that is unfortunately not the case with the common ubuntu install, and will probably stay this way for a long time.
    - docandrew 4y ago
      Yeah, for the most part today any user who is logged in is somebody I trust with the machine. What needs to be restricted is what _applications_ can do. My browser shouldn’t ever be allowed to to write to /etc/shadow regardless of whether it’s running as root or not. AppArmor gets us part of the way there but the UI to make everything play nice is too difficult. Android’s security model makes a lot of sense to me, and from what I understand it’s all based on top of normal UNIX user/group privileges, just with per-app users/groups. I’d like to see more desktop distros experiment with it.
yakubin 4y ago
Sudo must be the program with the largest number of buffer overflows I’ve heard about. That news is repeating itself ever since I remember. Maybe a good time to plug doas, a simpler alternative to sudo from OpenBSD folks[1], developed partly due to security fears about sudo. It’s also been ported to Linux and is available in e.g. Alpine and Debian. [1]: <https://flak.tedunangst.com/post/doas https://flak.tedunangst.com/post/doas>
- jmclnx 4y ago
  I was thinking the same, this is the slackbuild for Slackware 15 https://slackbuilds.org/repository/15.0/system/opendoas/?search=doas https://slackbuilds.org/repository/15.0/system/opendoas/?sea... It also contains some information on how to setup doas on Linux
- vbezhenar 4y ago
  There must not be a single suid program in a safe system. The concept of suid bit is flawed and nothing but a hack. You can build sudo-like functionality using ssh @localhost and additional root user with special shell.
  - yakubin 4y ago
    That to me sounds like moving the problem from a privileged binary to a privileged daemon and putting a network stack in the middle. I don’t see how it solves anything. Any way you can secure sshd you can probably apply to the suid binary as well.
  - Sohcahtoa82 4y ago
    This requires enabling being able to log in as root, which I'd rather not enable.
  - Beltalowda 4y ago
    And that sshd server is running as root, which is really just the same as setuid except with extra steps.
  - mindwok 4y ago
singron 4y ago
It looks like this only affects DES passwords. Glibc has supported other hashing algorithms for a very long time and most Linux distros have used them by default for years. I don't think there is a way for an unprivileged user to choose DES if it's not the default, so it's very unlikely this can actually be triggered.
- gunapologist99 4y ago
  Very good point. And, overriding defaults would mean that you have sufficient knowledge to know what not to choose. So, the practical impact of this is virtually nil.
v3ss0n 4y ago
Time to write sudo alternative in rust
- ho_schi 4y ago
  Please stop calling for a rewrite with the next language which is currently in trend. Use the right tool which fits your purpose. An example to learn: https://news.ycombinator.com/item?id=31089216 https://news.ycombinator.com/item?id=31089216 Lessons: * Serious bugs doesn't care in which language the error happens * C++ implementation was safe * Java implementation was unsafe * Test-Coverage would help... PS: I don't say Rust is good/bad. C++ is good/bad. Or is good/bad. Neither about Java.
  - ilyt 4y ago
    sudo has long history of bugs that would be impossible in Rust in the first place. Yes, given enough care and effort you might write code that will not have those bugs, but not having a possibility (aside from unsafe{}) to have them in the first place is usually better approach. Like, yeah, it is a dumb meme but in this case not without merit.
  - chlorion 4y ago
    >Serious bugs doesn't care in which language the error happens This just isn't true. Buffer overflows are not possible with bounds checking. Using a language that provides containers with bounds checked access methods would have prevented this. This isn't a point of debate or something, it's a fact. C is virtually the only language that doesn't provide a safe way to access elements. C++ provides bounds checking with std::array, std::vector and std::string using the "at()" methods. All Rust containers are checked by default. Pretty much every other language also is checked by default as well. All of these language's could have prevented this error and the other buffer overflow errors which there are tons of.
    - eklitzke 4y ago
      Sure but you wouldn't be reading a password into a std::array or std::vector in C++, you'd be reading into a std::string or possibly something like a std::stringstream. And both of those containers will handle sizing and reallocation for you. If your point is that C++ lets you do unsafe things then yes, of course it does. But so does Rust.
TheBrokenRail 4y ago
Seriously, why is sudo so complicated? Most of the time, all sudo has to do is hash a password, check that hash against a file, and if successful, run a program as root. Why can't we just have a minimal version of sudo that does just that and only that so the majority of smaller servers and home users can run sudo without fear of a security bug ever other month? Preferably using the same executable path so that everything else doesn't break. It just seems like most of sudo's security bugs come from weird obscure features almost no one uses. Like that time sudoedit had a security issue. I didn't even know that command existed until it broke things, and it still seems pointless when you can just run "sudo nano" or "sudo vi".
- maxnoe 4y ago
  There is: doas https://wiki.archlinux.org/title/Doas https://wiki.archlinux.org/title/Doas
- sersnth 4y ago
  sudoedit runs the editor as the original non-privileged user, which is nice if you're using a configurable text editor like vim/emacs so you're not suddenly using whatever (lack of) configuration the root user has setup. It can also be nice to know any other stuff a complex editor can do like running other programs won't happen in the privileged context.
effie 4y ago
This sort of fail isn't new to sudo, migrate to doas if you can - a much simpler(immensely) and less error-prone program.
pdimitar 4y ago
Alright, this is getting tiring. Zig, Nim, Rust, D, V, whatever -- can't we just move on from C/C++ already? It's obvious they are not up for the job.
- tmtvl 4y ago
  C and C++ are far from the same thing. That said, D does seem kinda nice so I wouldn't mind seeing some rewrites of critical infrastructure in it. Preferably something that'll benefit more from the rewrite than ls would.
  - pdimitar 4y ago
    Sure C++ is a tad better than C but compared to e.g. Rust and Zig it's pretty convoluted and verbose when trying to achieve things that they achieve with 2-5 liners. And even if modern C++ is amazing -- I have no doubt it's improving all the time -- that doesn't change the fact that there are metric tons of C++ code out there that nobody will ever modernize. So C++ getting improved with time is sadly an almost moot point. I'd personally advocate for Rust but I've heard people say there are a few other languages that allow you to achieve the same memory safety so, by all means, let's please start rewriting and make our everyday tools something different than a Swiss cheese of potential and actual security threats. It really is time. The language doesn't matter, the outcomes do. And in terms of outcomes I maintain that C and C++ have not stood the test of time in terms of security and amount of foot guns. Too much sentimental value is attached to them as well and that doesn't help matters either. We work with tech. We don't make love with it. We should all start acting like this is a job and not [only] a hobby.
    - pjmlp 4y ago
      > Sure C++ is a tad better than C but compared to e.g. Rust and Zig it's pretty convoluted and verbose when trying to achieve things that they achieve with 2-5 liners. yeah, if one is stuck in C++98 mentality.
      - pdimitar 4y ago
mrtweetyhack 4y ago
millert 4y ago
As far as I can tell this is a non-issue. A single byte is written potentially outside a dynamically allocated buffer but the original contents is restored before the function returns (sudo is single-threaded). At best it could be a crash, but even that is unlikely unless using address sanitizer or valgrind.
alibob 4y ago
Why is "sudo 1.8.0 through 1.9.12" affected, but rhel8 shipping sudo 1.8.29 and rhel9 shipping sudo 1.9.5, are not affected? <https://access.redhat.com/security/cve/CVE-2022-43995 https://access.redhat.com/security/cve/CVE-2022-43995> Description: ... Sudo 1.8.0 through 1.9.12 ... Statement: The sudo package as distributed with Red Hat Enterprise Linux 7, 8 and 9 is not affected by this issue as it currently doesn't ship the affected code. <https://access.redhat.com/downloads/content/sudo/x86_64/package-latest https://access.redhat.com/downloads/content/sudo/x86_64/pack...> 1.9.5p2-7.el9 1.8.29-8.el8
- alibob 4y ago
  <https://news.ycombinator.com/item?id=33467522 https://news.ycombinator.com/item?id=33467522> Got it. Linux distributions (ex. RHEL) have --with-pam in configure, so not vulnerable (code not compiled). (If you have --with-passwd in configure, then passwd.c is compiled, and you are vulnerable, but Linux distributions do not do this.) <https://ubuntu.com/security/CVE-2022-43995 https://ubuntu.com/security/CVE-2022-43995> sudo packages in Ubuntu are compiled with PAM support, so the vulnerable code isn't part of the binaries. Not vulnerable (code not compiled)

279 points by thewavelength 4y ago

zitterbewegung 4y ago

Overflow should be named hunter2 or sudoer2

Flocular 4y ago

Come on :D CVSS of 7.1, Complexity Low, Availability and Confidentiality High. sure...

BeefWellington 4y ago
What do you think is an appropriate score? Looks reasonable to me.
- Flocular 4y ago
  Attack complexity High (chance for an attacker to get anything at all is very low), Availability None (you're not crashing any service that's running in the background) and Confidentiality Low (data leaked is not in the attackers control and not likely to be interesting). Adds up to a score of 2.9
  - BeefWellington 4y ago
    IF you can execute code this way (which is an IF) then it's way more severe than a 2.9, and you could absolutely do anything you want with the system (you'll be root). Complexity High isn't about what an attacker gets, it's about whether or not any specific configuration must exist for the attack to happen. For instance, if an app that talks to several services over different file transfer protocols has a vulnerability in only the FTP component, and these are not under attacker control, that's Complexity High.

erk__ 4y ago

Fixed upstream here: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127...

phoe-krk 4y ago

A fun one. Buffer overflows tend to usually get associated with providing too much data; here's a nice case in which an overflow is triggered by providing too little. Seems like the buffer for storing the password was changed to be dynamically allocated, but only in some parts of the code; other parts still treated it as something that is at least nine bytes long (including the null terminator). In practice, this means that if your password is only one char, then the actual buffer is two bytes long, and the seventh byte past the buffer is then zeroed/set to the null terminator. I wonder if and how this is exploitable.

_kbh_ 4y ago
> I wonder if and how this is exploitable. Would be at worst a memory read past the inputted password, which wouldn't be super useful outside of a leak for another vulnerability but even that seems unlikely.
- TonyTrapp 4y ago
  No, the code overwrote the 9th byte of the buffer to add a null terminator: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127... So it's not just reading past the end of the buffer, but it's overwriting a single byte potentially belonging to another object. It may still cause a crash but it's relatively unlikely that it could cause something more severe.
  - Someone 4y ago
    I don’t understand how this can be correct: if (pw_len == DESLEN || HAS_AGEINFO(pw_epasswd, pw_len)) { strlcpy(des_pass, pass, sizeof(des_pass)); pass = des_pass; } Doesn’t that truncate your password if it happens to have DESLEN characters?
  - _kbh_ 4y ago
    > No, the code overwrote the 9th byte of the buffer to add a null terminator: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127 https://github.com/sudo-project/sudo/commit/bd209b9f16fcd127... Ah that makes a lot more sense. > So it's not just reading past the end of the buffer, but it's overwriting a single byte potentially belonging to another object. It may still cause a crash but it's relatively unlikely that it could cause something more severe. Yeah I agree that nothing severe should come from it. The allocations are probably larger then the size of the buffer being used so it may not even right off the end of its own allocation.

teddyh 4y ago

https://www.cve.org/CVERecord?id=CVE-2022-43995 https://www.cve.org/CVERecord?id=CVE-2022-43995

hardware2win 4y ago

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

stabbles 4y ago

sudo feels like a broken concept to me in general. sudo make install, ok, great, some of the many operations you need to do requires privileges? Better give elevated privileges to all operations! Even worse with GUI: enter your password to install. Now I have absolutely no clue what the scope of sudo is. Of course I don't want to enter my password for all individual cp and mv operations, but if sudo had a better/smaller scope that'd be great.

ccouzens 4y ago
Sudo feels like a broken concept to me because it's there to protect the machine and other users. But these days many computers are only used by one user. Everything I care about on my computer is readable by my user and a program running as my user could put fake binaries in my path.
- ccouzens 4y ago
  To be fair, it's the permission model that's not kept up with use cases. On a multiuser system sudo makes a lot of sense.
- hjanssen 4y ago
  This is why the concept of "granular permissions" is so important on modern pcs, and I personally think linux is severely lacking in this regard. Flatpack et al. have improved this situation somewhat, but come with their own drawbacks. Linux needs a central application-level permission system like Android, where I can grant/revoke e.g. internet access to applications. Frankly, I should never have to use sudo to install anything in my daily life, that is unfortunately not the case with the common ubuntu install, and will probably stay this way for a long time.
  - docandrew 4y ago
    Yeah, for the most part today any user who is logged in is somebody I trust with the machine. What needs to be restricted is what _applications_ can do. My browser shouldn’t ever be allowed to to write to /etc/shadow regardless of whether it’s running as root or not. AppArmor gets us part of the way there but the UI to make everything play nice is too difficult. Android’s security model makes a lot of sense to me, and from what I understand it’s all based on top of normal UNIX user/group privileges, just with per-app users/groups. I’d like to see more desktop distros experiment with it.

yakubin 4y ago

Sudo must be the program with the largest number of buffer overflows I’ve heard about. That news is repeating itself ever since I remember. Maybe a good time to plug doas, a simpler alternative to sudo from OpenBSD folks[1], developed partly due to security fears about sudo. It’s also been ported to Linux and is available in e.g. Alpine and Debian. [1]: <https://flak.tedunangst.com/post/doas https://flak.tedunangst.com/post/doas>

jmclnx 4y ago
I was thinking the same, this is the slackbuild for Slackware 15 https://slackbuilds.org/repository/15.0/system/opendoas/?search=doas https://slackbuilds.org/repository/15.0/system/opendoas/?sea... It also contains some information on how to setup doas on Linux
vbezhenar 4y ago
There must not be a single suid program in a safe system. The concept of suid bit is flawed and nothing but a hack. You can build sudo-like functionality using ssh @localhost and additional root user with special shell.
- yakubin 4y ago
  That to me sounds like moving the problem from a privileged binary to a privileged daemon and putting a network stack in the middle. I don’t see how it solves anything. Any way you can secure sshd you can probably apply to the suid binary as well.
- Sohcahtoa82 4y ago
  This requires enabling being able to log in as root, which I'd rather not enable.
- Beltalowda 4y ago
  And that sshd server is running as root, which is really just the same as setuid except with extra steps.
- mindwok 4y ago

singron 4y ago

It looks like this only affects DES passwords. Glibc has supported other hashing algorithms for a very long time and most Linux distros have used them by default for years. I don't think there is a way for an unprivileged user to choose DES if it's not the default, so it's very unlikely this can actually be triggered.

gunapologist99 4y ago
Very good point. And, overriding defaults would mean that you have sufficient knowledge to know what not to choose. So, the practical impact of this is virtually nil.

v3ss0n 4y ago

Time to write sudo alternative in rust

ho_schi 4y ago
Please stop calling for a rewrite with the next language which is currently in trend. Use the right tool which fits your purpose. An example to learn: https://news.ycombinator.com/item?id=31089216 https://news.ycombinator.com/item?id=31089216 Lessons: * Serious bugs doesn't care in which language the error happens * C++ implementation was safe * Java implementation was unsafe * Test-Coverage would help... PS: I don't say Rust is good/bad. C++ is good/bad. Or is good/bad. Neither about Java.
- ilyt 4y ago
  sudo has long history of bugs that would be impossible in Rust in the first place. Yes, given enough care and effort you might write code that will not have those bugs, but not having a possibility (aside from unsafe{}) to have them in the first place is usually better approach. Like, yeah, it is a dumb meme but in this case not without merit.
- chlorion 4y ago
  >Serious bugs doesn't care in which language the error happens This just isn't true. Buffer overflows are not possible with bounds checking. Using a language that provides containers with bounds checked access methods would have prevented this. This isn't a point of debate or something, it's a fact. C is virtually the only language that doesn't provide a safe way to access elements. C++ provides bounds checking with std::array, std::vector and std::string using the "at()" methods. All Rust containers are checked by default. Pretty much every other language also is checked by default as well. All of these language's could have prevented this error and the other buffer overflow errors which there are tons of.
  - eklitzke 4y ago
    Sure but you wouldn't be reading a password into a std::array or std::vector in C++, you'd be reading into a std::string or possibly something like a std::stringstream. And both of those containers will handle sizing and reallocation for you. If your point is that C++ lets you do unsafe things then yes, of course it does. But so does Rust.

TheBrokenRail 4y ago

Seriously, why is sudo so complicated? Most of the time, all sudo has to do is hash a password, check that hash against a file, and if successful, run a program as root. Why can't we just have a minimal version of sudo that does just that and only that so the majority of smaller servers and home users can run sudo without fear of a security bug ever other month? Preferably using the same executable path so that everything else doesn't break. It just seems like most of sudo's security bugs come from weird obscure features almost no one uses. Like that time sudoedit had a security issue. I didn't even know that command existed until it broke things, and it still seems pointless when you can just run "sudo nano" or "sudo vi".

maxnoe 4y ago
There is: doas https://wiki.archlinux.org/title/Doas https://wiki.archlinux.org/title/Doas
sersnth 4y ago
sudoedit runs the editor as the original non-privileged user, which is nice if you're using a configurable text editor like vim/emacs so you're not suddenly using whatever (lack of) configuration the root user has setup. It can also be nice to know any other stuff a complex editor can do like running other programs won't happen in the privileged context.

effie 4y ago

This sort of fail isn't new to sudo, migrate to doas if you can - a much simpler(immensely) and less error-prone program.

pdimitar 4y ago

Alright, this is getting tiring. Zig, Nim, Rust, D, V, whatever -- can't we just move on from C/C++ already? It's obvious they are not up for the job.

tmtvl 4y ago
C and C++ are far from the same thing. That said, D does seem kinda nice so I wouldn't mind seeing some rewrites of critical infrastructure in it. Preferably something that'll benefit more from the rewrite than ls would.
- pdimitar 4y ago
  Sure C++ is a tad better than C but compared to e.g. Rust and Zig it's pretty convoluted and verbose when trying to achieve things that they achieve with 2-5 liners. And even if modern C++ is amazing -- I have no doubt it's improving all the time -- that doesn't change the fact that there are metric tons of C++ code out there that nobody will ever modernize. So C++ getting improved with time is sadly an almost moot point. I'd personally advocate for Rust but I've heard people say there are a few other languages that allow you to achieve the same memory safety so, by all means, let's please start rewriting and make our everyday tools something different than a Swiss cheese of potential and actual security threats. It really is time. The language doesn't matter, the outcomes do. And in terms of outcomes I maintain that C and C++ have not stood the test of time in terms of security and amount of foot guns. Too much sentimental value is attached to them as well and that doesn't help matters either. We work with tech. We don't make love with it. We should all start acting like this is a job and not [only] a hobby.
  - pjmlp 4y ago
    > Sure C++ is a tad better than C but compared to e.g. Rust and Zig it's pretty convoluted and verbose when trying to achieve things that they achieve with 2-5 liners. yeah, if one is stuck in C++98 mentality.
    - pdimitar 4y ago

mrtweetyhack 4y ago

millert 4y ago

As far as I can tell this is a non-issue. A single byte is written potentially outside a dynamically allocated buffer but the original contents is restored before the function returns (sudo is single-threaded). At best it could be a crash, but even that is unlikely unless using address sanitizer or valgrind.

alibob 4y ago

Why is "sudo 1.8.0 through 1.9.12" affected, but rhel8 shipping sudo 1.8.29 and rhel9 shipping sudo 1.9.5, are not affected? <https://access.redhat.com/security/cve/CVE-2022-43995 https://access.redhat.com/security/cve/CVE-2022-43995> Description: ... Sudo 1.8.0 through 1.9.12 ... Statement: The sudo package as distributed with Red Hat Enterprise Linux 7, 8 and 9 is not affected by this issue as it currently doesn't ship the affected code. <https://access.redhat.com/downloads/content/sudo/x86_64/package-latest https://access.redhat.com/downloads/content/sudo/x86_64/pack...> 1.9.5p2-7.el9 1.8.29-8.el8

alibob 4y ago
<https://news.ycombinator.com/item?id=33467522 https://news.ycombinator.com/item?id=33467522> Got it. Linux distributions (ex. RHEL) have --with-pam in configure, so not vulnerable (code not compiled). (If you have --with-passwd in configure, then passwd.c is compiled, and you are vulnerable, but Linux distributions do not do this.) <https://ubuntu.com/security/CVE-2022-43995 https://ubuntu.com/security/CVE-2022-43995> sudo packages in Ubuntu are compiled with PAM support, so the vulnerable code isn't part of the binaries. Not vulnerable (code not compiled)