-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't fail with InvalidLength when reading nothing at end of data #1387
Conversation
If a "PEM-like" OpenSSH format private key: 1. has no comment; 2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and*** 3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding; then `ssh_key::private::PrivateKey::from_openssh` fails to successfully parse the key. The root cause is `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads when the base64-encoded buffer was empty. This wouldn't happen if: 1. the key had a comment, because that wouldn't be a zero-length read; 2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or* 3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes). Debugging this was... an amusement. The most reliable way to demonstrate this is with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`), because they *usually* (but not *always*) are of an appropriate length to trigger the bug. Amusingly (cough), the existing ECDSA P-256 key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.
5222491
to
bc3c2fc
Compare
If a "PEM-like" OpenSSH format private key: 1. has no comment; 2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and*** 3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding; then `ssh_key::private::PrivateKey::from_openssh` fails to successfully parse the key. The root cause is `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads when the base64-encoded buffer was empty. This wouldn't happen if: 1. the key had a comment, because that wouldn't be a zero-length read; 2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or* 3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes). Debugging this was... an amusement. The most reliable way to demonstrate this is with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`), because they *usually* (but not *always*) are of an appropriate length to trigger the bug. Amusingly (cough), the existing ECDSA P-256 key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.
Is this really necessary and the best solution? Wouldn’t it be better not to perform a zero length read in the first place? |
If "don't perform zero length reads" is the best solution, that's cool, although in that case it would be better, IMO, if this method always rejected zero length reads. The thing that made this bug so hard to track down was the fact that the zero length read only failed in a very narrow set of circumstances. |
I think it's fine to always reject zero length reads |
Righto, I'll rework the PR to go that way. |
ad32016
to
ade0ecb
Compare
Adjust to the changes to `base64ct` that reject zero-length decode() calls as invalid. The underlying trigger for this change was to avoid problems with decoding certain OpenSSH private keys. If a "PEM-like" OpenSSH format private key: 1. has no comment; 2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and*** 3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding; then `ssh_key::private::PrivateKey::from_openssh` failed to successfully parse the key. The root cause was `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads, *only* when the base64-encoded buffer was empty. This only happened for reading empty comments, because comments are at the end of the key. It *wouldn't* happen if: 1. the key had a comment, because that wouldn't be a zero-length read; 2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or* 3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes). Debugging this was... an amusement. The most reliable way to demonstrate this was with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`), because they're *usually* (but not *always*) an appropriate length to trigger the bug. Amusingly (cough), the existing ECDSA P-256 test key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.
ade0ecb
to
b44f92d
Compare
b44f92d
to
e72445c
Compare
OK, base64ct now errors on zero-length decode requests, with |
Adjust to the changes to `base64ct` that reject zero-length decode() calls as invalid. The underlying trigger for this change was to avoid problems with decoding certain OpenSSH private keys. If a "PEM-like" OpenSSH format private key: 1. has no comment; 2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and*** 3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding; then `ssh_key::private::PrivateKey::from_openssh` failed to successfully parse the key. The root cause was `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads, *only* when the base64-encoded buffer was empty. This only happened for reading empty comments, because comments are at the end of the key. It *wouldn't* happen if: 1. the key had a comment, because that wouldn't be a zero-length read; 2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or* 3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes). Debugging this was... an amusement. The most reliable way to demonstrate this was with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`), because they're *usually* (but not *always*) an appropriate length to trigger the bug. Amusingly (cough), the existing ECDSA P-256 test key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.
This is a curious corner case that can happen when, for example, you're reading the length-value encoded strings in OpenSSH. If the last string in the data is of zero-length, then decode() will be called with an empty buffer, so we don't need to read any bytes. However, since
is_finished()
was checked unconditionally, the zero-length read (which would be OK) was instead rejected because there was no data to (not) read.The bug was particularly mischievous because
is_finished()
will return false if there's=
padding, so 2/3 of empty read calls will work normally.