3

I just saw the notification about CVE-2016-1907 this morning:

The ssh_packet_read_poll2 function in packet.c in OpenSSH before 7.1p2 allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via crafted network traffic.

I can't find any other information about it beyond the general note in the release notes:

SECURITY: Fix an out of-bound read access in the packet handling
code. Reported by Ben Hawkes.

Chromium won't let me view the changes in the source repository (expired certificate plus HSTS) so I haven't tried looking at the patch itself yet.

Has anyone posted any analysis of this defect? At the very least I'd like to know if it affects the client, server, or both (e.g. if someone without an account could DoS an arbitrary server).

  • looks like I forgot about the last line about DoS attack. You could create intensive traffic, but the amount of running network children on server is always limited to MaxStartups option in sshd_config. Every attempt to miss-use this vulnerability would cause TCP disconnect. – Jakuje Jan 26 '16 at 9:33
3

This is good question. I investigated this issue two weeks ago as it was out. This bug appeared for the first time in openssh-6.8 in refactoring commit. Basically the issue is that there was replaced function which called exit() with function only returning error value.

if (state->packlen < 1 + 4 ||
    state->packlen > PACKET_MAX_SIZE) {
#ifdef PACKET_DEBUG
    sshbuf_dump(state->input, stderr);
#endif
    logit("Bad packet length %u.", state->packlen);
    if ((r = sshpkt_disconnect(ssh, "Packet corrupt")) != 0)
        return r;
    return SSH_ERR_CONN_CORRUPT; /* <-- this line was added */
}
sshbuf_reset(state->incoming_packet);

As you can see in the context of current version (snapshot above), this branch handles wrong packet lengths (smaller than 5 B and larger than PACKET_MAX_SIZE). This condition threw error message, disconnected packet and should have return. But the sshpkt_disconnect() might have failed and at this point, the code execution would continue to the function further, handling the buffers received from the other peer as valid, without additional checks. The code is used in both server and client.

As you see, the CVSS Severity is quite lower than than the other CVE released with the same version. To successfully exploit this bug, wou would have to craft packet fitting above condition (wrong length), make sure the sshpkt_disconnect() fails (close the socket?) and blindly expect that the evil things happen. Attack surface is much more limited and less investigated than CVE-2016-0778, where was even proof of concept with crafted server.

Also note that openSSH implements privilege separation so on server, which would give you basically just the possible code execution in the limited net child in the sandbox. On the other hand, you could use code execution on client side using crafted malicious server, but for the price of client disconnection. The user would probably be suspicious, but not the scripts (autossh, rsync jobs and similar).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.