This Week in Security: OpenSSH, JumbledPath, and RANsacked

This Week in Security: OpenSSH, JumbledPath, and RANsacked

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.


The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.



1387 int
1388 sshkey_to_base64(const struct sshkey *key, char **b64p)
1389 {
1390 int r = SSH_ERR_INTERNAL_ERROR;
....
1398 if ((r = sshkey_putb(key, b)) != 0)
1399 goto out;
1400 if ((uu = sshbuf_dtob64_string(b, 0)) == NULL) {
1401 r = SSH_ERR_ALLOC_FAIL;
1402 goto out;
1403 }
....
1409 r = 0;
1410 out:
....
1413 return r;
1414 }

The potential bug? What if line 1401 was missing? That would mean setting r to the success return code of one function (1398), then using a different variable in the next check (1400), without re-initializing r to a generic error value (1401). If that second check fails at line 1400, the code execution jumps to the return statement at the end, but instead of returning an erro ..

Support the originator by clicking the read the rest link below.