[Bug 2366] New: ssh-keygen doesn't correctly decode new format GCM-encrypted keys

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2366

            Bug ID: 2366
           Summary: ssh-keygen doesn't correctly decode new format
                    GCM-encrypted keys
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: ronf at timeheart.net

Created attachment 2567
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2567&action=edit
Patch for sshkey.c in OpenSSH 6.7p1

I was trying out the new OpenSSH private key format and I ran into a
problem when trying to work with keys encrypted in aes128-gcm and
aes256-gcm format. While ssh-keygen encrypted these keys correctly, it
was not able to decrypt them. I've identified the problem as an issue
with the lengths it passes into cipher_crypt() when dealing with a
cipher with integrated MAC support.

Steps to reproduce:

1) Create a new format key with a command like:
      ssh-keygen -t ed25519 -N test -Z aes128-gcm at openssh.com -f
new_key

2) Attempt to decrypt this key with a command like:
      ssh-keygen -p -P test -N '' -f new_key

With OpenSSH 6.7p1, this fails with the error "Bad passphrase" for
aes128-gcm and aes256-gcm, but works correctly for other ciphers which
don't include a built-in MAC. The error happens for all key types when
using the new private key format.

The error is in the call inside sshkey_parse_private2() where it passes
in the length of the encrypted buffer:

        if ((r = cipher_crypt(&ciphercontext, 0, dp,
sshbuf_ptr(decoded),
            sshbuf_len(decoded), 0, cipher_authlen(cipher))) != 0) {

The length here should be encrypted_len, not sshbuf_len(decoded), as
that includes the cipher_authlen(cipher) additional MAC bytes.

A few additional changes are needed to use encrypted_len safely here
and to later properly consume the auth data. I have attached a patch
which I believe fixes this problem.

With the fix, step 2 above succeeds and properly decrypts the key
created in step 1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.