forked from elastic/elasticsearch
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix memory leak from JWT cache (and fix the usage of the JWT auth cac…
…he) (elastic#101799) This commit fixes a memory leak and ensures that the JWT authentication cache is actually used to short circuit authenticate. When JWT authentication is successful we cache a hash(JWT) -> User. On subsequent authentication attempts we should short circuit some of the more expensive validation thanks to this cache. The existing cache key is a `BytesArray` constructed from `jwtAuthenticationToken.getUserCredentialsHash()` (the hash value of the JWT). However, `jwtAuthenticationToken` is comes from the security context which is effectively a request scoped object. When the security context goes out of scope the value of `jwtAuthenticationToken.getUserCredentialsHash()` is zero'ed out to help keep sensitive data out of the heap. It is arguable if zero'ing out that data is useful especially for a hashed value, but is inline with the internal contract/expectations. Since the cache key is derived from `jwtAuthenticationToken.getUserCredentialsHash()` when that get object is zero'ed out, so is the cache key. This results in a cache key that changes from a valid value to an empty byte array. This results in a junk cache entry. Subsequent authentication with the same JWT will result in a new cache entry which will then follow the same pattern of getting zero'ed out. This results in a useless cache with nothing but zero'ed out cache keys. This negates any benefits of having a cache at all in that a full authentication is preformed all the time which can be expensive for JWT (especially since JWT requires role mappings and role mappings are not cached). Fortunately the default cache size is 100k (by count) so the actual memory leak is technically capped but can vary depending on how large the cache values. This is an approximate cap of ~55MB where 3.125 MB (100k * 256 bits) for the sha256 cache keys + ~50MB (100k * ~50 bytes) cache values, however, it is possible for the cache to be larger if the values in the cache are larger. The fix here is to ensure the cache key used is a copy of the value that is zero'ed out (before it is zero'ed out). fixes: elastic#101752
- Loading branch information
1 parent
63f29d4
commit cef2b80
Showing
4 changed files
with
74 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
pr: 101799 | ||
summary: Fix memory leak from JWT cache (and fix the usage of the JWT auth cache) | ||
area: Authentication | ||
type: bug | ||
issues: [] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters