Jason Hall

Saw the Neuromancer trailer. In the book, Case is NOT "the best console man around." He's a junkie, his ability to jack into the matrix chemically burned away, dealing drugs and trying to provoke some contact into putting him out of his misery. Armitage chooses him because he's dispensable. So, as so often, I have mixed feelings about the trailer. Anyway, about time I reread the books.

Can you and I overcome the propensities of the natural man or woman through willpower and goal setting and determination and discipline? No. We learn in the Book of Mormon that the Savior is at the center of our transformation: “For the natural man is an enemy to God, and has been from the fall of Adam, and will be, forever and ever, unless he yields to the enticings of the Holy Spirit, and putteth off the natural man and becometh a saint THROUGH the Atonement of Christ the Lord” (Mosiah 3:19).

An OpenSSH bug that took 46 years to ripen! 1980 UNIX puts * in the password field of system accounts. The idea is simple: it’s not a real hash, so it can’t be brute-forced and you can’t log in with a password. 2012 The musl libc developers decide that returning NULL from crypt() on failure is dangerous - programs often forget to check it and crash with a segfault. So they return an error string instead. Guess which one? The same asterisk: *. Three weeks later they add a length limit: passwords longer than 256 bytes burn CPU. Anything longer is rejected. And since it’s an error, crypt() returns *. 2016 OpenSSH fixes a timing attack (CVE-2016-6210). If a user doesn’t exist, the server still hashes the password with a fake/borrowed salt so an attacker can’t tell valid usernames by response time. 2022 Alpine Linux changes the locked root password in /etc/shadow from ! to * so SSH keys work properly on cloud images. … and the loop closes! You connect over SSH as root (whose shadow entry is *). You type any password longer than 256 characters (e.g. 300 As). crypt() hits the length limit → returns * → OpenSSH compares it with the value in the database → that value is also * → you’re in as root. That chain took 46 years (!!!) to complete. Every individual change was reasonable. Together they produced a perfect * == * authentication bypass (CVE-2026-123158, nicknamed *sshole). Fixed in OpenSSH 10.6p2 and Alpine packages.

Kote kay sa a ye? Ban nou adrès egzak la, n ap detwi l.

sshhole.com/ By now you have probably heard about the sshhole bug. I didn't want to talk about on X until it had already attracted enough notice here that my analysis wouldn't be revealing anything to potential bad guys. It's really, really bad for Alpine Linux systems and others using MUSL as their C library. However, I think we've dodged the bullet that was the worst possible case: it could have opened a gaping root-access hole in any router running OpenWRT. That's, like, maybe 30% of them? On the order of 100-500M units worldwide. These are not yet confirmed findings, because frickin' chatGPT doesn't consider me authorized to do security analysis using it. I'm posting this hoping a real infosec guy with those creds can confirm. I first learned of this bug this morning when @dfranke texted me "Anyone with an OpenWRT router needs to unplug it. Now. Run." On further investigation, though, the bug only seems to bite if you have a root account that has shell access and a password field of "*" (disabled). Out of the box, OpenWRT ships with an empty root password. This is not the same as a "*" password field and should prevent the MUSL bug from biting. And while it's quite common to disable password access to that account, usually people do that with SSH server-side configuration rather than by modifying the password file in the dangerous way. All the other avccounts OpenWRT configures in have a shell entry "/bin/false", So you can exercise this bug on the ones with password field "*", but you can't exploit it. So unless you've done something rather weird to its configuration, your OpenWRT based router is probably okay. You should, however, inspect it to make sure that your root account has a password ("x" entry in the hash field) and all the accounts that don't have shell access safely directed to /bin/false. But again, this is not a confirmed result. If you're an infosec guy with the right tools, please check it immediately.