<story><title>Authentication Vulnerabilities in OpenBSD</title><url>https://www.openwall.com/lists/oss-security/2019/12/04/5</url></story><parent_chain><item><author>notaplumber</author><text>Most of the issues are classified as Local privilege escalation, and none of the daemons mentioned are enabled by default, sshd can be enabled in the installer, but as the quote says &amp;quot;sshd is not exploitable thanks to its defense-in-depth mechanisms.&amp;quot;&lt;p&gt;So, no. Still holds.&lt;p&gt;Worth pointing that Linux has had a rough week as well, this one is pretty bad: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.openwall.com&amp;#x2F;lists&amp;#x2F;oss-security&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;02&amp;#x2F;2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.openwall.com&amp;#x2F;lists&amp;#x2F;oss-security&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;02&amp;#x2F;2&lt;/a&gt;&lt;p&gt;Patch your systems.</text></item><item><author>procinct</author><text>&amp;gt; this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.&lt;p&gt;Does this mean OpenBSD will have to update the tagline on their website that says &amp;quot;Only two remote holes in the default install, in a heck of a long time!&amp;quot;?</text></item></parent_chain><comment><author>technion</author><text>This discussion comes up a lot, and I&amp;#x27;d make an opposing case. Rather than debating whether OpenBSD can reasonably say this - I&amp;#x27;d suggest most Linux distributions could say it themselves if they so wanted.&lt;p&gt;Last time I installed CentOS the only port open on the firewall by default with OpenSSH after all.</text></comment>
<story><title>Authentication Vulnerabilities in OpenBSD</title><url>https://www.openwall.com/lists/oss-security/2019/12/04/5</url></story><parent_chain><item><author>notaplumber</author><text>Most of the issues are classified as Local privilege escalation, and none of the daemons mentioned are enabled by default, sshd can be enabled in the installer, but as the quote says &amp;quot;sshd is not exploitable thanks to its defense-in-depth mechanisms.&amp;quot;&lt;p&gt;So, no. Still holds.&lt;p&gt;Worth pointing that Linux has had a rough week as well, this one is pretty bad: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.openwall.com&amp;#x2F;lists&amp;#x2F;oss-security&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;02&amp;#x2F;2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.openwall.com&amp;#x2F;lists&amp;#x2F;oss-security&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;02&amp;#x2F;2&lt;/a&gt;&lt;p&gt;Patch your systems.</text></item><item><author>procinct</author><text>&amp;gt; this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms.&lt;p&gt;Does this mean OpenBSD will have to update the tagline on their website that says &amp;quot;Only two remote holes in the default install, in a heck of a long time!&amp;quot;?</text></item></parent_chain><comment><author>upofadown</author><text>Smtpd (one of the mentioned daemons) is started in a default install. It is configured to do local mail delivery and can queue up remote deliveries for programs running on the system. It only connects to localhost and does not authenticate so this exploit would be irrelevant. If one did open an authenticated mail connection on an interface accessible to the world then the exploit would allow the system to be used as a spam relay.&lt;p&gt;Added: Just to be clear, this doesn&amp;#x27;t give any significant access to the system itself through smtpd even if it is configured to be remotely accessible. So not a possible remote hole. Dunno about other stuff.</text></comment>