Better code searching for Debian

Posted Dec 26, 2014 4:15 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: Better code searching for Debian by amarao
Parent article: Better code searching for Debian

A bug for you! A bug for you! Bugs for everyone!</oprah>

Better code searching for Debian

Posted Dec 29, 2014 23:56 UTC (Mon) by debacle (subscriber, #7114) [Link] (5 responses)

Let us all LD_PRELOAD this function to everything:

char *strcpy(char *dest, const char *src)
{
	system("logger BUG!");
	return NULL;
}

Better code searching for Debian

Posted Dec 31, 2014 0:13 UTC (Wed) by lsl (subscriber, #86508) [Link] (4 responses)

Why would you want do that? Unlike with gets(3), there's nothing fundamentally broken about strcpy. Cargo culting weird absolute rules ("never use strcpy") is not going to prevent security issues.

Better code searching for Debian

Posted Dec 31, 2014 11:52 UTC (Wed) by JGR (subscriber, #93631) [Link] (2 responses)

Things go very badly wrong if the input string is too long, to the point that using it without calling strlen and performing error-checking first is effectively an error. This is cumbersome boilerplate that people would rather (and do) do without, which leads to security bugs.

I agree that ldpreloading something like the above isn't helpful, but "never use strcpy (directly, use strlcpy or some other wrapper function which takes an output buffer length, does a strlen and does suitable error checking/calls abort first)" is perfectly sound advice.

Better code searching for Debian

Posted Jan 8, 2015 21:59 UTC (Thu) by dfsmith (guest, #20302) [Link] (1 responses)

Note that strlcpy() has an information leak that strncpy() doesn't have. (Fill remaining buffer with '\0': guaranteed for strncpy(), not mentioned for strlcpy().)

Better code searching for Debian

Posted Jan 8, 2015 22:43 UTC (Thu) by zlynx (guest, #2285) [Link]

That isn't an information leak. It's a feature.

I know its a feature because I switched some code from strncpy to strlcpy because profiling showed writing the zeros into an 8KB URL string buffer was wasting a LOT of time.

If you are worried about information leaks then you need to be using a security library and it needs to be written in ASM because compilers are too likely to optimize all the security features away. For example, unless a value is volatile the compiler can remove all writes to it if nothing reads it before destroying it.

Better code searching for Debian

Posted Dec 31, 2014 14:10 UTC (Wed) by debacle (subscriber, #7114) [Link]

The LD_PRELOAD was a joke, of course. Anyway, I avoid strcpy even in cases where I know that the destination can take the copy. strcpy and strncpy just make it too easy to err fataly, e.g. much later when refactoring code. I use either g_strlcpy from glib or strlcpy from BSD instead, even if this has its own problem. Btw. the discussion about adding strlcpy to glibc started in 2000, right? In some hours we have 2015 - is it in there now?