4 ms·

> Theo is making the assumption that most programmers care about security, when in fact, they're probably primarily interested in creating code that works, and

by clarry 13y ago

> Theo is making the assumption that most programmers care about security, when in fact, they're probably primarily interested in creating code that works, and making it secure later. Insecure software is broken software; it doesn't work correctly (unless insecurity is an intended feature, such as in a backdoor). > It doesn't matter what function you use to copy strings. Technically you're right, you can even roll your own loop. However, the purpose of library functions is to make your (and your users' & co-developers') life easier. The strl* functions provide a simple idiom that just works, and it takes less effort than doing arithmetic prior to strcpy/cat calls. It makes it easy for everyone to check that it does indeed work. > In this case what we're talking is not doing bounds checking on input before copying data, which will always end up fucking you in one way or another, regardless of what function you use. The strl* functions are all about doing bounds checking in a simple and compact way while copying data, and they inform you in case the input was too large. They're all about replacing broken (or entirely missing!) hand-rolled bounds checking that you'd write before every strcpy/strcat. Why don't you try audit code that uses strlcat & strlcpy? Grep for these and check that every invocation is correct. Now do the same for code using strcat, strncpy, and strcpy. Check all the arithmetic (which may take up goodness knows how many lines, spread all over the place, in loops, etc.). After a few hundred of these, you should begin to understand why strlcpy and strlcat exist. People have done such massive audits before. And misuse of the standard string functions has indeed caused many many bugs. The secure alternatives weren't invented just for the heck of it; there's actual history behind it.

peterwwillis 13y ago
Yes, I understand why these functions exist. That's my whole point: we shouldn't be nit-picking these functions in regards to security, because simply using them does not make your program secure. You have to actually design for security, not just use strlcpy and believe somehow you have produced secure code. At the same time, just because someone has strcpy in their code, does not mean their code is not secure. So this whole discussion is pointless, is what i'm saying :)
- clarry 13y ago
  Yes it's pointless if people continue to miss the point regarding auditability, and the fact that harder-to-use functions that are also harder to audit are more like to end up used wrong. I realize that many out here don't care about auditability, and never spend hours systematically going through hundreds or thousands of invocations in other people's code, checking for correctness of exactly the kind of code that historically has caused lots of easy-to-exploit security problems. I realize that most people here would probably trust themselves to be able to use strcpy, strncpy, and strcat correctly; I would trust myself too. But that is not the point. With the right idioms, I make it easier for other people to verify the correctness of my code, so they don't need to depend on blind trust. And to be honest, it doesn't take a whole lot of "design" to use strlcat correctly; it is simple. Yes you can misuse it, but I would hold it very likely that most people who actually learn about it, check the manual, and decide to use it, are going to use it correctly.
  - peterwwillis 13y ago
    > I would hold it very likely that most people who actually learn about it, check the manual, and decide to use it, are going to use it correctly. You don't think that's dangerous? If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly, you're going to miss the one or two times it's not, and end up with vulnerabilities. I haven't needed to audit code professionally, but when I do it personally, I don't look for common pitfalls in function use - I look for general scenarios that are dangerous, like working with potentially tainted data. So when I talk about design security, I don't mean what function you use, I mean how it fits into the broader scheme of what the application is trying to do.
    - clarry 13y ago
      > If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly That is not at all what I have said, how did you come up with that? I've been arguing that the idiomatic use of strlcpy is easier to audit than any use of strcpy. > I haven't needed to audit code professionally, but when I do it personally, I don't look for common pitfalls in function use - I look for general scenarios that are dangerous, like working with potentially tainted data. So when I talk about design security, I don't mean what function you use, I mean how it fits into the broader scheme of what the application is trying to do. What you're doing isn't wrong, but looking for common pitfalls is a very easy way to get a baseline assesment of code quality. You'd be surprised at the amount of problems you can find just by looking for arithmetic overflows near memory allocation, misuse of realloc, and the string handling functions. And if the search turns out lots of such problems, trying to understand the design and "broader scheme" is not very useful (at least for me, because at this point I would've decided the software in its current state is simply not good enough for me). There's another reason to look for common pitfalls: you have something very concrete to focus on. You can work mechanically. You can work with grep. It really does make a huge difference. And let's not forget: these common pitfalls are common. And commonly, they are exploitable. And they are the things many attackers would also initially look for. If you "just look" trying to find potential security issues in design or otherwise, but are not looking for anything very specific, you can't be anywhere near as focused, and it will take more time to usefully process the code. If it takes a lot of time, focus is going to get worse with the degrading attention span.. it'll be harder (at least for me) to be certain that the review has actually been thorough and has managed to flag things that need attention. Oh I do look at the broader design of software, but only after getting the low hanging fruit out of the way.

by clarry 13y ago

peterwwillis 13y ago

Yes, I understand why these functions exist. That's my whole point: we shouldn't be nit-picking these functions in regards to security, because simply using them does not make your program secure. You have to actually design for security, not just use strlcpy and believe somehow you have produced secure code. At the same time, just because someone has strcpy in their code, does not mean their code is not secure. So this whole discussion is pointless, is what i'm saying :)

clarry 13y ago
Yes it's pointless if people continue to miss the point regarding auditability, and the fact that harder-to-use functions that are also harder to audit are more like to end up used wrong. I realize that many out here don't care about auditability, and never spend hours systematically going through hundreds or thousands of invocations in other people's code, checking for correctness of exactly the kind of code that historically has caused lots of easy-to-exploit security problems. I realize that most people here would probably trust themselves to be able to use strcpy, strncpy, and strcat correctly; I would trust myself too. But that is not the point. With the right idioms, I make it easier for other people to verify the correctness of my code, so they don't need to depend on blind trust. And to be honest, it doesn't take a whole lot of "design" to use strlcat correctly; it is simple. Yes you can misuse it, but I would hold it very likely that most people who actually learn about it, check the manual, and decide to use it, are going to use it correctly.
- peterwwillis 13y ago
  > I would hold it very likely that most people who actually learn about it, check the manual, and decide to use it, are going to use it correctly. You don't think that's dangerous? If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly, you're going to miss the one or two times it's not, and end up with vulnerabilities. I haven't needed to audit code professionally, but when I do it personally, I don't look for common pitfalls in function use - I look for general scenarios that are dangerous, like working with potentially tainted data. So when I talk about design security, I don't mean what function you use, I mean how it fits into the broader scheme of what the application is trying to do.
  - clarry 13y ago
    > If your method of auditing code is skipping all the strlcpy's because you assume it's being used correctly That is not at all what I have said, how did you come up with that? I've been arguing that the idiomatic use of strlcpy is easier to audit than any use of strcpy. > I haven't needed to audit code professionally, but when I do it personally, I don't look for common pitfalls in function use - I look for general scenarios that are dangerous, like working with potentially tainted data. So when I talk about design security, I don't mean what function you use, I mean how it fits into the broader scheme of what the application is trying to do. What you're doing isn't wrong, but looking for common pitfalls is a very easy way to get a baseline assesment of code quality. You'd be surprised at the amount of problems you can find just by looking for arithmetic overflows near memory allocation, misuse of realloc, and the string handling functions. And if the search turns out lots of such problems, trying to understand the design and "broader scheme" is not very useful (at least for me, because at this point I would've decided the software in its current state is simply not good enough for me). There's another reason to look for common pitfalls: you have something very concrete to focus on. You can work mechanically. You can work with grep. It really does make a huge difference. And let's not forget: these common pitfalls are common. And commonly, they are exploitable. And they are the things many attackers would also initially look for. If you "just look" trying to find potential security issues in design or otherwise, but are not looking for anything very specific, you can't be anywhere near as focused, and it will take more time to usefully process the code. If it takes a lot of time, focus is going to get worse with the degrading attention span.. it'll be harder (at least for me) to be certain that the review has actually been thorough and has managed to flag things that need attention. Oh I do look at the broader design of software, but only after getting the low hanging fruit out of the way.