Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

Parent Full thread

If you are going to do that check, there is almost no value to using this function as you can do a similar check before copying the string. (The only benefit you get is that if you don't know the length of the source string you save having to first calculate it; but that's a performance optimization, not a fundamentally different paradigm.)

The thing is, though: no one actually checks that return value, as this idea that using this API is what makes things secure has become zeitgeist. This post from OpenBSD is even making this mistake: they care only that people are using the API, not that they are using it correctly (despite pointing out the truncation issue at the end, they are just analyzing the usage, not the correctness). Just using this API is not a magic bullet: if you are using the API incorrectly, your program is still incorrect, and if you are using it correctly you can just use strcpy correctly.

If you don't believe me, this is a really depressing search to perform:

site:opensource.apple.com "strlcpy" -"strlcpy.c" -"strlcpy.s" -"strlcpy.3" -"strlcpy.h"

OpenSSH doesn't even check strlcpy correctly...

    317         /* No MIN_SIZEOF here - we absolutely *must not* truncate the
    318          * username (XXX - so check for trunc!) */
    319         strlcpy(li->username, pw->pw_name, sizeof(li->username));

Yeah, that's great: we "absolutely must not" do something, but it's marked as a XXX?!?!?

If the world wrote perfect code, nobody would have ever needed to replace strcpy. Water is wet.

Yet somehow, even you admit that they have some use because "almost no value" is infinitely more value than "no value". The benefit you describe is exactly what's beneficial. strlcpy does the length calculation, and prevents overflowing the buffer, which is a reasonable improvement over calling strcpy and trusting that previous checks (if they exist at all) are correct. Truncation (unless intended) can never occur when the program is correct, it merely exchanges one vulnerability for another one, which rarely can be exploited.

That noone checks for the return value is trivially false. That Theo only cares about usage and not about correct usage is also false. Just because something isn't in a mail doesn't mean you can come to the reverse conclusion and claim the person doesn't care about a topic not mentioned. Most people tackle bigger problems first, before getting into discussions about writing "perfect" code.

Given you are a perfect programmer (I assume), why don't you check the openssh code you quoted and let us know how you would've handled it? I looked at it, it's part of (portable) utmp logging and will truncate the username from passwd(5) to fit into the utmp structure. Nothing much can be done about it, because the two structures do not agree on common size limits.

Demanding perfection while being unwilling to improve the status quo is hypocritical.

Yeah, that's wrong and I'll fix it. Impact: if your username is > 511 characters long and truncates to another valid username that is exactly 511 characters long then you will see their "last logged in" date instead of yours.

Meanwhile, how many overflows have even the naive conversions of strc=>strl saved?

> how many overflows have even the naive conversions of strc=>strl saved?

We should ask you.

Reply on news.ycombinator.com