Memory errors in sample programs (not in the library)

[mpg]

Summary

• At programs/ssl/ssl_server2.c:1390 (dummy_ticket parse), a ticket shorter than the expected header underflows the length used for the subsequent session load, reading past the ticket buffer. Reached when ssl_server2 has dummy_ticket enabled and a peer sends a 1–3 byte ticket (mbedtls_ssl_handshake via programs/ssl/ssl_server2.c:3385), controllable by an anonymous TLS client.
• At programs/ssl/ssl_context_info.c:885 (ALPN tail parsing of the decoded context), the tool calls strlen/compares on data whose length is not bounded against the decoded buffer. Reached from ssl_context_info -f <base64 file> (main, programs/ssl/ssl_context_info.c:903; file input :215), controllable by a local CLI user supplying the input file.

These are not security issues because they are squarely in sample programs, not the library, so not covered by our security guarantees.

But we should still fix those both as a matter of principle, and to avoid this popping up in the middle of investigating unrelated issues in the future.

Note: while at it, may want to edit the readme and/or security.md in order to make the status of sample programs clearer.

[abtom87]

1. Underflow in dummy_ticket_parse (ssl_server2.c)
   I would fix it by checking if the length passed to dummy_ticket_parse is less than 4 bytes and return MBEDTLS_ERR_SSL_BAD_INPUT_DATA if it is the case.

2. ALPN parsing in print_deserialized_ssl_context (ssl_context_info.c)
   I am confused as to why strlen is used here. Is \0 always expected after the ALPN negotiation bytes? strlen would also return an incorrect vale when it encounters 0 within the ALPN negotiation bytes. Or? Am i missing something else?
   I would drop the strlen check entirely and rewrite it something like this.

if (alpn_len > 0) {
   fwrite(ssl, 1, alpn_len, stdout);
} else {
    printf("not selected\n");
}
ssl += alpn_len;

Would love to know your thoughts? @mpg @gilles-peskine-arm