1. 07 Apr, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: rename *-asn1.[ch] to *.asn1.[ch] · 4fa8bc94
      Masahiro Yamada authored
      Our convention is to distinguish file types by suffixes with a period
      as a separator.
      *-asn1.[ch] is a different pattern from other generated sources such
      as *.lex.c, *.tab.[ch], *.dtb.S, etc.  More confusing, files with
      '-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in
      Rename generated files to *.asn1.[ch] for consistency.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  2. 08 Dec, 2017 1 commit
    • Eric Biggers's avatar
      X.509: reject invalid BIT STRING for subjectPublicKey · 0f30cbea
      Eric Biggers authored
      Adding a specially crafted X.509 certificate whose subjectPublicKey
      ASN.1 value is zero-length caused x509_extract_key_data() to set the
      public key size to SIZE_MAX, as it subtracted the nonexistent BIT STRING
      metadata byte.  Then, x509_cert_parse() called kmemdup() with that bogus
      size, triggering the WARN_ON_ONCE() in kmalloc_slab().
      This appears to be harmless, but it still must be fixed since WARNs are
      never supposed to be user-triggerable.
      Fix it by updating x509_cert_parse() to validate that the value has a
      BIT STRING metadata byte, and that the byte is 0 which indicates that
      the number of bits in the bitstring is a multiple of 8.
      It would be nice to handle the metadata byte in asn1_ber_decoder()
      instead.  But that would be tricky because in the general case a BIT
      STRING could be implicitly tagged, and/or could legitimately have a
      length that is not a whole number of bytes.
      Here was the WARN (cleaned up slightly):
          WARNING: CPU: 1 PID: 202 at mm/slab_common.c:971 kmalloc_slab+0x5d/0x70 mm/slab_common.c:971
          Modules linked in:
          CPU: 1 PID: 202 Comm: keyctl Tainted: G    B            4.14.0-09238-g1d3b78bb #26
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
          task: ffff880033014180 task.stack: ffff8800305c8000
          Call Trace:
           __do_kmalloc mm/slab.c:3706 [inline]
           __kmalloc_track_caller+0x22/0x2e0 mm/slab.c:3726
           kmemdup+0x17/0x40 mm/util.c:118
           kmemdup include/linux/string.h:414 [inline]
           x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
           x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
           asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
           key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
           SYSC_add_key security/keys/keyctl.c:122 [inline]
           SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
      Fixes: 42d5ec27
       ("X.509: Add an ASN.1 decoder")
      Cc: <stable@vger.kernel.org> # v3.7+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
  3. 10 Jun, 2017 1 commit
  4. 09 Jun, 2017 1 commit
  5. 25 Nov, 2016 1 commit
    • Andrey Ryabinin's avatar
      X.509: Fix double free in x509_cert_parse() [ver #3] · 2b95fda2
      Andrey Ryabinin authored
      We shouldn't free cert->pub->key in x509_cert_parse() because
      x509_free_certificate() also does this:
      	BUG: Double free or freeing an invalid pointer
      	Call Trace:
      	 [<ffffffff81896c20>] dump_stack+0x63/0x83
      	 [<ffffffff81356571>] kasan_object_err+0x21/0x70
      	 [<ffffffff81356ed9>] kasan_report_double_free+0x49/0x60
      	 [<ffffffff813561ad>] kasan_slab_free+0x9d/0xc0
      	 [<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	 [<ffffffff81844fbf>] public_key_free+0x1f/0x30
      	 [<ffffffff818455d4>] x509_free_certificate+0x24/0x90
      	 [<ffffffff818460bc>] x509_cert_parse+0x2bc/0x300
      	 [<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	 [<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	 [<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	 [<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	 [<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      	Object at ffff880110bd1900, in cache kmalloc-512 size: 512
      	PID = 2579
      	[<ffffffff8104283b>] save_stack_trace+0x1b/0x20
      	[<ffffffff813558f6>] save_stack+0x46/0xd0
      	[<ffffffff81356183>] kasan_slab_free+0x73/0xc0
      	[<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	[<ffffffff818460a3>] x509_cert_parse+0x2a3/0x300
      	[<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	[<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	[<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	[<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	[<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      Fixes: db6c43bd
       ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
  6. 06 Apr, 2016 3 commits
    • David Howells's avatar
      X.509: Extract signature digest and make self-signed cert checks earlier · 6c2dc5ae
      David Howells authored
      Extract the signature digest for an X.509 certificate earlier, at the end
      of x509_cert_parse() rather than leaving it to the callers thereof since it
      has to be called anyway.
      Further, immediately after that, check the signature on self-signed
      certificates, also rather in the callers of x509_cert_parse().
      We note in the x509_certificate struct the following bits of information:
       (1) Whether the signature is self-signed (even if we can't check the
           signature due to missing crypto).
       (2) Whether the key held in the certificate needs unsupported crypto to be
           used.  We may get a PKCS#7 message with X.509 certs that we can't make
           use of - we just ignore them and give ENOPKG at the end it we couldn't
           verify anything if at least one of these unusable certs are in the
           chain of trust.
       (3) Whether the signature held in the certificate needs unsupported crypto
           to be checked.  We can still use the key held in this certificate,
           even if we can't check the signature on it - if it is held in the
           system trusted keyring, for instance.  We just can't add it to a ring
           of trusted keys or follow it further up the chain of trust.
      Making these checks earlier allows x509_check_signature() to be removed and
      replaced with direct calls to public_key_verify_signature().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Retain the key verification data · 77d0910d
      David Howells authored
      Retain the key verification data (ie. the struct public_key_signature)
      including the digest and the key identifiers.
      Note that this means that we need to take a separate copy of the digest in
      x509_get_sig_params() rather than lumping it in with the crypto layer data.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Allow authentication data to be stored in an asymmetric key · 3b764563
      David Howells authored
      Allow authentication data to be stored in an asymmetric key in the 4th
      element of the key payload and provide a way for it to be destroyed.
      For the public key subtype, this will be a public_key_signature struct.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  7. 03 Mar, 2016 1 commit
  8. 29 Feb, 2016 3 commits
    • David Howells's avatar
      X.509: Handle midnight alternative notation in GeneralizedTime · 7650cb80
      David Howells authored
      The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
      The time is permitted to show midnight as 00:00 or 24:00 (the latter being
      equivalent of 00:00 of the following day).
      The permitted value is checked in x509_decode_time() but the actual
      handling is left to mktime64().
      Without this patch, certain X.509 certificates will be rejected and could
      lead to an unbootable kernel.
      Note that with this patch we also permit any 24:mm:ss time and extend this
      to UTCTime, which whilst not strictly correct don't permit much leeway in
      fiddling date strings.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
    • David Howells's avatar
      X.509: Support leap seconds · da02559c
      David Howells authored
      The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
      [X.680 46.3] and this apparently supports leap seconds (ie. the seconds
      field is 60).  It's not entirely clear that ASN.1 expects it, but we can
      relax the seconds check slightly for GeneralizedTime.
      This results in us passing a time with sec as 60 to mktime64(), which
      handles it as being a duplicate of the 0th second of the next minute.
      We can't really do otherwise without giving the kernel much greater
      knowledge of where all the leap seconds are.  Unfortunately, this would
      require change the mapping of the kernel's current-time-in-seconds.
      UTCTime, however, only supports a seconds value in the range 00-59, but for
      the sake of simplicity allow this with UTCTime also.
      Without this patch, certain X.509 certificates will be rejected,
      potentially making a kernel unbootable.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
    • David Howells's avatar
      X.509: Fix leap year handling again · ac4cbedf
      David Howells authored
      There are still a couple of minor issues in the X.509 leap year handling:
       (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
           determining whether the year is a leap year or not, I divided the year
           by 100 after doing the modulus-by-100, thereby letting the compiler do
           one instruction for both, and then did a modulus-by-4.
           Unfortunately, I then passed the now-modified year value to mktime64()
           to construct a time value.
           Since this isn't a fast path and since mktime64() does a bunch of
           divisions, just condense down to "% 400".  It's also easier to read.
       (2) The default month length for any February where the year doesn't
           divide by four exactly is obtained from the month_length[] array where
           the value is 29, not 28.
           This is fixed by altering the table.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: stable@vger.kernel.org
  9. 10 Feb, 2016 1 commit
  10. 09 Feb, 2016 1 commit
  11. 06 Feb, 2016 1 commit
  12. 12 Nov, 2015 1 commit
    • David Howells's avatar
      X.509: Fix the time validation [ver #2] · cc25b994
      David Howells authored
      This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.
      Fix the X.509 time validation to use month number-1 when looking up the
      number of days in that month.  Also put the month number validation before
      doing the lookup so as not to risk overrunning the array.
      This can be tested by doing the following:
      cat <<EOF | openssl x509 -outform DER | keyctl padd asymmetric "" @s
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
      If it works, it emit a key ID; if it fails, it should give a bad message
      Reported-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Acked-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
  13. 21 Sep, 2015 1 commit
  14. 12 Aug, 2015 2 commits
    • David Howells's avatar
      PKCS#7: Improve and export the X.509 ASN.1 time object decoder · fd19a3d1
      David Howells authored
      Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
      struct tm to make comparison easier (unfortunately, this makes readable
      display less easy) and export it so that it can be used by the PKCS#7 code
      Further, tighten up its parsing to reject invalid dates (eg. weird
      characters, non-existent hour numbers) and unsupported dates (eg. timezones
      other than 'Z' or dates earlier than 1970).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
    • David Howells's avatar
      X.509: Change recorded SKID & AKID to not include Subject or Issuer · a4c6e57f
      David Howells authored
      The key identifiers fabricated from an X.509 certificate are currently:
       (A) Concatenation of serial number and issuer
       (B) Concatenation of subject and subjectKeyID (SKID)
      When verifying one X.509 certificate with another, the AKID in the target
      can be used to match the authoritative certificate.  The AKID can specify
      the match in one or both of two ways:
       (1) Compare authorityCertSerialNumber and authorityCertIssuer from the AKID
           to identifier (A) above.
       (2) Compare keyIdentifier from the AKID plus the issuer from the target
           certificate to identifier (B) above.
      When verifying a PKCS#7 message, the only available comparison is between
      the IssuerAndSerialNumber field and identifier (A) above.
      However, a subsequent patch adds CMS support.  Whilst CMS still supports a
      match on IssuerAndSerialNumber as for PKCS#7, it also supports an
      alternative - which is the SubjectKeyIdentifier field.  This is used to
      match to an X.509 certificate on the SKID alone.  No subject information is
      available to be used.
      To this end change the fabrication of (B) above to be from the X.509 SKID
      alone.  The AKID in keyIdentifier form then only matches on that and does
      not include the issuer.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-By: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  15. 07 Aug, 2015 1 commit
  16. 06 Oct, 2014 1 commit
  17. 03 Oct, 2014 1 commit
  18. 16 Sep, 2014 1 commit
    • David Howells's avatar
      KEYS: Overhaul key identification when searching for asymmetric keys · 46963b77
      David Howells authored
      Make use of the new match string preparsing to overhaul key identification
      when searching for asymmetric keys.  The following changes are made:
       (1) Use the previously created asymmetric_key_id struct to hold the following
           key IDs derived from the X.509 certificate or PKCS#7 message:
      	id: serial number + issuer
      	skid: subjKeyId + subject
      	authority: authKeyId + issuer
       (2) Replace the hex fingerprint attached to key->type_data[1] with an
           asymmetric_key_ids struct containing the id and the skid (if present).
       (3) Make the asymmetric_type match data preparse select one of two searches:
           (a) An iterative search for the key ID given if prefixed with "id:".  The
           	 prefix is expected to be followed by a hex string giving the ID to
           	 search for.  The criterion key ID is checked against all key IDs
           	 recorded on the key.
           (b) A direct search if the key ID is not prefixed with "id:".  This will
           	 look for an exact match on the key description.
       (4) Make x509_request_asymmetric_key() take a key ID.  This is then converted
           into "id:<hex>" and passed into keyring_search() where match preparsing
           will turn it back into a binary ID.
       (5) X.509 certificate verification then takes the authority key ID and looks
           up a key that matches it to find the public key for the certificate
       (6) PKCS#7 certificate verification then takes the id key ID and looks up a
           key that matches it to find the public key for the signed information
           block signature.
      Additional changes:
       (1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
           cert to be rejected with -EBADMSG.
       (2) The 'fingerprint' ID is gone.  This was primarily intended to convey PGP
           public key fingerprints.  If PGP is supported in future, this should
           generate a key ID that carries the fingerprint.
       (3) Th ca_keyid= kernel command line option is now converted to a key ID and
           used to match the authority key ID.  Possibly this should only match the
           actual authKeyId part and not the issuer as well.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
  19. 02 Jul, 2014 1 commit
  20. 01 Jul, 2014 1 commit
  21. 25 Oct, 2013 1 commit
  22. 25 Sep, 2013 2 commits
  23. 22 Apr, 2013 1 commit
    • Chun-Yi Lee's avatar
      X.509: Support parse long form of length octets in Authority Key Identifier · 04b00bdb
      Chun-Yi Lee authored
      Per X.509 spec in section, the structure of Authority Key
      Identifier Extension is:
         AuthorityKeyIdentifier ::= SEQUENCE {
            keyIdentifier             [0] KeyIdentifier           OPTIONAL,
            authorityCertIssuer       [1] GeneralNames            OPTIONAL,
            authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
         KeyIdentifier ::= OCTET STRING
      When a certificate also provides
      authorityCertIssuer and authorityCertSerialNumber then the length of
      AuthorityKeyIdentifier SEQUENCE is likely to long form format.
         The example certificate demos/tunala/A-server.pem in openssl source:
      X509v3 Authority Key Identifier:
          DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
      Current parsing rule of OID_authorityKeyIdentifier only take care the
      short form format, it causes load certificate to modsign_keyring fail:
      [   12.061147] X.509: Extension: 47
      [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
      So, this patch add the parsing rule for support long form format against
      Authority Key Identifier.
      Changed the size check in "Short Form length" case, we allow v[3] smaller
      then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
      are also possible attach in AuthorityKeyIdentifier sequence.
       - Removed comma from author's name.
       - Moved 'Short Form length' comment inside the if-body.
       - Changed the type of sub to size_t.
       - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
       - Moved the key_len's value assignment before alter v.
       - Fixed the typo of octets.
       - Add 2 to v before entering the loop for calculate the length.
       - Removed the comment of check vlen.
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarChun-Yi Lee <jlee@suse.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  24. 10 Oct, 2012 2 commits
  25. 08 Oct, 2012 1 commit
    • David Howells's avatar
      X.509: Add a crypto key parser for binary (DER) X.509 certificates · c26fd69f
      David Howells authored
      Add a crypto key parser for binary (DER) encoded X.509 certificates.  The
      certificate is parsed and, if possible, the signature is verified.
      An X.509 key can be added like this:
      	# keyctl padd crypto bar @s </tmp/x509.cert
      and displayed like this:
      	# cat /proc/keys
      	00f09a47 I--Q---     1 perm 39390000     0     0 asymmetri bar: X509.RSA e9fd6d08 []
      Note that this only works with binary certificates.  PEM encoded certificates
      are ignored by the parser.
      Note also that the X.509 key ID is not congruent with the PGP key ID, but for
      the moment, they will match.
      If a NULL or "" name is given to add_key(), then the parser will generate a key
      description from the CertificateSerialNumber and Name fields of the
      	00aefc4e I--Q---     1 perm 39390000     0     0 asymmetri bfbc0cd76d050ea4:/C=GB/L=Cambridge/O=Red Hat/CN=kernel key: X509.RSA 0c688c7b []
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>