saml_binding_post_parse leaks the base64-decoded response buffer on every parse
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c
- Domain
- authentication
Research direction
Start in src/binding.c at saml_binding_post_parse, then inspect saml_base64_decode in src/codecs.c:64 to confirm the decoded buffer's ownership. Build with AddressSanitizer and LeakSanitizer and run the valid-base64 SAMLResponse loop described in the reproducer. Done means the parser's success and validation-related return paths no longer report the decoded response buffer as leaked.
Written by the indexing model from the issue text.
Description
Summary
saml_binding_post_parse leaks the base64-decoded response buffer on every parse. The buffer is decoded, handed to xmlReadMemory (which copies into the libxml2 document), and never freed on the success path.
Where
src/binding.c, saml_binding_post_parse (current main, 7d88f4e):
saml_base64_decode(src/codecs.c:64) allocatesdecoded.xmlReadMemory((char*)decoded, decoded_len, ...)copies the bytes into the document.- The function then returns
SAML_OK(and the DTD / schema-validation early returns) withoutfree(decoded). The onlyfree(decoded)is on the base64-decode failure path.
Impact
One heap buffer the size of the decoded SAML response leaks per POST callback. Under AddressSanitizer/LeakSanitizer, a standalone driver calling the real parse path shows ~response-sized bytes leaked per parse (measured ~2.7 KB per ~2.7 KB response; scales linearly with the number of parses). Because the callback is reachable pre-authentication and the attacker controls the POST body size, this is a slow memory-exhaustion amplifier for a long-lived worker.
Reproducer
Build the C sources with -fsanitize=address and drive saml_binding_post_parse in a loop over a valid base64 SAMLResponse; LeakSanitizer reports the saml_base64_decode allocation as definitely lost, accumulating per iteration.
Note
Pre-existing (present in v0.2.5). No memory-safety fault otherwise: the same ASan/UBSan run over a malicious corpus was clean apart from this leak.
Suggested fix
Free decoded on every return path of saml_binding_post_parse after xmlReadMemory has copied it (a single cleanup label, or free immediately once the document is built).
- Dominant language
- Perl
- Stars
- 2
- Forks
- 3
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 3
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from api7/lua-resty-saml
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
api7/lua-resty-saml#62 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
api7/lua-resty-saml#45 · 1 comment · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
api7/lua-resty-saml#64 ·
-
api7/lua-resty-saml#61 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
api7/lua-resty-saml#59 ·
All issues in api7/lua-resty-saml
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 60/100
conda-forge/perl-test-warn-feedstock#1 · 1 comment · 1 reaction ·
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
conda-forge/perl-test-fatal-feedstock#6 · 1 comment · 1 reaction ·