Date: Fri, 30 Jul 2010 00:55:58 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: d@delphij.net Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Gabor Kovesdan <gabor@FreeBSD.ORG> Subject: Re: svn commit: r210578 - head/usr.bin/grep Message-ID: <20100729225558.GB42378@stack.nl> In-Reply-To: <4C51FFB6.7040802@delphij.net> References: <201007290011.o6T0BE0l072516@svn.freebsd.org> <20100729122034.GA28899@stack.nl> <4C51FFB6.7040802@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 29, 2010 at 03:24:54PM -0700, Xin LI wrote: > On 2010/07/29 05:20, Jilles Tjoelker wrote: > > Note that this code may not be safe if fg->len comes from an untrusted > > user, as fg->len + 1 is 0 if fg->len == SIZE_MAX. This is not the case > > if fg->len is an actual length from strlen() or similar. > Speaking for this piece of code, I have to say that the modified version > is actually safer (an improvement, as the attacker could not overwrite > arbitrary memory). > If fg->len + 1 == 0, fg->pattern would point to a small area (assuming > normal malloc.conf setting without V) where, for memcpy, it would > overwrite fg->len bytes, while strlcpy() will do nothing. > By the way how can fg->len come from an untrusted party? It's > strlen(pat) which I don't think can ever reach SIZE_MAX without crashing > the program. Right, fg->len comes from a strlen() so adding one to it is safe. My remark was directed at similar code where a length comes from a number supplied by an untrusted user. > I'll dig further for this piece of code anyways. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100729225558.GB42378>