[ad_1]
There is a four-year bug in the implementation of Secure Shell, libssh, which allows anyone to gain unhindered administrative control of a vulnerable server. Although the authentication bypass flaw represents a major security flaw that should be addressed immediately, it was not clear which sites or devices were vulnerable because neither the widely used implementation OpenSSH or Github's had not been affected.
The vulnerability, introduced in version 0.6 of libssh published in 2014, allows to connect by presenting to a server a message SSH2_MSG_USERAUTH_SUCCESS rather than the message SSH2_MSG_USERAUTH_REQUEST expected by the server, according to a notice published Tuesday. Feats are the equivalent of a Jedi Mental Tip, in which an opponent uses Force to influence or confuse weaker opponents. The last time the world witnessed an authentication-bypass bug that had such a serious and time-consuming impact, it was 11 months ago, when Apple's MacOS allowed users to log in as administrator without entering a password.
The effects of malicious exploits, assuming there was one during the more than four years the bug was active, are difficult to understand. In the worst case, attackers could use exploits to take full control of vulnerable servers. Attackers could then steal encryption keys and user data, install rootkits, and erase logs that logged unauthorized access. Anyone who has used a vulnerable version of libssh in server mode should consider performing a thorough audit of their network immediately after the update.
For its part, there was no immediate sign of the site's bite by big names, which bears the reference CVE-2018-10933. While Github uses libssh, site managers says on Twitter that "GitHub.com and GitHub Enterprise are not affected by CVE-2018-10933 because of the way we use the library." follow-up tweetThe GitHub security officers said they were using a custom version of libssh that implemented an authentication mechanism separate from the one provided by the library. As a precaution, GitHub has installed a patch released with Tuesday's notice.
Another limitation is that only vulnerable versions of libssh running in server mode are vulnerable, while client mode is not affected. Peter Winter-Smith, a researcher at the NCC security company who discovered the bug and privately reported it to libssh developers, told Ars that the vulnerability was a result of using the same machine state by libssh to authenticate clients and servers. Because exploits involve secure client behavior, but not sure of the server context, only servers are affected.
How many sites?
A search on Shodan revealed that 6,351 sites used libssh, but it is difficult to know the importance of the results. On the one hand, the research is probably not exhaustive. And on the other hand, like GitHub, using libssh does not automatically make a site vulnerable.
Rob Graham, CEO of Errata Security, said vulnerability "is a big problem for us, but not necessarily a problem for readers. It's fascinating that a component as reliable as SSH becomes your loss. "
Winter-Smith agreed. "I guess this will end up being a nomination for the most overdone bug, because half of the people on Twitter seem to be concerned that this is affecting OpenSSH and the other half (quite correctly!) Worry that GitHub is using libssh, while in fact, GitHub is not vulnerable, "he said." Remove GitHub and I guess there will be only a handful of random sftp servers or devices left. IoT, and few others! "
The researcher provided additional details about the bug:
The problem is essentially a bug in the libssh library, not to be confused with libssh2 or OpenSSH projects with the same name (especially the last), which results from the fact that the server uses the same state machine to authenticate clients and waiters.
The message distribution code that processes messages in client mode or in server mode (it is the same function) does not guarantee that the type of message received is adapted to the mode in which it is running. For example, the server will send messages that are only for client-side processing, even in server mode.
The SSH2_MSG_USERAUTH_SUCCESS message is used by the server to inform the client that they have been authenticated successfully. It updates the libssh internal state machine to mark the client as being authenticated with the server. I found that if the same message is sent to the server, it updates the state machine to tell the server that the client is authenticated.
Technically, I would say it's surprising to see how simple, serious bugs can still hide, and sometimes it pays to step back to avoid wasting time trying to understand how a protocol implementation works. .
Again, anyone running a vulnerable version of libssh must apply a fix immediately. And anyone who has used the application to receive incoming connections from unreliable users should consider looking closely at their servers for signs of compromise. At the same time, everything indicates for the moment that the number of devices affected by this high severity bug seems to be relatively small, a limitation that is lost for many people discussing this bug via social media.
This article will be updated as new information becomes available.
[ad_2]
Source link
