It seems like the pattern emerging is that AI is great at finding these obscure vulnerabilities that are only exploitable on very particular systems with very particular, non-typical configurations, and only on nights where unicorns fart candycorn.
Sure, fix them, but the hype is too much. Also, disable password auth on SSH already. Jesus. Keys arnt that hard.
I think you’re buying snake oil, my friend. What is “AI”? Statistical tools have been used in security auditing for decades.
The people riding the AI bubble want you to think things are magically different right now, but we won’t know that until we can get some solid data over the next year or five to do a proper comparison.
More like AI is much faster at finding obscure vulnerabilities, because it doesn’t get tired of digging into the mind-numbing details of human-generated spaghetti code. Give a human the same kind of task, and they would die of boredom 12 hours into it.
We’re entering an age where AI is quickly cleaning up the stupid security holes that have been created by decades of human mistakes, and will continue to be this way until increased AI security reviews will become more standard. The tribals wielding spears will continue to get shot by superior firepower until they adapt to the same weapons and protection themselves.
“Finding” is also rather generous, going by numbers from Anthropic and from the Linux kernel, things like Mythos are wrong 95% of the time.
They’re much easier to run though, compared to more reliable tools. So even being wrong 95% of the time wins out if you’ve got 100x more people running them.
In my experience, the LLM usually proposes a solution, but it’s a crapshoot whether it works well. And plenty of bugfixes go well beyond a few lines, especially in older code.
I use this shit on a daily basis at work. They work well, as long as you’re choosing the right models, making the right engineering decisions, and have a good set of baseline rules.
This example demonstrates my point though. It requires an extremely unusual system configuration that may or may not even exist in the real world it is so unusual. AI doesnt get tired, like you said, but its not about spaghetti code (both musl and openssh are gold-standard opposite of spaghetti code), its about trying every possible software combination in ways a human wouldnt bother.
It requires an extremely unusual system configuration that may or may not even exist in the real world it is so unusual.
You have to remember that the same AI agents finding the code are also able to exploit the code. So, if it’s some extremely rare race condition requiring some convoluted pattern, it’s still easy to exploit.
I agree about the AI, but desktop Linux has never been under haxxor pressure the same way windows or apple has. I also think the newer parts of the userbase are less technical than even ten years ago. Previously undocumented bugs found and squashed is great for everyone.
Using password login renders this vulnerability useless.
This isn’t the case, though I can see how the article could lead you to believe that.
It’s directly based on password rather than key input. The entire vulnerability is that typing a password longer than 256 characters automatically defaults to crypt() outputting the * character instead of a normal password hash, which is coincidentally the same default character used as the “hash” (not actually a value you could get from a normal hash, intended to be impossible to get from any normal password for that reason) for the built-in daemon account.
When the Ars Technica article says “Second, the target system account must be configured to be passwordless”, what they mean is the default daemon account, which has a hash set to * by default, and thus wouldn’t normally be accessible via any hashed password… unless you happen to find out that the system chooses to not make a hash, and just send * if you type more than 256 characters.
Other way around. This requires a passwordless account configured with sha256 or sha512 password hash, musl system with openssh installed, no PAM, and password authentication allowed:
When logging into a passwordless account, the attacker can gain access by inputting more than 256 characters in the password field.
Can they please take a break from having vulnerabilities
nah, find and fix as many as possible.
It seems like the pattern emerging is that AI is great at finding these obscure vulnerabilities that are only exploitable on very particular systems with very particular, non-typical configurations, and only on nights where unicorns fart candycorn.
Sure, fix them, but the hype is too much. Also, disable password auth on SSH already. Jesus. Keys arnt that hard.
I think you’re buying snake oil, my friend. What is “AI”? Statistical tools have been used in security auditing for decades.
The people riding the AI bubble want you to think things are magically different right now, but we won’t know that until we can get some solid data over the next year or five to do a proper comparison.
More like AI is much faster at finding obscure vulnerabilities, because it doesn’t get tired of digging into the mind-numbing details of human-generated spaghetti code. Give a human the same kind of task, and they would die of boredom 12 hours into it.
We’re entering an age where AI is quickly cleaning up the stupid security holes that have been created by decades of human mistakes, and will continue to be this way until increased AI security reviews will become more standard. The tribals wielding spears will continue to get shot by superior firepower until they adapt to the same weapons and protection themselves.
“Cleaning up” seems a little generous. It’s finding them, but someone still has to patch them.
“Finding” is also rather generous, going by numbers from Anthropic and from the Linux kernel, things like Mythos are wrong 95% of the time.
They’re much easier to run though, compared to more reliable tools. So even being wrong 95% of the time wins out if you’ve got 100x more people running them.
Most vulnerability patches are a few lines of code. Finding it is the hard part.
Even then, the AI session that found it probably already has a solution to fix it.
In my experience, the LLM usually proposes a solution, but it’s a crapshoot whether it works well. And plenty of bugfixes go well beyond a few lines, especially in older code.
I use this shit on a daily basis at work. They work well, as long as you’re choosing the right models, making the right engineering decisions, and have a good set of baseline rules.
This example demonstrates my point though. It requires an extremely unusual system configuration that may or may not even exist in the real world it is so unusual. AI doesnt get tired, like you said, but its not about spaghetti code (both musl and openssh are gold-standard opposite of spaghetti code), its about trying every possible software combination in ways a human wouldnt bother.
You have to remember that the same AI agents finding the code are also able to exploit the code. So, if it’s some extremely rare race condition requiring some convoluted pattern, it’s still easy to exploit.
I agree about the AI, but desktop Linux has never been under haxxor pressure the same way windows or apple has. I also think the newer parts of the userbase are less technical than even ten years ago. Previously undocumented bugs found and squashed is great for everyone.
Have any of these new vulnerabilities been desktop linux?
How would i know? The write up only touched a handful of things.
This particular vulnerability is precisely about logins with key. Using password login renders this vulnerability useless.
This isn’t the case, though I can see how the article could lead you to believe that.
It’s directly based on password rather than key input. The entire vulnerability is that typing a password longer than 256 characters automatically defaults to
crypt()outputting the*character instead of a normal password hash, which is coincidentally the same default character used as the “hash” (not actually a value you could get from a normal hash, intended to be impossible to get from any normal password for that reason) for the built-indaemonaccount.When the Ars Technica article says “Second, the target system account must be configured to be passwordless”, what they mean is the default
daemonaccount, which has a hash set to*by default, and thus wouldn’t normally be accessible via any hashed password… unless you happen to find out that the system chooses to not make a hash, and just send*if you type more than 256 characters.Look at https://sshhole.com/ if you want the details.
Oh, thanks for details! Missed that.
Other way around. This requires a passwordless account configured with sha256 or sha512 password hash, musl system with openssh installed, no PAM, and password authentication allowed: