They found a vulnerability in openSSH 9.1 that allows bypassing malloc

Recently Qualys (a technology company that specializes in cloud security) made it known what have you found a way to bypass malloc and doubleless protection to initiate a crossover using a vulnerability in OpenSSH 9.1.

So far it has been determined that such vulnerability is only "theoretical", as it is unlikely to create a working exploit. At the same time, the possibility of creating a working exploit remains a big question.

Regarding vulnerability, it is mentioned that the trick to bypass the protections double free and use after free from malloc is to reallocate the memory that was occupied by options.kex_algorithms as soon as it is free.

From malloc's point of view, no attempt is made to free, read, or write memory that is already free; from the point of sshd, however, an aliasing attack occurs, since two different pointers to two different objects refer to the same chunk of memory, and a write to one object overwrites the other object.

This opens up a world of possibilities.

We started our investigation into the Debian bookworm (which uses the glibc code
malloc), but we eventually switched to OpenBSD 7.2, because OpenBSD
malloc (despite its very defensive programming) has two features that
make it especially interesting for this particular free double bug:

The vulnerability is due to a double release of a memory area in the pre-authentication stage. To create conditions for vulnerability, just change the banner of the SSH client to "SSH-2.0-FuTTYSH_9.1p1" (or another old SSH client) to achieve setting the "SSH_BUG_CURVE25519PAD" and "SSH_OLD_DHGEX" flags After setting these flags, the memory for the "options.kex_algorithms" buffer is freed twice .

Qualys researchers, in the course of vulnerability manipulation, were able to gain control over the processor register "%rip", A containing a pointer to the next statement to be executed. The exploit technique developed allows control to be transferred to any point in the address space of the sshd process in an out-of-date OpenBSD 7.2 environment, which ships by default with OpenSSH 9.1.

Quick update: We were able to get arbitrary control of the "rip" via this bug (i.e. we can jump wherever we want in sshd's address space) on an unpatched installation of OpenBSD 7.2 (running
OpenSSH 9.1 by default). This is by no means the end of the story: this eFor just step 1, skip the malloc and double guards.

The following step that may or may not be feasible at all, are:

– step 2, execute arbitrary code despite ASLR, NX and ROP
protections (this will likely require an information leak, either
by the same error or by a secondary error);

– step 3, escaping the sshd sandbox (via a minor bug, either in
the privileged parent process or in the reduced kernel attack
surface).

It is noted that the proposed prototype is the implementation of only the first stage of the attack: To create a working exploit, you need to bypass the ASLR, NX, and ROP protection mechanisms, and break out of sandbox isolation, which is unlikely.

Solving the problem of bypassing ASLR, NX, and ROP requires obtaining address information, which can be accomplished by identifying another vulnerability that leads to information leakage. A bug in a privileged parent or kernel process can help break out of the sandbox.

The vulnerability is mentioned to work as follows:

• -First, free options.kex_algorithms in compat_kex_proposal(), pretending the ssh client is an old "FuTTY" client.
• -Secondly, the fragment that was occupied by options.kex_algorithms is reallocated, with a structure EVP_AES_KEY whose size is 264 bytes, selecting the “aes128-ctr” cipher during the key exchange phase. This reallocation occurs with a probability of ~1/32.
• – Third, freeing (again) the chunk that was occupied by options.kex_algorithms (and is now occupied by the EVP_AES_KEY structure) in kex_assemble_names() (via mm_getpwnamallow()). This happens if and only if the first byte of the chunk is '+', '-', or '^' (otherwise kex_assemble_names() returns an error and fatal_fr() is called).
• – Fourth, the chunk that was occupied by options.kex_algorithms (and is still referenced as an EVP_AES_KEY structure now) is reassigned, with a 300 'A' byte string, "authctxt->user" or "authctxt ->style" during the authentication phase. This reallocation, which effectively overwrites the entire EVP_AES_KEY structure with 'A' bytes, occurs with a probability of ~2/32.
• – Finally, it jumps to 0x4141414141414141 when sshd calls EVP_Cipher(), because the EVP_AES_KEY structure contains a function pointer that was overwritten by our 'A' bytes and is called by CRYPTO_ctr128_encrypt_ctr32() (via EVP_Cipher()) .

Finally, if you are interested in knowing more about it, you can consult the details In the following link.