A major vulnerability in CoreOS Linux Alpha has been patched, with the issue limited to versions 104x.0.0 of the distribution.
In the blog post Major Remote SSH Security Issue in CoreOS Linux Alpha, Subset of Users Affected the CoreOS Security Team described the issue saying:
A misconfiguration in the PAM subsystem in CoreOS Linux Alpha 1045.0.0 and 1047.0.0 allowed unauthorised users to gain access to accounts without a password or any other authentication token being required. This vulnerability affects a subset of machines running CoreOS Linux Alpha.
According to the team, the issue was reported at May 15 at 20:21, and a fix was available just six hours later. Machines running CoreOS Linux Beta or Stable releases were not affected.
In a debrief of the issue, published on the CoreOS blog on May 19, principal security engineer, Matthew Garrett, said the team had received notification from someone who "had identified a system compromise." It was reported that an attacker had logged in as the operator user "and was using the compromised system to send spam."
"This was initially confusing, as the operator user is disabled, but we were able to duplicate the issue internally," Garett said. It was discovered that someone could log into the operator and core accounts with any password "even if the accounts had not been provisioned with passwords."
Garrett elaborates that the vulnerability was narrowed down to a coreos-overlay commit, where Red Hat's System Security Services tools had been integrated into CoreOS to enable user authentication. The issue came down to a difference between Gentoo-based systems and Red Hat-based systems. Where the former defaults to ending the PAM configuration with an optionalpam_permit, the latter defaults to a required pam_deny. In this instance, the configuration fell through to pam_permit, and allowed users to log in.
Explaining how this could happen, even though the operator user was disabled, Garrett said the operator user "exists on several UNIX-like systems, and is present in many automated SSH attack scripts, so the presence of an operator user that could be accessed without a valid password left systems vulnerable to these automated attacks."
On Hacker News, Kamil Choudhury commented on a discussion of the debrief, asking "Am I wrong in thinking of this as an overreaction?"
Garrett replied, explaining that there was "no strong reason" to believe that alpha releases had worse security than other releases.
I think that one of the strengths of distributed computing is that you can run a subset of your deployment on alpha without worrying that bugs are going to take down your entire deployment. That makes it much easier for you to have confidence that new stable releases won't break things for you, which means you can adopt stable releases more quickly, and avoid the security risks inherent in running older versions of software.
For that to be possible, users need to be confident that alpha releases were not being shipped "with gaping security issues," Garrett said, "It is a big deal when we fail in that respect."