-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: OpenDNSSEC 1.0.0, OpenDNSSEC 1.1.0, OpenDNSSEC 1.1.1, OpenDNSSEC 1.1.2, OpenDNSSEC 1.1.3, OpenDNSSEC 1.2.0, OpenDNSSEC 1.2.1, OpenDNSSEC 1.2.2, OpenDNSSEC 1.3.0, OpenDNSSEC 1.3.1, OpenDNSSEC 1.3.2, OpenDNSSEC 1.3.3, OpenDNSSEC 1.3.4, OpenDNSSEC 1.3.5, OpenDNSSEC 1.3.6, OpenDNSSEC 1.3.7, OpenDNSSEC 1.3.8, OpenDNSSEC 1.4.0a1, OpenDNSSEC 1.4.0a2, OpenDNSSEC 2.0.0a3, OpenDNSSEC 1.3.9, OpenDNSSEC 1.3.10, OpenDNSSEC 1.4.0a3, OpenDNSSEC 1.4.0b1, OpenDNSSEC 1.3.11, OpenDNSSEC 1.3.12, OpenDNSSEC 1.3.13, OpenDNSSEC 1.3.14, OpenDNSSEC 1.4.0b2, OpenDNSSEC 1.4.0rc1, OpenDNSSEC 1.4.0rc2, OpenDNSSEC 1.4.0b3, OpenDNSSEC 1.4.0rc3, OpenDNSSEC 1.4.0, OpenDNSSEC 1.4.1, OpenDNSSEC 1.4.2, OpenDNSSEC 1.3.15, OpenDNSSEC 1.3.16, OpenDNSSEC 1.4.3, OpenDNSSEC 2.0
-
Fix Version/s: None
-
Component/s: PKCS#11 Interface
-
Labels:None
At least since revision 903, the function hsm_list_keys_session_internal, contained in libhsm.c, is prone to a denial of service (segfault).
realloc is used to allocate an ever-extending table of CK_OBJECT_HANDLE, based on the results of C_FindObjects calls.
No more than max_object_count (100) object handles can be fetched at once. However as long as objects are found (0 != objectCount), the non-null objectCount is added to the total_count counter. This total_count is then used in the realloc call, where it is multiplied by the sizeof CK_OBJECT_HANDLE.
The result of the realloc is not checked and the while(objectCount > 0) is unbound. This means that an adversarial HSM could return non-null objectCount until memory is filled and realloc returns NULL.
A few lines later, this would result in an attempt to dereference a NULL pointer and write there, thus causing a denial of service (segfault).
On top of that denial of service, total_count being a CK_ULONG, the multiplication "total_count * sizeof(CK_OBJECT_HANDLE)" could result in an integer overflow.
I am not sure whether this integer overflow resulting in a very low amount of reallocated memory could result in an exploitable heap buffer overflow. The answer might be dependent on the libc realloc implementation.
I think a check should be performed, in any case.
Please find in attachment a patch for this issue.
- is cloned by
-
OPENDNSSEC-539 Memory corruption (improper realloc call) in hsm_list_keys_session_internal (libhsm.c)
-
- Closed
-