Barely coherent animations every three sentences make this a really unfun read. And, is it just me, or do none of the very overly verbose explanations actually ever explain how those behaviors come together to produce a vulnerability? I had to ignore the prose and put the code snippets together to get what actually happened.
Am I right in understanding that this is fully mitigated by disabling password login and using ssh keys instead? Because that should be the norm nowadays anyway for other reasons as well, right?
(Not trying to say this shouldn't be fixed and isn't a good find though.)
Password logins are enabled by default, yes, but not for root. Having only an asterisk in the password-field in /etc/shadow is hopefully rare for other users.
It's an interesting vuln, but this glossy website presentation style that buries the lede (am i affected, what to do), is really annoying to read through.
I know that named-vuln-site itself is a cliche that some people roll their eyes on, but in comparison:
https://tldr.fail/ (not a vuln but still a nice "fix your stuff" writeup)
feel much more grounded and immediately useful than this, but I guess the LLM graphics stuff gets more clicks or something :/
That checklist at the end is also like...... Maybe I'm old-fashioned but I thought it's not a good UI/UX thing to have things randomly pop-in or blink.
Also the most generic slop design ever, really. You'd think they'd at least prompt "don't make it look like every single other website ever generated by an LLM"
Why did musl even decide to "fix" an API that always returns NULL on failure elsewhere? The correct solution would be to fix the program that uses the API, IMO.
I suspect because this is a fairly rare thing to happen that most people don't think about it when testing their programs, and so don't handle that case correctly. And if you have a large number of real-world programs running that already do the wrong thing and crash, then it's probably easier to fix it at the API level rather than fix all those programs (even if technically those programs are wrong).
Ideally, they could have used ADTs to force users to handle the error cases or crash explicitly (Ok(String) | Err(UnknownAlgorithm)) but that's not really viable for a C API unfortunately.
Yeah but those programs are more likely used on glibc in the vast majority of systems, which will also return NULL. So musl fixing it unilaterally isn't going to make as much of an impact as trying to fix the programs.
"Fixing" it in musl doesn't cause incompatibility with programs that would correctly check for null though. So in theory it can be "fixed" from both sides of the API. Musl fixing it in their version is just a step in the right direction. Sadly it caused a bug that now also needs to be fixed.
Yes the design is a little slop-y, but interesting vulnerability… does this have a CVE then? Not sure how that works. Does this effect anyone running default alpine docker up on the internet then? If you run a docker container with alpine that has ssh installed, are we saying it’s possible to log into the ‘alpine’ user that way by default?
Luckily PermitRootLogin hasn't allowed logins with passwords for root since 2015. I'm guessing that's at least part of why this went undiscovered for so long.
For this to hit root I believe you'd have to actively allow password-logins for a root-account that doesn't have a password, which seems like a weird thing to do. But people are forgetful, so it's entirely possible to end up in this situation. I'm glad OpenSSH decided to patch even though they "consider the root cause of this bug to be outside sshd".
First thing I do on any server is turn off password authentication, for years, just because of all the automated brute force attempts. I fail2ban them, of course, but there are always more. It can be a pretty big inconvenience when I have a new device, but I'm just living with it.
hjvt | an hour ago
Barely coherent animations every three sentences make this a really unfun read. And, is it just me, or do none of the very overly verbose explanations actually ever explain how those behaviors come together to produce a vulnerability? I had to ignore the prose and put the code snippets together to get what actually happened.
siru | 2 hours ago
Am I right in understanding that this is fully mitigated by disabling password login and using ssh keys instead? Because that should be the norm nowadays anyway for other reasons as well, right?
(Not trying to say this shouldn't be fixed and isn't a good find though.)
sjamaan | 2 hours ago
Yes, disabling password logins mitigates it fully, but AFAICT ssh ships with password logins enabled by default.
dullmirror | 2 hours ago
Password logins are enabled by default, yes, but not for root. Having only an asterisk in the password-field in
/etc/shadowis hopefully rare for other users.sjamaan | 2 hours ago
I don't know how Alpine does it, but my Debian machine's
/etc/shadowis full of "system" users with an asterisk in the password field...thedward | an hour ago
On Debian, those users are assigned the login shell
/usr/sbin/nologin.sjamaan | an hour ago
Ah, good point!
dullmirror | an hour ago
Also, the bug is specific to musl-based linuxes. Debian uses glibc, and is not affected :)
It seems
!is default for users (other than root) without a password on Alpine. Hopefully the other musl-distros doesn't follow Debian in using*.regalialong | an hour ago
It's an interesting vuln, but this glossy website presentation style that buries the lede (am i affected, what to do), is really annoying to read through.
I know that named-vuln-site itself is a cliche that some people roll their eyes on, but in comparison:
feel much more grounded and immediately useful than this, but I guess the LLM graphics stuff gets more clicks or something :/
That checklist at the end is also like...... Maybe I'm old-fashioned but I thought it's not a good UI/UX thing to have things randomly pop-in or blink.
nytpu | 54 minutes ago
Also the most generic slop design ever, really. You'd think they'd at least prompt "don't make it look like every single other website ever generated by an LLM"
BenjaminRi | 2 hours ago
Imagine C has proper sum types that force you to unwrap an
Ok(value)orError. It's easy if you try.gspr | an hour ago
sjamaan | 2 hours ago
Why did musl even decide to "fix" an API that always returns
NULLon failure elsewhere? The correct solution would be to fix the program that uses the API, IMO.Johz | 2 hours ago
I suspect because this is a fairly rare thing to happen that most people don't think about it when testing their programs, and so don't handle that case correctly. And if you have a large number of real-world programs running that already do the wrong thing and crash, then it's probably easier to fix it at the API level rather than fix all those programs (even if technically those programs are wrong).
Ideally, they could have used ADTs to force users to handle the error cases or crash explicitly (
Ok(String) | Err(UnknownAlgorithm)) but that's not really viable for a C API unfortunately.sjamaan | 2 hours ago
Yeah but those programs are more likely used on glibc in the vast majority of systems, which will also return
NULL. So musl fixing it unilaterally isn't going to make as much of an impact as trying to fix the programs.siru | 2 hours ago
"Fixing" it in musl doesn't cause incompatibility with programs that would correctly check for null though. So in theory it can be "fixed" from both sides of the API. Musl fixing it in their version is just a step in the right direction. Sadly it caused a bug that now also needs to be fixed.
runxiyu | 2 hours ago
This reminds me of PAM's Segmentation fault when receiving "*" from musl's crypt(3)
eest | 2 hours ago
https://hachyderm.io/@damienmiller/117563026759098135
ariaaaa | 30 minutes ago
I guess responsible disclosure is out the window.
Here is alpine's security advisory, which has the pertinent information rather than a publicity stunt.
srcrip | 32 minutes ago
Yes the design is a little slop-y, but interesting vulnerability… does this have a CVE then? Not sure how that works. Does this effect anyone running default alpine docker up on the internet then? If you run a docker container with alpine that has ssh installed, are we saying it’s possible to log into the ‘alpine’ user that way by default?
dullmirror | 2 hours ago
That was a fun read!
Luckily
PermitRootLoginhasn't allowed logins with passwords for root since 2015. I'm guessing that's at least part of why this went undiscovered for so long.For this to hit
rootI believe you'd have to actively allow password-logins for a root-account that doesn't have a password, which seems like a weird thing to do. But people are forgetful, so it's entirely possible to end up in this situation. I'm glad OpenSSH decided to patch even though they "consider the root cause of this bug to be outside sshd".gcupc | an hour ago
First thing I do on any server is turn off password authentication, for years, just because of all the automated brute force attempts. I fail2ban them, of course, but there are always more. It can be a pretty big inconvenience when I have a new device, but I'm just living with it.
ramones | 2 hours ago
what did u call me ?