You're absolutely correct if the length of value to be copied is not validated prior to the copy. Then, an invalid page could be hit if no nil is present within the array or beyond.
I wasn't providing a verbatim patch (notice the function and operator weren't filled in). I was just providing the sequence of events that should occur. Eric points out correctly that strncpy effectively performs the first operation on the user's behalf. The second is achieved through the write to N. To be verbose, my bypassing of strncpy is due to issues I've encountered in multi-threaded code. e.g. Don't trust libc copy functions in MT envs, always check post call. An interesting and sometimes desirable effect of crashing on an invalid page read is that if memory can be corrupted, a consistent unexploitable crash is better than entering a context where the bug becomes exploitable. D On Jun 5, 2013, at 7:38 AM, Friedrich Psiorz <f.psi...@gmx.de> wrote: > I think your code is wrong. If the NUL byte is present, it doesn't do > anything, however if it is not there, strlen will read more than it > should, and possibly try to read some invalid address. > In case info.host is a fixe size array, a simple > info.host[sizeof info.host - 1] = 0; > would do. > > Am 05.06.2013 15:13, schrieb Don Bailey: >> The first opportunity to write a nil byte should always be taken. Using >> sizeof only means that in corner cases memory disclosure may occur between >> where the nil should be and the end of the array. While this isn't a >> security critical app, it is still good coding practice. >> >> x = strlen(info.host) < sizeof info.host ? strlen() : sizeof ; >> info.host[x] = 0; >> >> D > >
