Qualys Reveals Critical OpenBSD Mail Server Security Flaw
Qualys Research Labs disclosed this week a security flaw in the OpenSMTPD mail server used within the OpenBSD operating system that allows a cyberattacker to execute arbitrary shell commands with elevated privileges at a root level.
Jimmy Graham, senior director of product management for Qualys, said that OpenBSD flaw is severe enough to warrant an immediate patch that has been made available by the OpenBSD community. In addition, other distributions of Linux that might be using the OpenSMTPD mail server should apply the patch immediately, said Graham. It’s not known yet if cybercriminals or nation-states have already discovered this potential exploit to inject code into OpenBSD systems, but now that it’s been disclosed the skills required to exploit it are not especially high, added Graham.
This vulnerability exists in OpenBSD’s mail server OpenSMTPD’s “smtp_mailaddr()” function, and affects OpenBSD version 6.6. The exploitation of the vulnerability had some limitations in terms of local part length (max 64 characters is allowed) and characters to be escaped (“$”, “|”). Qualys researchers were able to overcome these limitations using a technique from the Morris Worm by executing the body of the mail as a shell script in Sendmail.
Graham said Qualys discovered the vulnerability as part of its ongoing research efforts to identify vulnerabilities in widely employed software. Once the OpenSMTPD mail server vulnerability was discovered, Qualys worked with the OpenBSD on the timing of the disclosure to make sure a patch was available, he said.
The challenge, of course, is that patch management processes in most organizations are often flawed. In an ideal world, organizations would be relying more on a patch management system that automatically tracks and prioritizes vulnerabilities, Graham said. Qualys customers can track all OpenBSD vulnerabilities via the OpenBSD Vulnerabilities Dashboard.
Ideally, patch management will one day become a more natural extension of any set of best DevSecOps processes. Each new vulnerability discovered will be prioritized within the context of a continuous integration/continuous deployment (CI/CD) platform. DevOps teams will then decide based on the level of risk from known vulnerabilities how much time to devote to building patches versus adding new features and capabilities. It will then be up to cybersecurity teams to verify whatever patches created have been properly installed. The biggest DevSecOps challenge now may not be so much the technology involved as much as it getting two disparate cultures to work in a more hand-in-glove fashion.
In the meantime, cybersecurity teams should expect to see the steady stream of vulnerability disclosures to continue. Organizations may not always appreciate the disruption such disclosures can create, but the alternative is even more unacceptable. There’s always a probability that bad actors are already exploiting a vulnerability that has just been disclosed for a significant amount of time. Once the disclosure is made, it then becomes a race to implement the patch before cybercriminals start actively looking to exploit it. Hopefully, one day soon machine learning algorithms will make it a lot easier to determine where all those patches should be applied.
