Date: Tue, 14 Jan 1997 14:47:57 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, davidn@unique.usn.blaze.net.au Cc: hackers@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: unused variable in su Message-ID: <199701140347.OAA20727@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> It should be strdup(). Using strncpy() or snprintf() to handle buffer >> overflows by truncating the string is sloppy. > >No, it is defensive programming, pure and simple. > >The buffer already IS a reasonable size - in fact, it is the >maximum legal path size. If the string copied into it is too Actually, it's the size of the longest path that is guaranteed to be acceptable to system calls that look up pathnames. Longer paths may work with non-system calls. E.g., getpwd() may return a path longer than MAXPATHLEN. >long, then it is going to get rejected by the execvp() anyway >- only the error number changes - EEXIST vs. ENAMETOOLONG. No, after you've truncated it to length MAXPATHLEN - 1, execv() may exec the wrong program. (execvp() would be a security hole in su, execvp() is careful about this problem. Try this: PATH=/111...:$PATH where there are about MAXPATHLEN 1's in the first component. execvp() will print a lot of annoying error messages.) >There is an advantage the snprintf() case, at least you can >detect if the formatted string would have overflowed. Although >it seems that the snprintf() return value is not often (enough) >checked. IMHO, it should be, perhaps even via syslog(), if >early notification of possible attacks is useful. How about using functions strancpy(), ..., asnprintf() that abort if the string is too long? This would be better than silently truncating the string. It would also take less code for the strncpy() case since null trermination would be guaranteed (else abort). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701140347.OAA20727>