Skip to content
Snippets Groups Projects
  1. Dec 27, 2015
  2. Oct 12, 2015
  3. 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
  4. May 24, 2015
  5. 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
  6. 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
  7. 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
  8. Feb 04, 2015
  9. 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
  10. 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
  11. 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
  12. 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
  13. Nov 03, 2014
  14. Oct 20, 2014
  15. Oct 01, 2014
  16. Sep 25, 2014
    • Heikki Linnakangas's avatar
      Refactor space allocation for base64 encoding/decoding in pgcrypto. · 1dcfb8da
      Heikki Linnakangas authored
      Instead of trying to accurately calculate the space needed, use a StringInfo
      that's enlarged as needed. This is just moving things around currently - the
      old code was not wrong - but this is in preparation for a patch that adds
      support for extra armor headers, and would make the space calculation more
      complicated.
      
      Marko Tiikkaja
      1dcfb8da
  17. Aug 25, 2014
  18. Jul 15, 2014
    • Magnus Hagander's avatar
      Remove dependency on wsock32.lib in favor of ws2_32 · a16bac36
      Magnus Hagander authored
      ws2_32 is the new version of the library that should be used, as
      it contains the require functionality from wsock32 as well as some
      more (which is why some binaries were already using ws2_32).
      
      Michael Paquier, reviewed by MauMau
      a16bac36
  19. Jul 14, 2014
  20. May 06, 2014
    • Bruce Momjian's avatar
      pgindent run for 9.4 · 0a783200
      Bruce Momjian authored
      This includes removing tabs after periods in C comments, which was
      applied to back branches, so this change should not effect backpatching.
      0a783200
  21. Apr 18, 2014
    • Peter Eisentraut's avatar
      Create function prototype as part of PG_FUNCTION_INFO_V1 macro · e7128e8d
      Peter Eisentraut authored
      Because of gcc -Wmissing-prototypes, all functions in dynamically
      loadable modules must have a separate prototype declaration.  This is
      meant to detect global functions that are not declared in header files,
      but in cases where the function is called via dfmgr, this is redundant.
      Besides filling up space with boilerplate, this is a frequent source of
      compiler warnings in extension modules.
      
      We can fix that by creating the function prototype as part of the
      PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway.  That
      makes the code of modules cleaner, because there is one less place where
      the entry points have to be listed, and creates an additional check that
      functions have the right prototype.
      
      Remove now redundant prototypes from contrib and other modules.
      e7128e8d
  22. Apr 17, 2014
  23. Mar 17, 2014
  24. Jan 17, 2014
    • Tom Lane's avatar
      Add gen_random_uuid() to contrib/pgcrypto. · e6170126
      Tom Lane authored
      This function provides a way of generating version 4 (pseudorandom) UUIDs
      based on pgcrypto's PRNG.  The main reason for doing this is that the
      OSSP UUID library depended on by contrib/uuid-ossp is becoming more and
      more of a porting headache, so we need an alternative for people who can't
      install that.  A nice side benefit though is that this implementation is
      noticeably faster than uuid-ossp's uuid_generate_v4() function.
      
      Oskari Saarenmaa, reviewed by Emre Hasegeli
      e6170126
  25. Jan 09, 2014
    • Peter Eisentraut's avatar
      pgcrypto: Make header files stand alone · 10a3b165
      Peter Eisentraut authored
      pgp.h used to require including mbuf.h and px.h first.  Include those in
      pgp.h, so that it can be used without prerequisites.  Remove mbuf.h
      inclusions in .c files where mbuf.h features are not used
      directly.  (px.h was always used.)
      10a3b165
  26. Nov 10, 2013
  27. May 29, 2013
  28. May 10, 2013
  29. Jun 10, 2012
  30. May 30, 2012
    • Tom Lane's avatar
      Fix incorrect password transformation in contrib/pgcrypto's DES crypt(). · 932ded2e
      Tom Lane authored
      Overly tight coding caused the password transformation loop to stop
      examining input once it had processed a byte equal to 0x80.  Thus, if the
      given password string contained such a byte (which is possible though not
      highly likely in UTF8, and perhaps also in other non-ASCII encodings), all
      subsequent characters would not contribute to the hash, making the password
      much weaker than it appears on the surface.
      
      This would only affect cases where applications used DES crypt() to encode
      passwords before storing them in the database.  If a weak password has been
      created in this fashion, the hash will stop matching after this update has
      been applied, so it will be easy to tell if any passwords were unexpectedly
      weak.  Changing to a different password would be a good idea in such a case.
      (Since DES has been considered inadequately secure for some time, changing
      to a different encryption algorithm can also be recommended.)
      
      This code, and the bug, are shared with at least PHP, FreeBSD, and OpenBSD.
      Since the other projects have already published their fixes, there is no
      point in trying to keep this commit private.
      
      This bug has been assigned CVE-2012-2143, and credit for its discovery goes
      to Rubin Xu and Joseph Bonneau.
      932ded2e
  31. May 08, 2012
  32. May 02, 2012
  33. Apr 24, 2012
  34. Jan 28, 2012
  35. Jan 15, 2012
  36. Dec 27, 2011
  37. Nov 17, 2011
Loading