saml_binding_post_parse leaks the base64-decoded response buffer on every parse

Open Beginner friendly
#63 0 comments 0 reactions 0 assignees View on GitHub

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

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) allocates decoded.
  • xmlReadMemory((char*)decoded, decoded_len, ...) copies the bytes into the document.
  • The function then returns SAML_OK (and the DTD / schema-validation early returns) without free(decoded). The only free(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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from api7/lua-resty-saml

All issues in api7/lua-resty-saml

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.