The second vulnerability is needed for a successful attack: But how to trigger this memory error on the client in a real-world scenario. One option was to put a very long key on the fake server, but they were limited by the maximum size of the packet that is exchanged during the handshake which is around 256KB and this is not nearly enough to consume all of the client’s memory.This meant the researchers needed another vulnerability that could be triggered before authentication and would consume as much of the client process’ memory before serving the rogue server key in an attempt to trigger an out-of-memory SSH_ERR_ALLOC_FAIL error.”As yet another testimony to OpenSSH’s code quality, we actually failed to find a pre-authentication memory leak,” the researchers wrote in their advisory. “Instead, we found an unlimited allocation of memory that is not freed until the very end of the initial key exchange.”This is the second vulnerability, CVE-2025-26466, which impacts both client and server deployments of OpenSSH. And while it can lead to denial-of-service on both clients and servers, on the client it can also be used to set up the ground for exploiting the other vulnerability and make the man-in-the-middle attack possible.”If fake-server does implement the out-of-memory attack discussed previously (by allocating a 1024-bit RSA key and a ~140KB certificate extension, plus ~234MB of PONG packets, but many other combinations work), then the client’s call to sshkey_from_private() returns SSH_ERR_ALLOC_FAIL, and its checks of the real-server’s host key are completely bypassed, thus allowing the fake-server to successfully impersonate the real-server,” the researchers explained in their proof-of-concept exploit scenario.
First seen on csoonline.com
Jump to article: www.csoonline.com/article/3827268/openssh-fixes-two-flaws-that-enable-a-man-in-the-middle-attack-and-denial-of-service.html
