[Semibug] Potential danger of strlcpy

[Nick Holland]

On 2019-11-20 06:03, Mike O'Connor wrote:
> :From our discussion tonight: it can be dangerous to replace strncpy() calls
> :with strlcpy() in a kernel setting [1].  The problem is that since strlcpy()
> :doesn't zero out the remainder of a string buffer like strncpy(), it can lead
> :to inadvertent leaks of data from the kernel.  If that unzeroed section of
> :memory happens to contain internal kernel memory addresses, it could be used to
> :help defeat ASLR.
> :
> :[1] https://twitter.com/grsecurity/status/1082957293489147904

"strlcpy doesn't zero pad to the length provided, so if this is some buffer 
being copied in full to userland -> infoleak"

in response to:
"Another example of naive strlcpy use introducing a vulnerability"

> FWIW, strlcpy doesn't zero out the remainder of the string buffer for
> performance reasons.  zero-filling has a non-zero cost.  
> 
> In general, strlcpy won't really help you if you're not checking its
> return value (assuming you can ascertain what to check against)
> 
> I'm amused that you're citing a Linux security guru, when strlcpy has
> BSD history and is still verboten in glibc.  :)

The OpenBSD team has been pretty clear that strlcpy / strlcat is NOT
a *drop-in* replacement or intended for "naive" use.  It IS a different
function, it works differently.  The problem with strncat and strncpy
is that they don't behave as people expect. The point is it works more
understandably and predictably -- and thus, differently.

So ... improper strlcpy use introduces problems.  Yep. Water is still
wet, fire still hot, Michigan winter still gloomy.  No news.

Data leakage through unzeroed strings is a different problem -- one
complicated by compilers "optimizing" away writing of data where they
(supposedly) don't matter.  This lead to the OpenBSD team coming up with
the explicit_bzero function...which is in glibc now.  Assuming the compiler
won't "help" performance by removing "useless code" like zeroing data is
perhaps unexpectedly dangerous.  If you want data to go away (a good
thing), make it go away explicitly.

Nick.