summaryrefslogtreecommitdiffstats
path: root/src/plugins/kdb
Commit message (Collapse)AuthorAgeFilesLines
* Correct spellingBen Kaduk2014-12-151-7/+7
| | | | | Remove extra 'i' from "create_standalone_prinicipal". While here, pick a slightly shorter name for the variable.
* Add helper for freeing arrays of berval pointersBen Kaduk2014-12-151-11/+21
| | | | | This eliminates a potential leak of the bv_val members from krb5_encode_krbsecretkey().
* Remove some dead codeBen Kaduk2014-12-151-19/+1
| | | | | | | | The secretkey variable is initialized to NULL and compared against NULL, but never actually set to anything after initialization. Remove the variable and all code that would have executed if it was non-NULL.
* Support keyless principals in LDAP [CVE-2014-5354]Ben Kaduk2014-12-151-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Operations like "kadmin -q 'addprinc -nokey foo'" or "kadmin -q 'purgekeys -all foo'" result in principal entries with no keys present, so krb5_encode_krbsecretkey() would just return NULL, which then got unconditionally dereferenced in krb5_add_ber_mem_ldap_mod(). Apply some fixes to krb5_encode_krbsecretkey() to handle zero-key principals better, correct the test for an allocation failure, and slightly restructure the cleanup handler to be shorter and more appropriate for the usage. Once it no longer short-circuits when n_key_data is zero, it will produce an array of length two with both entries NULL, which is treated as an empty list by the LDAP library, the correct behavior for a keyless principal. However, attributes with empty values are only handled by the LDAP library for Modify operations, not Add operations (which only get a sequence of Attribute, with no operation field). Therefore, only add an empty krbprincipalkey to the modlist when we will be performing a Modify, and not when we will be performing an Add, which is conditional on the (misspelled) create_standalone_prinicipal boolean. CVE-2014-5354: In MIT krb5, when kadmind is configured to use LDAP for the KDC database, an authenticated remote attacker can cause a NULL dereference by inserting into the database a principal entry which contains no long-term keys. In order for the LDAP KDC backend to translate a principal entry from the database abstraction layer into the form expected by the LDAP schema, the principal's keys are encoded into a NULL-terminated array of length-value entries to be stored in the LDAP database. However, the subroutine which produced this array did not correctly handle the case where no keys were present, returning NULL instead of an empty array, and the array was unconditionally dereferenced while adding to the list of LDAP operations to perform. Versions of MIT krb5 prior to 1.12 did not expose a way for principal entries to have no long-term key material, and therefore are not vulnerable. CVSSv2 Vector: AV:N/AC:M/Au:S/C:N/I:N/A:P/E:H/RL:OF/RC:C ticket: 8041 (new) tags: pullup target_version: 1.13.1 subject: kadmind with ldap backend crashes when putting keyless entries
* Fix LDAP misused policy name crash [CVE-2014-5353]Greg Hudson2014-12-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In krb5_ldap_get_password_policy_from_dn, if LDAP_SEARCH returns successfully with no results, return KRB5_KDB_NOENTRY instead of returning success with a zeroed-out policy object. This fixes a null dereference when an admin attempts to use an LDAP ticket policy name as a password policy name. CVE-2014-5353: In MIT krb5, when kadmind is configured to use LDAP for the KDC database, an authenticated remote attacker can cause a NULL dereference by attempting to use a named ticket policy object as a password policy for a principal. The attacker needs to be authenticated as a user who has the elevated privilege for setting password policy by adding or modifying principals. Queries to LDAP scoped to the krbPwdPolicy object class will correctly not return entries of other classes, such as ticket policy objects, but may return success with no returned elements if an object with the requested DN exists in a different object class. In this case, the routine to retrieve a password policy returned success with a password policy object that consisted entirely of zeroed memory. In particular, accesses to the policy name will dereference a NULL pointer. KDC operation does not access the policy name field, but most kadmin operations involving the principal with incorrect password policy will trigger the crash. Thanks to Patrik Kis for reporting this problem. CVSSv2 Vector: AV:N/AC:M/Au:S/C:N/I:N/A:C/E:H/RL:OF/RC:C [kaduk@mit.edu: CVE description and CVSS score] ticket: 8051 (new) target_version: 1.13.1 tags: pullup
* Use new error message wrapping APIsNicolas Williams2014-12-077-42/+23
| | | | | | | | | | | | | | Define internal names k5_prendmsg and k5_wrapmsg and use them where we amend error messages. This slightly changes the error message when we fail to construct FAST AP-REQ armor, decrypt a FAST reply, or store credentials in a gic_opts output ccache. Adjust the test suite for the latter of those changes. [ghudson@mit.edu: define and use internal names for brevity; pull in test fix from later commit; expand commit message; fix redundant separators in LDAP messages] ticket: 8046
* Fix LDAP key data segmentation [CVE-2014-4345]Tomas Kuthan2014-08-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For principal entries having keys with multiple kvnos (due to use of -keepold), the LDAP KDB module makes an attempt to store all the keys having the same kvno into a single krbPrincipalKey attribute value. There is a fencepost error in the loop, causing currkvno to be set to the just-processed value instead of the next kvno. As a result, the second and all following groups of multiple keys by kvno are each stored in two krbPrincipalKey attribute values. Fix the loop to use the correct kvno value. CVE-2014-4345: In MIT krb5, when kadmind is configured to use LDAP for the KDC database, an authenticated remote attacker can cause it to perform an out-of-bounds write (buffer overrun) by performing multiple cpw -keepold operations. An off-by-one error while copying key information to the new database entry results in keys sharing a common kvno being written to different array buckets, in an array whose size is determined by the number of kvnos present. After sufficient iterations, the extra writes extend past the end of the (NULL-terminated) array. The NULL terminator is always written after the end of the loop, so no out-of-bounds data is read, it is only written. Historically, it has been possible to convert an out-of-bounds write into remote code execution in some cases, though the necessary exploits must be tailored to the individual application and are usually quite complicated. Depending on the allocated length of the array, an out-of-bounds write may also cause a segmentation fault and/or application crash. CVSSv2 Vector: AV:N/AC:M/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C [ghudson@mit.edu: clarified commit message] [kaduk@mit.edu: CVE summary, CVSSv2 vector] ticket: 7980 (new) target_version: 1.12.2 tags: pullup
* Disallow unlocked iteration of hash databasesTom Yu2014-08-071-0/+3
| | | | | | | | | | It's not clear whether unlocked iteration over a hash DB2 database will omit unaffected entries if database additions or deletions occur concurrently with the iteration. Avoid this situation by disabling unlocked iteration in the unlikely event that someone is still using a hash database for their KDB. ticket: 7977
* Support unlocked iteration in DB2Tom Yu2014-08-022-23/+174
| | | | | | | | | | Add support to the DB2 KDB back end to optionally release the lock when calling the iterator callback. This prevents the blocking of other processes when dumps of large databases are taking place. Also add support for reversed iteration. ticket: 7977
* Support write locks in DB2 iterationTom Yu2014-08-021-1/+7
| | | | | | | Add support to krb5_db_iterate() for requesting write locks in the DB2 back end. ticket: 7977
* Add flag word to KDB iteration APIsTom Yu2014-08-026-10/+10
| | | | | ticket: 7977 (new) subject: Enable unlocked KDB iteration
* Add kiprop/<master-hostname> during KDB creationNeng Xue2014-08-011-0/+7
| | | | | | | | | | | To reduce the number of steps in the deployment of iprop, create the kiprop/hostname principal for the master KDC during KDB creation. Adjust tests to match the new behavior. [ghudson@mit.edu: clarified commit message; avoided applying kadmin flags/lifetime to kiprop principal] ticket: 7979 (new)
* Simplify kdb5_ldap_util special princ creationGreg Hudson2014-08-011-161/+104
| | | | | In kdb5_ldap_realm.c, factor out special principal creation into three helper functions to reduce the amount of verbiage in kdb5_ldap_create.
* Modify k5buf interfaces for easier useGreg Hudson2014-07-302-3/+3
| | | | | | | | Make struct k5buf less opaque and get rid of k5buf-int.h. Make it easy to initialize a k5buf in an error state so that it can be freed in a cleanup handler. Add a function k5_buf_status which returns 0 or ENOMEM. Remove k5_buf_data and k5_buf_len. Rename k5_free_buf to k5_buf_free. Adjust all callers to match.
* Add SASL support to LDAP KDB moduleGreg Hudson2014-07-193-10/+149
| | | | | | | | | | | | | Add variables for the SASL mechanism, authcid, authzid, and realm. If a SASL mechanism is set, perform an interactive bind with that mechanism. If <sasl/sasl.h> is found at build time, provide the authcid, authzid, and realm in the interaction function, and provide a SASL secret read from the service password file (under the authcid) if we found one. Based on a patch from Zoran Pericic <zpericic@netst.org>. ticket: 7944 (new)
* Modernize some LDAP sourcesGreg Hudson2014-07-1915-1611/+1003
| | | | | | | | | | | | | | | | | | | | | | | | | | | Bring ldap_misc.c up to date with current practices and make limited changes to other files. Of note: * krb5_decode_krbsecretkey was freeing its bvalues argument; make that the caller's responsibility. * Make is_principal_in_realm and has_modify_increment return krb5_boolean, reversing the sense of their results. * Remove broken code path in decode_tl_data when an integer value has a length other than 2 (which should never happen). * Simplify krb5_ldap_readpassword and make it take filename/name parameters instead of an LDAP context. * Make krb5_ldap_bind (renamed to authenticate) responsible for setting a useful error message, so that its caller doesn't assume knowledge of the bind parameters. * Make krb5_ldap_initialize (renamed to initialize_server) responsible for updating the handle list, and remove the otherwise unused krb5_update_ldap_handle. * Remove remaining skeletal certificate support, including the unused has_sasl_external_mech function. * Remove unused krb5_get_containerdn and KDB_TL_CONTAINERDN. * Remove kdb_xdr.h; all of its prototypes were for functions that don't exist in the module or were duplicated in other headers. * Remove krb5_ldap_get_strings and use ldap_get_values directly at its call sites; there was no need to copy the result.
* Fix error check in krb5_ldap_parse_principal_nameLukas Slebodnik2014-07-121-1/+1
| | | | | | Test the correct variable for NULL to detect a strdup failure. [ghudson@mit.edu: clarified commit message]
* Remove unused variablesLukas Slebodnik2014-07-123-13/+4
| | | | [ghudson@mit.edu: squashed with similar commits]
* Fix several memory leaks in LDAP KDB modulesGreg Hudson2014-07-127-38/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory leaks discovered by running valgrind over kdbtest, and some related leaks. Many of them result from not calling ldap_msgfree after an unsuccessful search (as the OpenLDAP documentation requires) or after an exception following a search, so many of the fixes move or add ldap_msgfree calls to cleanup labels. ldap_osa_free_princ_ent was not used, and could not be used because it frees the container while krb5_lookup_tl_kadm_data uses a caller-allocated container. Change it to leave the container alone, but to correctly destroy xdrs. Use it in krb5_ldap_put_principal where princ_ent was leaked. In krb5_ldap_put_principal, subtreelist is declared twice in interior scopes and not properly freed; move it to function scope and free it up in the cleanup label. Also in krb5_ldap_put_principal, avoiding decoding multiple KBR5_TL_KADM_DATA values (which we don't expect to see) as later decodes would cause earlier decodes to leak. In krb5_encode_krbsecretkey, fix a leak of the krb5_data container and also add an error check when calling asn1_encode_sequence_of_keys; otherwise we would dereference a null pointer if we run out of memory encoding keys (very unlikely). ticket: 7941 (new) target_version: 1.12.2 tags: pullup
* Include autoconf.h before system headersGreg Hudson2014-07-0811-24/+14
| | | | | | | | | Include autoconf.h (either directly or via proxy) before system headers, so that feature test macros defined there can affect the system namespace. Where include order was changed, eliminate some redundant or unnecessary includes. ticket: 7961
* Simplify usage of strerror_rGreg Hudson2014-07-081-5/+0
| | | | | | | | Take advantage of the strerror_r portability wrapper to simplify code using it. Remove unused macros related to strerror_r in ldap_service_stash.c and plugins.c. ticket: 7961
* Tidy up k5-int.h variable name constantsGreg Hudson2014-06-161-1/+1
| | | | | Fix three mismatched constant names, and properly alphabetize and columnize the lists of definitions. No functional changes.
* Treat LDAP KrbKey salt field as optionalGreg Hudson2014-06-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Per the ASN.1 definition, the KrbKey salt field is optional. Since 1.7, we have been treating it as mandatory in the encoder; since 1.11, we have been treating it as mandatory in the decoder. Mostly by luck, we have been encoding a salt type of 0 when key_data_ver is 1, but we really should not be looking at key_data_type[1] or key_data_length[1] in this situation. Treat the salt field as optional in the encoder and decoder. Although the previous commit ensures that we continue to always encode a salt (without any dangerous assumptions about krb5_key_data constructors), this change will allow us to decode key data encoded by 1.6 without salt fields. This also fixes issue #7918, by properly setting key_data_ver to 2 if a salt type but no salt value is present. It is difficult to get the decoder to actually assign 2 to key_data_ver just because the salt field is there, so take care of that in asn1_decode_sequence_of_keys. Adjust kdbtest.c to match the new behavior by setting key_data_ver to 2 in both test keys. ticket: 7919 target_version: 1.12.2 tags: pullup
* Always include salt in LDAP KrbKey encodingGreg Hudson2014-06-051-1/+20
| | | | | | | | | | | | | | | | | | | In the LDAP KDB module, ensure that every krb5_key_data we pass to asn1_encode_sequence_of_keys includes a salt type, for compatibility with the decoder in unpatched krb5 1.11 and 1.12. This is not a behavior change by itself; since 1.7 the encoder has always included a KrbKey salt field because it erroneously treats that field as non-optional. (Luckily, the encoded salt always happens to have salt type 0 because krb5_key_data constructors start with zeroed memory.) The next commit will fix the encoder and decoder to properly treat the KrbKey salt field as optional, so we need this change to ensure that our encodings remain compatible. Also fix the ASN.1 tests to set key_data_ver correctly for the sample test key data. ticket: 7919
* Use k5_setmsgGreg Hudson2014-06-0512-126/+98
| | | | | | Replace most calls to krb5_set_error_message with k5_setmsg for brevity. Leave alone plugin sources where we don't include k5-int.h (mostly PKINIT).
* Conditionalize use of LDAP_OPT_DEBUG_LEVELGreg Hudson2014-02-281-0/+2
| | | | | | | | | The LDAP debug level option (#7551) causes a build failure with the Solaris LDAP library, which does not have LDAP_OPT_DEBUG_LEVEL. ticket: 7870 (new) target_version: 1.12.2 tags: pullup
* Assume <stdint.h> and fixed-width typesGreg Hudson2014-02-261-6/+0
| | | | | | | Make unconditional use of <stdint.h> and fixed-width types such as uint32_t. k5-plugin.h doesn't use any special integer types, so remove the conditional include block there. Nothing uses INT64_FMT/UINT64_FMT, so leave those out of k5-platform.h for now.
* Use system dictionary for db2 tests againGreg Hudson2014-02-191-4/+13
| | | | | | | | | | The built-in word list is not long enough for all of the libdb2 tests to run properly. Revert d21a86e47a7cda29225013e08d060095b94b2ee7 and go back to using the system dictionary if we find one. However, omit any lines from the chosen word list which contain non-alphabetical characters. ticket: 7860
* Use TAILQ macros instead of CIRCLEQ in libdb2Greg Hudson2014-02-192-27/+24
| | | | | | | | | The optimizer in gcc 4.8.1 (but not the current gcc head revision) breaks the queue.h CIRCLEQ macros, apparently due to an overzealous strict aliasing deduction. Use TAILQ macros in the libdb2 mpool code instead. ticket: 7860
* Don't use system dictionary files for DB2 testsGreg Hudson2014-02-111-8/+0
| | | | | | | | | The system dictionary may contain entries with punctuation, which can confuse the shell. It's more predictable to always use the word list from the source tree. ticket: 7860 status: open
* Remove mentions of krb5-send-prTom Yu2014-01-151-2/+1
| | | | | | | | | | | | | | Start the process of deprecating krb5-send-pr. In practice, it causes frustration for some users, and free-form email is good enough for most bug reports. Continue to install krb5-send-pr for now, but plan to remove it from the tree in the future, probably replaced by a script that instructs the user to send email manually. ticket: 5566 target_version: 1.12.1 tags: pullup
* Improve LDAP KDB initialization error messagesGreg Hudson2013-10-301-7/+7
| | | | | | | | | | | | | In krb5_ldap_initialize, don't just blat the LDAP error into the extended message; give an indication of which LDAP operation we were trying to do and show what parameters we gave to it. (Also, krb5_set_error_message can handle a null context argument, so don't bother to check before calling.) ticket: 7739 (new) target_version: 1.12 tags: pullup
* Avoid allocating zero key_data structuresGreg Hudson2013-07-151-1/+2
| | | | | | | | When we allocate space for an array of key_data structures, make sure we allocate at least one, so we don't spuriously fail on platforms where malloc(0) returns NULL. Where we use malloc, use k5calloc instead. Where we use krb5_db_alloc or realloc, just allocate an extra entry.
* Use k5calloc instead of k5alloc where appropriateGreg Hudson2013-07-112-10/+12
| | | | | Wherever we use k5alloc with a multiplication in the size parameter,, use the new k5calloc helper function instead.
* Fix various warningsGreg Hudson2013-06-077-43/+36
|
* Fix warnings in dbtest.cGilles Espinasse2013-05-311-20/+38
| | | | | | | | | Check return values of read() and write(). Avoid some unsigned comparisons. Cast a ptrdiff_t value to int for use with %d in a format string. [ghudson@mit.edu: rewrap long lines; fix one more warning; commit message]
* Link dbtest with libkrb5supportGreg Hudson2013-05-311-2/+2
| | | | | | | | In a static build, linking dbtest could fail on platforms where libdb2 depends on krb5support (platforms without a native mkstemp). Reported by Gilles Espinasse <g.esp@free.fr>. ticket: 7651
* Reduce boilerplate in makefilesGreg Hudson2013-05-167-55/+2
| | | | | | | | | Provide default values in pre.in for PROG_LIBPATH, PROG_RPATH, SHLIB_DIRS, SHLIB_RDIRS, and STOBJLISTS so that they don't have to be specified in the common case. Rename KRB5_RUN_ENV and KRB5_RUN_VARS to RUN_SETUP (already the most commonly used name) and RUN_VARS. Make sure to use DEFINES for local defines (not DEFS). Remove some other unnecessary makefile content.
* Assume mutex locking cannot failGreg Hudson2013-05-144-31/+13
| | | | | | | | | | | | Locking and unlocking a non-recursive mutex is a simple memory operation and should not fail on any reasonable platform with correct usage. A pthread mutex can return EDEADLK on lock or EPERM on unlock, or EINVAL if the mutex is uninitialized, but all of these conditions would reflect serious bugs in the calling code. Change the k5_mutex_lock and k5_mutex_unlock wrappers to return void and adjust all call sites. Propagate this change through k5_cc_mutex_lock and k5_cc_mutex_unlock as well.
* Fix type mismatch in db2_exp.cGreg Hudson2013-05-101-1/+1
| | | | | | The locking wrapper for audit_as_req used the wrong function signature, which was harmless but produced a couple of warnings. Fix it.
* Improve LDAP password file error messagesGreg Hudson2013-05-081-2/+6
| | | | | | | If we cannot open the LDAP password file or cannot find the bind DN in it, include the filename and DN in the error message. ticket: 7632
* Simplify krb5_ldap_readpasswordGreg Hudson2013-03-291-19/+2
| | | | | | There's no need to check whether the file exists and is readable before opening it, and setting an extended error message which is just strerror_r() of the errno value isn't useful.
* Fix kdb_ldap_create_principal cleanupGreg Hudson2013-03-281-2/+2
| | | | entry must be initialized before all code which can jump to cleanup.
* Fix more password_policy cleanup codeGreg Hudson2013-03-281-11/+6
| | | | | Initialize policy_dn in krb5_ldap_create_password_policy; free values unconditionally in all ldap_pwd_policy.c cleanup handlers.
* Get rid of krb5_xfreeGreg Hudson2013-03-282-23/+23
|
* Fix krb5_ldap_put_password_policy cleanupGreg Hudson2013-03-281-3/+2
| | | | | Initialize policy_dn since we clean it up. Also free it unconditionally.
* Init output parameter of krb5_decode_princ_entryGreg Hudson2013-03-281-0/+2
| | | | | For easier static analysis, make sure that krb5_decode_princ_entry always sets *entry_ptr to a valid entry or NULL.
* make dependGreg Hudson2013-03-244-124/+112
|
* Eliminate unused variablesGreg Hudson2013-03-151-1/+1
|
* Initialize status in krb5_ldap_parse_db_paramsGreg Hudson2013-03-111-1/+1
| | | | | | | | If db_args is non-null but empty, status could be returned without being initialized; gcc with optimization correctly warns about this, causing a build failure. (This bug was introduced by 0b1dc2f93da4c860dd27f1ac997617b712dff383 which was pushed after the 1.11 release branch, so it isn't in any release.)
generated by cgit (git 2.34.1) at 2026-01-26 17:59:56 +0000