Well, it's a "real" flawfinder issue but in this case I've no idea what to do about it - it's complaining about readlink in the realpath implementation we're using to guarantee a working realpath on Linux, but I have no idea how to decode symbolic links for that purpose without using it...
aha, interesting. yep, that's an old syscall flaw
here's what flawfinder says about it:
"readlink":
(normal, 5,
"This accepts filename arguments; if an attacker " +
"can move those files or change the link content, " +
"a race condition results. " +
"Also, it does not terminate with ASCII NUL. (CWE-362, CWE-20)",
# This is often just a bad idea, and it's hard to suggest a
# simple alternative:
"Reconsider approach",
"race", "", {'input' : 1}),
We can certainly ensure the null-termination is accounted for, but not the first issue.
It gets pretty good coverage of the issues in this secure programming book: https://books.google.com/books?id=GL8AeTCu1WAC&pg=PT218&lpg=PT218&dq=%22readlink%22+%22safe%22&source=bl&ots=igMmAwNZQn&sig=ACfU3U3cjlgBWaD-Z8VElKaoqkMwgQhVTA&hl=en&sa=X&ved=2ahUKEwjnhZPwteLpAhX9lHIEHapBAsAQ6AEwB3oECAoQAQ#v=onepage&q=%22readlink%22%20%22safe%22&f=false
looks like realpath_bsd.c is guilty of the 4th issue, but then so are we
looks like flawfinder has categorized this as a level 5 issue, i.e., the highest level of risk possible
Last updated: Jan 09 2025 at 00:46 UTC