I think the others have given a decent explanation, but I would like to
elaborate a little furter.
The Linux documentation says the following:
Preferred to strlcpy since the API doesn't require reading memory from
the src string beyond the specified "count" bytes, and since the return
value is easier to error-check than strlcpy's. In addition, the
implementation is robust to the string changing out from underneath it,
unlike the current strlcpy implementation.
OK, so strscpy won't read any more data from src than count bytes, which
could save you from reading from the end of the world, where strlcpy
does assume that src is a NUL-terminated string. So it's not 100%
identical to the wrapper around strlcpy. But here also comes a wrong
sense of security.
Consider the following C code:
#include <stdio.h>
#include <string.h>
char *
crapcopy(char *src)
{
static char dst[1048576]; /* something big -> 1MB*/
strlcpy(dst, src, sizeof(dst));
return dst;
}
void
func(void)
{
char src[2];
src[0] = 'a';
src[1] = 'b';
printf("%s\n", crapcopy(src));
}
src is clearly not a C-string, since it's not NUL-terminated, but
there's no problem, since strscpy doesn't throw us over the edge of the
world. Right?
The problem is that you don't know what comes after src. It could be
sensitive information that's now being made available to an attacker, it
could introduce byte-sequences that completely blow up your terminal.
You just can't tell for sure. With strlcpy chances are greater that you
hit a page that's not mapped readable and you generate a SEGFAULT.
Like Joel said in his talk, it's better to crash and fix the bug.
Note that I'm not familiar enough with the kernel to make any statement
on whether on not things work identically there.
If you want to be 100% secure you'd need to keep track of both the src
length (note that's the length of the string and not of the allocated
memory) and the destination buffer size and built a set of string
manipulation functions around that. But that would be a lot more tedious
to use and one could just as easily overlook to change the length
attribute upon change, which brings you back to square one.
If documentation states that it requires a NUL-terminated string to
function just make damn sure that thing is NUL-terminated, which can
best be done by building it with functions that guarantee to NUL-
terminate their return string.
I'm not certain what the author tries to say with "the implementation
is robust to the string changing out from underneath it", so I won't
comment on that part.
martijn@
On 1/27/19 7:07 AM, 0sjfoij...@firemail.cc wrote:
> Recently on LCA2019, Joel Sing made a presentation about "Security
> Vulnerability Mitigations"[1]
> (very good, btw). He suggests function strlcpy(3) as a secure API.
> In the same conference, though, Kees Cook ("Making C Less Dangerous in the
> Linux kernel"[2]),
> recommends strscpy() as more secure. So, my question is: what's the best to
> use?
>
> Thanks in advance.
>
>
> [1] https://youtube.com/watch?v=9-uNC4-RbQM
> [2] https://youtube.com/watch?v=FY9SbqTO5GQ
>
