points by andix 2 days ago | 0 comments
A lot of embedded systems use musl and no PAM. Some of them might use Alpine, but the distribution doesn't matter that much.
[–] tonnydourado 2 days ago
And ssh? I'd assume most would use proprietary or industry-specific standard for data IO, or just https, for domestic IoT stuff
[–] andix 2 days ago
And also ssh in many cases.
[–] pera 2 days ago
I thought Dropbear was pretty much the defacto SSH server for embedded applications, is OpenSSH+musl actually a common combination for these scenarios?
[–] 0x457 2 days ago
Well, OpenWrt is OpenSSH + musl.
[–] pera 2 days ago
OpenWrt uses Dropbear by default:
https://openwrt.org/docs/guide-user/services/ssh/transfer_dr...
[–] pizlonator 2 days ago
We don’t know that dropbear isn’t vulnerable. The bug here is in musl and OpenSSH is just being a bro by working around it
[–] hnfong 2 days ago
I wouldn't say the bug is only in musl. Musl is probably the "worst" offender here (at least choose something other than "*"!), but the change in sshd was also a little suspect. i.e. the "let's find a user and take their salt (and hashing algorithm) and use it to compute and compare the hash to avoid timing attacks" change.
I haven't thought it through, but I suspect in an ideal world, sshd shouldn't have accepted the user password regardless of the outcome of crypt() if the user did not exist and it only pretended to go through the motions to avoid a timing attack.
Did look into their patch yesterday(?) which seemed to mitigate this issue which they (rightfully IMHO) consider caused by musl. But it seems their fix is to do a sanity check on the supposed hashed password char length, and thus still theoretically still allowing the possibility of those "!!!INVALID_PASSWORD!!!" suggestions to fall through....
[–] gsich 2 days ago
Tried it, doesn't work.
[–] 3m4r 2 days ago