Skip to content
Snippets Groups Projects
  1. Mar 13, 2017
    • Noah Misch's avatar
      Use wrappers of PG_DETOAST_DATUM_PACKED() more. · 3a0d4731
      Noah Misch authored
      This makes almost all core code follow the policy introduced in the
      previous commit.  Specific decisions:
      
      - Text search support functions with char* and length arguments, such as
        prsstart and lexize, may receive unaligned strings.  I doubt
        maintainers of non-core text search code will notice.
      
      - Use plain VARDATA() on values detoasted or synthesized earlier in the
        same function.  Use VARDATA_ANY() on varlenas sourced outside the
        function, even if they happen to always have four-byte headers.  As an
        exception, retain the universal practice of using VARDATA() on return
        values of SendFunctionCall().
      
      - Retain PG_GETARG_BYTEA_P() in pageinspect.  (Page images are too large
        for a one-byte header, so this misses no optimization.)  Sites that do
        not call get_page_from_raw() typically need the four-byte alignment.
      
      - For now, do not change btree_gist.  Its use of four-byte headers in
        memory is partly entangled with storage of 4-byte headers inside
        GBT_VARKEY, on disk.
      
      - For now, do not change gtrgm_consistent() or gtrgm_distance().  They
        incorporate the varlena header into a cache, and there are multiple
        credible implementation strategies to consider.
      3a0d4731
  2. Mar 07, 2017
  3. Feb 25, 2017
    • Tom Lane's avatar
      Remove useless duplicate inclusions of system header files. · 9e3755ec
      Tom Lane authored
      c.h #includes a number of core libc header files, such as <stdio.h>.
      There's no point in re-including these after having read postgres.h,
      postgres_fe.h, or c.h; so remove code that did so.
      
      While at it, also fix some places that were ignoring our standard pattern
      of "include postgres[_fe].h, then system header files, then other Postgres
      header files".  While there's not any great magic in doing it that way
      rather than system headers last, it's silly to have just a few files
      deviating from the general pattern.  (But I didn't attempt to enforce this
      globally, only in files I was touching anyway.)
      
      I'd be the first to say that this is mostly compulsive neatnik-ism,
      but over time it might save enough compile cycles to be useful.
      9e3755ec
  4. Feb 06, 2017
  5. Dec 12, 2016
  6. Dec 05, 2016
    • Heikki Linnakangas's avatar
      Replace PostmasterRandom() with a stronger source, second attempt. · fe0a0b59
      Heikki Linnakangas authored
      This adds a new routine, pg_strong_random() for generating random bytes,
      for use in both frontend and backend. At the moment, it's only used in
      the backend, but the upcoming SCRAM authentication patches need strong
      random numbers in libpq as well.
      
      pg_strong_random() is based on, and replaces, the existing implementation
      in pgcrypto. It can acquire strong random numbers from a number of sources,
      depending on what's available:
      
      - OpenSSL RAND_bytes(), if built with OpenSSL
      - On Windows, the native cryptographic functions are used
      - /dev/urandom
      
      Unlike the current pgcrypto function, the source is chosen by configure.
      That makes it easier to test different implementations, and ensures that
      we don't accidentally fall back to a less secure implementation, if the
      primary source fails. All of those methods are quite reliable, it would be
      pretty surprising for them to fail, so we'd rather find out by failing
      hard.
      
      If no strong random source is available, we fall back to using erand48(),
      seeded from current timestamp, like PostmasterRandom() was. That isn't
      cryptographically secure, but allows us to still work on platforms that
      don't have any of the above stronger sources. Because it's not very secure,
      the built-in implementation is only used if explicitly requested with
      --disable-strong-random.
      
      This replaces the more complicated Fortuna algorithm we used to have in
      pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
      so it doesn't seem worth the maintenance effort to keep that. pgcrypto
      functions that require strong random numbers will be disabled with
      --disable-strong-random.
      
      Original patch by Magnus Hagander, tons of further work by Michael Paquier
      and me.
      
      Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
      Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
      fe0a0b59
  7. Nov 30, 2016
    • Heikki Linnakangas's avatar
      Remove dead stuff from pgcrypto. · b2cc748b
      Heikki Linnakangas authored
      pgp-pubkey-DISABLED test has been unused since 2006, when support for
      built-in bignum math was added (commit 1abf76e8). pgp-encrypt-DISABLED has
      been unused forever, AFAICS.
      
      Also remove a couple of unused error codes.
      b2cc748b
  8. Oct 18, 2016
  9. Oct 17, 2016
    • Heikki Linnakangas's avatar
      Use OpenSSL EVP API for symmetric encryption in pgcrypto. · 5ff4a67f
      Heikki Linnakangas authored
      The old "low-level" API is deprecated, and doesn't support hardware
      acceleration. And this makes the code simpler, too.
      
      Discussion: <561274F1.1030000@iki.fi>
      5ff4a67f
    • Heikki Linnakangas's avatar
      Replace PostmasterRandom() with a stronger way of generating randomness. · 9e083fd4
      Heikki Linnakangas authored
      This adds a new routine, pg_strong_random() for generating random bytes,
      for use in both frontend and backend. At the moment, it's only used in
      the backend, but the upcoming SCRAM authentication patches need strong
      random numbers in libpq as well.
      
      pg_strong_random() is based on, and replaces, the existing implementation
      in pgcrypto. It can acquire strong random numbers from a number of sources,
      depending on what's available:
      - OpenSSL RAND_bytes(), if built with OpenSSL
      - On Windows, the native cryptographic functions are used
      - /dev/urandom
      - /dev/random
      
      Original patch by Magnus Hagander, with further work by Michael Paquier
      and me.
      
      Discussion: <CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com>
      9e083fd4
  10. Sep 30, 2016
  11. Sep 15, 2016
    • Heikki Linnakangas's avatar
      Fix building with LibreSSL. · 5c6df67e
      Heikki Linnakangas authored
      LibreSSL defines OPENSSL_VERSION_NUMBER to claim that it is version 2.0.0,
      but it doesn't have the functions added in OpenSSL 1.1.0. Add autoconf
      checks for the individual functions we need, and stop relying on
      OPENSSL_VERSION_NUMBER.
      
      Backport to 9.5 and 9.6, like the patch that broke this. In the
      back-branches, there are still a few OPENSSL_VERSION_NUMBER checks left,
      to check for OpenSSL 0.9.8 or 0.9.7. I left them as they were - LibreSSL
      has all those functions, so they work as intended.
      
      Per buildfarm member curculio.
      
      Discussion: <2442.1473957669@sss.pgh.pa.us>
      5c6df67e
    • Heikki Linnakangas's avatar
      Support OpenSSL 1.1.0. · 593d4e47
      Heikki Linnakangas authored
      Changes needed to build at all:
      
      - Check for SSL_new in configure, now that SSL_library_init is a macro.
      - Do not access struct members directly. This includes some new code in
        pgcrypto, to use the resource owner mechanism to ensure that we don't
        leak OpenSSL handles, now that we can't embed them in other structs
        anymore.
      - RAND_SSLeay() -> RAND_OpenSSL()
      
      Changes that were needed to silence deprecation warnings, but were not
      strictly necessary:
      
      - RAND_pseudo_bytes() -> RAND_bytes().
      - SSL_library_init() and OpenSSL_config() -> OPENSSL_init_ssl()
      - ASN1_STRING_data() -> ASN1_STRING_get0_data()
      - DH_generate_parameters() -> DH_generate_parameters()
      - Locking callbacks are not needed with OpenSSL 1.1.0 anymore. (Good
        riddance!)
      
      Also change references to SSLEAY_VERSION_NUMBER with OPENSSL_VERSION_NUMBER,
      for the sake of consistency. OPENSSL_VERSION_NUMBER has existed since time
      immemorial.
      
      Fix SSL test suite to work with OpenSSL 1.1.0. CA certificates must have
      the "CA:true" basic constraint extension now, or OpenSSL will refuse them.
      Regenerate the test certificates with that. The "openssl" binary, used to
      generate the certificates, is also now more picky, and throws an error
      if an X509 extension is specified in "req_extensions", but that section
      is empty.
      
      Backpatch to all supported branches, per popular demand. In back-branches,
      we still support OpenSSL 0.9.7 and above. OpenSSL 0.9.6 should still work
      too, but I didn't test it. In master, we only support 0.9.8 and above.
      
      Patch by Andreas Karlsson, with additional changes by me.
      
      Discussion: <20160627151604.GD1051@msg.df7cb.de>
      593d4e47
  12. Aug 29, 2016
    • Heikki Linnakangas's avatar
      Remove support for OpenSSL versions older than 0.9.8. · 9b7cd59a
      Heikki Linnakangas authored
      OpenSSL officially only supports 1.0.1 and newer. Some OS distributions
      still provide patches for 0.9.8, but anything older than that is not
      interesting anymore. Let's simplify things by removing compatibility code.
      
      Andreas Karlsson, with small changes by me.
      9b7cd59a
  13. Aug 10, 2016
  14. Jun 14, 2016
    • Tom Lane's avatar
      Minor fixes in contrib installation scripts. · 5484c0a9
      Tom Lane authored
      Extension scripts should never use CREATE OR REPLACE for initial object
      creation.  If there is a collision with a pre-existing (probably
      user-created) object, we want extension installation to fail, not silently
      overwrite the user's object.  Bloom and sslinfo both violated this precept.
      
      Also fix a number of scripts that had no standard header (the file name
      comment and the \echo...\quit guard).  Probably the \echo...\quit hack
      is less important now than it was in 9.1 days, but that doesn't mean
      that individual extensions get to choose whether to use it or not.
      
      And fix a couple of evident copy-and-pasteos in file name comments.
      
      No need for back-patch: the REPLACE bugs are both new in 9.6, and the
      rest of this is pretty much cosmetic.
      
      Andreas Karlsson and Tom Lane
      5484c0a9
  15. Jun 10, 2016
  16. Jun 09, 2016
  17. Mar 15, 2016
  18. Mar 09, 2016
    • Alvaro Herrera's avatar
      pgcrypto: support changing S2K iteration count · 188f359d
      Alvaro Herrera authored
      pgcrypto already supports key-stretching during symmetric encryption,
      including the salted-and-iterated method; but the number of iterations
      was not configurable.  This commit implements a new s2k-count parameter
      to pgp_sym_encrypt() which permits selecting a larger number of
      iterations.
      
      Author: Jeff Janes
      188f359d
  19. Feb 01, 2016
  20. Dec 27, 2015
  21. Oct 12, 2015
  22. Oct 05, 2015
    • Noah Misch's avatar
      pgcrypto: Detect and report too-short crypt() salts. · 1d812c8b
      Noah Misch authored
      Certain short salts crashed the backend or disclosed a few bytes of
      backend memory.  For existing salt-induced error conditions, emit a
      message saying as much.  Back-patch to 9.0 (all supported versions).
      
      Josh Kupershmidt
      
      Security: CVE-2015-5288
      1d812c8b
  23. May 24, 2015
  24. May 18, 2015
    • Noah Misch's avatar
      pgcrypto: Report errant decryption as "Wrong key or corrupt data". · 85270ac7
      Noah Misch authored
      This has been the predominant outcome.  When the output of decrypting
      with a wrong key coincidentally resembled an OpenPGP packet header,
      pgcrypto could instead report "Corrupt data", "Not text data" or
      "Unsupported compression algorithm".  The distinct "Corrupt data"
      message added no value.  The latter two error messages misled when the
      decrypted payload also exhibited fundamental integrity problems.  Worse,
      error message variance in other systems has enabled cryptologic attacks;
      see RFC 4880 section "14. Security Considerations".  Whether these
      pgcrypto behaviors are likewise exploitable is unknown.
      
      In passing, document that pgcrypto does not resist side-channel attacks.
      Back-patch to 9.0 (all supported versions).
      
      Security: CVE-2015-3167
      85270ac7
  25. Mar 26, 2015
    • Tom Lane's avatar
      Tweak __attribute__-wrapping macros for better pgindent results. · 785941cd
      Tom Lane authored
      This improves on commit bbfd7eda by
      making two simple changes:
      
      * pg_attribute_noreturn now takes parentheses, ie pg_attribute_noreturn().
      Likewise pg_attribute_unused(), pg_attribute_packed().  This reduces
      pgindent's tendency to misformat declarations involving them.
      
      * attributes are now always attached to function declarations, not
      definitions.  Previously some places were taking creative shortcuts,
      which were not merely candidates for bad misformatting by pgindent
      but often were outright wrong anyway.  (It does little good to put a
      noreturn annotation where callers can't see it.)  In any case, if
      we would like to believe that these macros can be used with non-gcc
      compilers, we should avoid gratuitous variance in usage patterns.
      
      I also went through and manually improved the formatting of a lot of
      declarations, and got rid of excessively repetitive (and now obsolete
      anyway) comments informing the reader what pg_attribute_printf is for.
      785941cd
  26. Mar 11, 2015
    • Andres Freund's avatar
      Add macros wrapping all usage of gcc's __attribute__. · bbfd7eda
      Andres Freund authored
      Until now __attribute__() was defined to be empty for all compilers but
      gcc. That's problematic because it prevents using it in other compilers;
      which is necessary e.g. for atomics portability.  It's also just
      generally dubious to do so in a header as widely included as c.h.
      
      Instead add pg_attribute_format_arg, pg_attribute_printf,
      pg_attribute_noreturn macros which are implemented in the compilers that
      understand them. Also add pg_attribute_noreturn and pg_attribute_packed,
      but don't provide fallbacks, since they can affect functionality.
      
      This means that external code that, possibly unwittingly, relied on
      __attribute__ defined to be empty on !gcc compilers may now run into
      warnings or errors on those compilers. But there shouldn't be many
      occurances of that and it's hard to work around...
      
      Discussion: 54B58BA3.8040302@ohmu.fi
      Author: Oskari Saarenmaa, with some minor changes by me.
      bbfd7eda
  27. Feb 04, 2015
  28. Feb 02, 2015
    • Noah Misch's avatar
      Prevent Valgrind Memcheck errors around px_acquire_system_randomness(). · 59b91982
      Noah Misch authored
      This function uses uninitialized stack and heap buffers as supplementary
      entropy sources.  Mark them so Memcheck will not complain.  Back-patch
      to 9.4, where Valgrind Memcheck cooperation first appeared.
      
      Marko Tiikkaja
      59b91982
    • Noah Misch's avatar
      Cherry-pick security-relevant fixes from upstream imath library. · 8b59672d
      Noah Misch authored
      This covers alterations to buffer sizing and zeroing made between imath
      1.3 and imath 1.20.  Valgrind Memcheck identified the buffer overruns
      and reliance on uninitialized data; their exploit potential is unknown.
      Builds specifying --with-openssl are unaffected, because they use the
      OpenSSL BIGNUM facility instead of imath.  Back-patch to 9.0 (all
      supported versions).
      
      Security: CVE-2015-0243
      8b59672d
    • Noah Misch's avatar
      Fix buffer overrun after incomplete read in pullf_read_max(). · 1dc75515
      Noah Misch authored
      Most callers pass a stack buffer.  The ensuing stack smash can crash the
      server, and we have not ruled out the viability of attacks that lead to
      privilege escalation.  Back-patch to 9.0 (all supported versions).
      
      Marko Tiikkaja
      
      Security: CVE-2015-0243
      1dc75515
  29. Jan 30, 2015
    • Tom Lane's avatar
      Fix Coverity warning about contrib/pgcrypto's mdc_finish(). · a59ee881
      Tom Lane authored
      Coverity points out that mdc_finish returns a pointer to a local buffer
      (which of course is gone as soon as the function returns), leaving open
      a risk of misbehaviors possibly as bad as a stack overwrite.
      
      In reality, the only possible call site is in process_data_packets()
      which does not examine the returned pointer at all.  So there's no
      live bug, but nonetheless the code is confusing and risky.  Refactor
      to avoid the issue by letting process_data_packets() call mdc_finish()
      directly instead of going through the pullf_read() API.
      
      Although this is only cosmetic, it seems good to back-patch so that
      the logic in pgp-decrypt.c stays in sync across all branches.
      
      Marko Kreen
      a59ee881
  30. Jan 24, 2015
    • Tom Lane's avatar
      Replace a bunch more uses of strncpy() with safer coding. · 586dd5d6
      Tom Lane authored
      strncpy() has a well-deserved reputation for being unsafe, so make an
      effort to get rid of nearly all occurrences in HEAD.
      
      A large fraction of the remaining uses were passing length less than or
      equal to the known strlen() of the source, in which case no null-padding
      can occur and the behavior is equivalent to memcpy(), though doubtless
      slower and certainly harder to reason about.  So just use memcpy() in
      these cases.
      
      In other cases, use either StrNCpy() or strlcpy() as appropriate (depending
      on whether padding to the full length of the destination buffer seems
      useful).
      
      I left a few strncpy() calls alone in the src/timezone/ code, to keep it
      in sync with upstream (the IANA tzcode distribution).  There are also a
      few such calls in ecpg that could possibly do with more analysis.
      
      AFAICT, none of these changes are more than cosmetic, except for the four
      occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength
      source leads to a non-null-terminated destination buffer and ensuing
      misbehavior.  These don't seem like security issues, first because no stack
      clobber is possible and second because if your values of sslcert etc are
      coming from untrusted sources then you've got problems way worse than this.
      Still, it's undesirable to have unpredictable behavior for overlength
      inputs, so back-patch those four changes to all active branches.
      586dd5d6
  31. Nov 11, 2014
    • Tom Lane's avatar
      Loop when necessary in contrib/pgcrypto's pktreader_pull(). · f2ad2bdd
      Tom Lane authored
      This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key
      or corrupt data" on messages whose length is 6 less than a power of 2.
      
      Per bug #11905 from Connor Penhale.  Fix by Marko Tiikkaja, regression
      test case from Jeff Janes.
      f2ad2bdd
  32. Nov 03, 2014
  33. Oct 20, 2014
  34. Oct 01, 2014
Loading