The ups and downs of strlcpy()

Posted Jul 20, 2012 4:15 UTC (Fri) by quotemstr (subscriber, #45331)
In reply to: The ups and downs of strlcpy() by cmccabe
Parent article: The ups and downs of strlcpy()

> You really think that aborting the program is the right behavior when a string is too long?

Yes, I do. It's difficult to turn abort() into an escalation-of-privilege. In a well-written program, you never get to the abort() call because you've already checked the length of the input string and done something sensible, which is rarely to just truncate it.

> Clue: it's not.

I'm glad we're civil around here.

> If mandatory checks are what you want, use something like electric fence, -D_FORTIFY_SOURCE, or, best of all, a managed language!

Programs can't run normally under electric fence. -D_FORTIFY_SOURCE is nice, but it only works when the compiler knows the size of the destination buffer. Sometimes it doesn't, but you do, and you can tell the compiler about the destination buffer. strcpy_s isn't a substitute for length checks; as I mentioned in my first post, you can use strncpy_s to tell the compiler (and your reviewer!) explicitly that you want string truncation. strcpy_s ensures that if you _do_ screw up, your program fails in an obvious and controlled fashion instead of veering off into exciting undefined behavior. -D_FORTIFY_SOURCE can't make the same guarantees in all cases.

> strcpy_s is about as useful as a screen door on a submarine.

It'd reflect better on you if you used metaphors that had some relationship to your argument.

The ups and downs of strlcpy()

Posted Jul 20, 2012 7:20 UTC (Fri) by cmccabe (guest, #60281) [Link] (7 responses)

> Yes, I do. It's difficult to turn abort() into an escalation-of-privilege

However, it's easy to turn abort() into a denial of service.

Look, I realize you are serious, and I'm sorry if I was overly snarky. But your idea just does not make sense. You can't magically make C into a managed language by adding more layers of bureaucracy. It's been tried before and it just doesn't work. And that's all I'm going to say about that.

The ups and downs of strlcpy()

Posted Jul 20, 2012 13:25 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

DoS is much preferable to complete pwning. And the point is, abort()-ing means that there would have been a buffer overflow more likely than not.

The ups and downs of strlcpy()

Posted Jul 20, 2012 17:33 UTC (Fri) by bronson (subscriber, #4806) [Link] (5 responses)

Who said anything about turning C into a managed language?

> You really think that aborting the program is the right behavior when a string is too long?

Yes, obviously yes. You are now outside the parameters of the program as written and the only 100% safe thing to do is just stop.

Or do you know of a magic solution that's not subject to silent truncation attacks?

The ups and downs of strlcpy()

Posted Jul 20, 2012 17:51 UTC (Fri) by jimparis (guest, #38647) [Link] (4 responses)

> > You really think that aborting the program is the right behavior when a string is too long?

> Yes, obviously yes. You are now outside the parameters of the program as written and the only 100% safe thing to do is just stop.

It's not obvious, and it's not always true. Security is hard and there's not always one single answer.

If my code is trying to concatenate "/etc/passwd" and ".bak", then yes, it is likely better to stop executing rather than fail to append the suffix.

But if my code is a web server reading someone's preferred subtitle from a form, it's likely better to truncate "Jimparis the magnificent" to just "Jimparis the magni" if it can't fit in my buffer -- the rest of the code will behave no differently than if the user had just typed the truncated version in the first place, while bringing down a whole server process can easily turn into a DoS.

The ups and downs of strlcpy()

Posted Jul 20, 2012 18:29 UTC (Fri) by quotemstr (subscriber, #45331) [Link]

> it's likely better to truncate "Jimparis the magnificent" to just "Jimparis the magni"

If you want that behavior, you can ask for it. If the programmer doesn't specify, the safer thing to do is abort. You'll notice an abort and fix it fast. You might not notice a truncation vulnerability until it's too late.

The ups and downs of strlcpy()

Posted Jul 20, 2012 20:31 UTC (Fri) by bronson (subscriber, #4806) [Link] (2 responses)

Yes, but is libc told how the string is being used? No.

So what's the only safe thing for libc to do when it notices that initial conditions are invalid?

The ups and downs of strlcpy()

Posted Jul 21, 2012 4:19 UTC (Sat) by cmccabe (guest, #60281) [Link] (1 responses)

libc can't "notice that the conditions are invalid," because C IS NOT A MANAGED LANGUAGE.

We all make copy and paste errors and all other things being equal, long, hard to inspect C code is less secure than short and clear code.

The ups and downs of strlcpy()

Posted Jul 25, 2012 2:00 UTC (Wed) by bronson (subscriber, #4806) [Link]

You don't need a managed language to make strlcpy abort instead of truncating.

I agree with the rest of your comment.