看起来CVE-2018-10933刚刚于今天发布,您可以在libssh此处找到摘要。

摘要:


libssh 0.6及更高版本具有服务器代码中的身份验证绕过漏洞。通过向服务器提供SSH2_MSG_USERAUTH_SUCCESS消息代替服务器希望进行身份验证的SSH2_MSG_USERAUTH_REQUEST消息,攻击者可以在没有任何凭据的情况下成功进行身份验证。及其影响范围。 Debian,Ubuntu之类的操作系统是否依赖libssh进行SSH,如果这样做,是否意味着每台公开SSH的服务器都容易受到此攻击?另外,OpenSSH是否依赖libssh还是它们是两个单独的实现?我尝试寻找OpenSSH vs libssh,但是找不到我想要的东西。这个漏洞听起来像是SSH最坏的情况,所以我感到惊讶的是它还没有成为头条新闻或爆炸。此漏洞的摘要含糊不清,因此我正在寻找有关影响范围以及在什么情况下我应该担心的任何见解。

#1 楼


... OpenSSH是否依赖libssh


OpenSSH(大多数系统上是标准的SSH守护程序)不依赖libssh。


我试图寻找opensshv.s。 libssh ...


实际上,搜索openssh libssh首先给了我:OpenSSH / Development,其中包括libssh的以下语句:“ ... libssh是一个独立的项目。 ..“”

此外,如果OpenSSH会受到影响,您可以确保在OpenSSH的官方站点上找到此类信息,该站点上明确包含有关OpenSSH安全性的页面。


Debian,Ubunutu之类的操作系统是否依赖libssh进行SSH ...


(至少)请参阅libssh的官方文档,以了解谁在使用它:KDE, GitHub ...

您还可以检查自己的操作系统上哪些可用或已安装的软件包取决于libssh。例如对于Debian和类似的产品(例如Ubuntu),应为apt rdepends libssh-4apt rdepends --installed libssh-4。首先,该问题似乎仅与将libssh用于SSH服务器而不是客户端有关。而且即使在服务器角色中也不一定受到影响,例如,即使Github在服务器角色中使用libssh,似乎也不受影响。

评论


由于KDE将其用于SFTP,所以我猜他们不使用服务器代码。一定让GitHub听起来很有趣...

– AndrolGenhald
18-10-16在18:54

Debian 8上的apt不了解rdepends。在那里,您可以改用apt-cache rdepends libssh-4。

– Arjen
18-10-17在7:55

“是一个独立的项目”是一个模棱两可的说法。这可能意味着它是独立开发的,但仍依赖/链接。

– Grzegorz Oledzki
18-10-19在7:44

@GrzegorzOledzki:我同意,可能有必要遵循我提供的链接,并仔细查看此声明的更多上下文,以确保不依赖libssh或将其链接到OpenSSH中。

– Steffen Ullrich
18-10-19在14:16



#2 楼


Debian,Ubuntu等操作系统是否依赖libssh进行SSH,如果这样做,是否意味着每台公开SSH的服务器都容易受到此攻击?


使用libssh的应用程序可能会出现问题。如libssh网站上所述:“ libssh是一个C库,使您能够编写使用SSH协议的程序。”因此,使用libssh库的用户应用程序可能容易受到攻击,而不是操作系统本身。以下是一些使用libssh的应用程序(来自libssh网站):


KDE使用libssh进行sftp文件传输
GitHub通过libssh实现了git ssh服务器
X2Go是适用于Linux的远程桌面解决方案


另外,OpenSSH是否依赖libssh还是它们是两个单独的实现?


不,不是。他们是分开的。


更新2018-10-18:由漏洞发现程序撰写的博客文章现已提供,其中包括详细说明以及概念验证代码(通过Paramiko)。 br />
链接到博客的文章解释说,该漏洞是由以下事实造成的:即使在服务器(即使这样)中,包处理调度表(在libssh \ src \ packet.c中)的代码也执行SSH2_MSG_USERAUTH_SUCCESS的处理程序一条消息仅应由客户端处理)。对代码的进一步研究表明,在libssh \ src \ auth.c中对消息的这种错误处理导致服务器将会话状态更改为已验证!

还提供了详细的概念验证代码,显示可以更新python Paramiko来发送SSH2_MSG_USERAUTH_SUCCESS消息来代替SSH2_MSG_USERAUTH_REQUEST消息并利用此漏洞。

,博客文章还指出:


“并不是所有的libSSH服务器都必然会受到身份验证绕过的攻击;由于身份验证绕过将内部libSSH状态机设置为经过身份验证,而没有给予任何已注册的身份验证回调机会执行,因此使用libSSH开发的服务器会保持其他自定义会话状态,因此可能会失败如果在未创建此状态的情况下对用户进行了身份验证,则可以正常运行。“


评论


“ OpenSSH声明他们使用LibreSSL的一部分(libcrypto部分),而不是libssh” –在您提供的链接中,OpenSSH仅声明它使用LibreSSL。它没有声明它不使用libssh,而且我认为也不能从他们在这里写的内容中得出这个结论。

– Steffen Ullrich
18-10-16在19:17



-1:libssh和LibreSSL唯一的共同点是两个名称均以“ lib”开头。

–马克
18-10-16在20:59

@Mark:“ ...如何使用LibreSSL []的一部分,而不使用libssh。”甚至建议否则?

–贡特拉姆·布洛姆(Guntram Blohm)
18-10-16在21:17

@Mark,它们的名称都具有double,并且都与加密相关。

–PaŭloEbermann
18-10-16在21:20

好的...更新的答案...呃,做得更好。 LibreSSL与libssh无关,这就是重点,我当时指出这一点……我想那是令人困惑的。

–hft
18-10-16在22:05



#3 楼

要通过命令行查看应用程序的依赖性,您可以运行以下命令:

ldd / usr / sbin / ssh

这将显示该应用程序的任何依赖性。执行此命令时,它不会显示libssh,这意味着libssh不是OpenSSH的一部分。

评论


除非它是静态链接的(不是这样,但仅通过运行ldd不能确定)。

– AndrolGenhald
18-10-17在14:26

@AndrolGenhald,您可以进行混合链接:某些库的静态链接和其他库的动态链接。

–马克
18-10-17在22:41

@Mark我知道,我的意思是OpenSSH不会静态链接libssh,但是运行ldd不会告诉您。

– AndrolGenhald
18-10-17在23:40