After your recent fixes for strace crashes, I reviewed strace for other memory management issues. I found 8 bugs which could lead to easily reproduced crash, and 4 bugs which are unlikely to be triggered. Still unclear, whether some of these overflows could lead to privilege escalation or not, so setting "security" tag in case they are not just crash bugs.
Created attachment 114990 [details] strace-4.5.11-alt-mem-fixes.patch for cvs snapshot 20050526 Proposed fix.
Created attachment 114992 [details] xattr.c This program demonstrates crash in print_xattr_val(). Test with "strace -e trace=fsetxattr ./xattr".
Created attachment 114993 [details] iov.c This program demonstrates crash in tprint_iov(). Test with "strace -e trace=writev ./iov".
Created attachment 114994 [details] nodes.c This program demonstrates crash in get_nodes(). Test with "strace -e trace=get_mempolicy ./nodes".
Created attachment 114996 [details] msg.c This program demonstrates crash in printcmsghdr(). Test with "strace -e trace=sendmsg ./msg".
Created attachment 114997 [details] msg2.c This program demonstrates another crash in printcmsghdr(). Test with "strace -e trace=sendmsg ./msg2".
Created attachment 114998 [details] setgroups.c This program demonstrates crash in sys_setgroups32(). Test with "strace -e trace=setgroups32 ./setgroups".
Created attachment 114999 [details] poll.c This program demonstrates crash in sys_poll(). Test with "strace -e trace=poll ./poll".
Created attachment 115000 [details] sysctl.c This program demonstrates crash in sys_sysctl(). Test with "strace -e trace=_sysctl ./sysctl".
Well, it is not easy to use these bugs to get something more than instant crash. Let's remove "security" tag then?
Thanks for all those test cases, and the fixes! I've put the patch in upstream. I'll check with our security folks whether they think these problems need to be treated as security issues.
If there is no potential for arbitrary code execution, then I don't see any of these as being security issues.
I also do not think these are security bugs. That's because the program being traced is already granted the ability to execute arbitrary code/syscalls. strace is not a policy enforcement tool, and not even an interactive debugger where one may single-step or the like not letting the program do nasty things. But we need to get the bugs fixed indeed. (Should the Summary read "multiple", not "multiply"?)
I know that strace is oftenly used by root user to trace various applications, including less privileged ones. These bugs allow applications to overwrite arbitrary address of strace memory, but I found no way (yet?) how it can be used to gain control over strace itself. Ok, lets hope it is not possible.
Oh, you're referring to strace's ability to attach to already-executing processes, which may be _known_ to be _already_ running as non-root, correct? This is something I've overlooked when writing my previous comment. OK, these may be security bugs, then.
These fixes are in the upstream cvs, lifting embargo.
Fixed in strace-4.5.12.