Repository navigation
fix stack overflow building absolute path from relative symlink target - #6425
Dhanu-dynamic wants to merge 2 commits into
Conversation
cf-agent reconstructs the absolute target of a relative symbolic link by appending the readlink() result onto the link's directory name in a CF_BUFSIZE stack buffer. KillGhostLink() in files_links.c did this with an unbounded strcat(linkpath, linkbuf), and LinkCopy() in verify_files_utils.c with strncat(vbuff, linkbuf, CF_BUFSIZE - 1), whose third argument is the maximum number of bytes to take from the source, not the space left in the destination. readlink() returns up to CF_BUFSIZE - 1 bytes, so a symlink whose relative target is near CF_BUFSIZE, left by an unprivileged user in a directory that a root files promise walks (depth_search, perms, link copy), overflows the stack of the agent. KillGhostLink() runs on every symlink met during a recursive descent, before the dead-link stat(). Bound both appends with strlcat(..., sizeof(buf)), the same way ExpandLinks() in files_links.c already does, and have KillGhostLink() bail out with an "Internal limit reached" message when the target does not fit. Normal links are unchanged. Changelog: Title Signed-off-by: Dhanraj E <dhanraj@labs.digiscrypt.com>
|
Thanks for submitting a pull request! Maybe @craigcomstock can review this? |
larsewi
left a comment
There was a problem hiding this comment.
Thanks 🚀 A few notes:
A link target too long is silently truncated. The truncated path could produce an absolute link pointing to somewhere else (unintended). It would be safer to fail with error.
The unit test fails on macOS, because it rejects too long targets. Maybe you can skip if symlink() sets errno to ENAMETOOLONG?
…rget Also skip the KillGhostLink() regression test when symlink() rejects the long target with ENAMETOOLONG, as macOS does. Changelog: None Signed-off-by: Dhanraj E <dhanraj@labs.digiscrypt.com>
fc01b23 to
8a156de
Compare
|
Agreed, a truncated target could end up as a valid absolute link pointing somewhere unintended. |
|
@cf-bottom Jenkins please :) @Dhanu-dynamic can you please squash the two commits? |
|
Sure, I triggered a build: Jenkins: https://ci.cfengine.com/job/pr-pipeline/15003/ Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-15003/ |
KillGhostLink() in libpromises/files_links.c and LinkCopy() in
cf-agent/verify_files_utils.c reconstruct the absolute target of a relative
symbolic link by appending the readlink() result onto the link's directory
name in a CF_BUFSIZE stack buffer:
The strcat() is unbounded, and the strncat() third argument is the maximum
number of bytes to take from the source, not the space left in vbuff, so it
does not bound the destination either. readlink() returns up to CF_BUFSIZE-1
bytes, so a symlink whose relative target is near CF_BUFSIZE, placed by an
unprivileged user in any directory a root files promise walks (depth_search,
perms, or a link-type copy), overflows the agent's stack. KillGhostLink()
runs on every symlink met during a recursive descent, before the dead-link
stat(), so reaching it only takes one such link under a recursive promise.
Bound both appends with strlcat(..., sizeof(buf)), the same way ExpandLinks()
in files_links.c already bounds this exact operation, and have KillGhostLink()
bail out with an "Internal limit reached" message when the target does not
fit. Valid links are unchanged.
Verified with AddressSanitizer via a regression test in
tests/unit/files_links_test.c: a relative symlink with a CF_BUFSIZE-sized
target aborts KillGhostLink() with a stack overflow before the change and
returns cleanly after it.