4 ms·

>Could I sit down and write a web-facing server from scratch and have a reasonable expectation of safety? Probably not. This is very suprising to me that peopl

>Could I sit down and write a web-facing server from scratch and have a reasonable expectation of safety? Probably not. This is very suprising to me that people think this. I am not a fantastic programmer, but I don't see writing safe code diffucly at all, you just have to understand the basics how attacks work, and follow some basic rules when writing code. In order for a piece of software to be exploitable, you need to have an input channel that is not isolated from the functionality- something like taking the parameters in the url and passing it directly to a shell is a massive failure in isolation. As long as you do proper input sanitation, where the input must have certain format, and certain length for each part, and certain formatting for each part, the attack surface goes down to an absolute minimum. For example, for all the C/C++ code that I have seen that deals with web, only once I remember seeing a check on characters in the passed data being in the set of [0x10, 0x13, 0x20-0x7e], which should be the first check performed on any HTTP data passed to it, even before you start invalidating HTTP characters. As far as memory safety goes, never rely on null terminated strings, allways copy the exact amount of data to a statically defined max, and make the buffer that holds data have the length max+1 with an extra byte that is allways set to null for every copy into the buffer. For malloc/free, design your code so that malloc and free are in the same function at the beggining and end, and allways run memcheck and valgrind before deploying to production. Between all the other mechanisms in place, like non executable stack/heap, stack canaries, ASLR, and the tools like memcheck and valgrind, the possibility of you making an exploitable software is as low as coding it in a "proven safe" language (if such a thing exists) and messing up some parser input that can lead to unexpected behavior. And of course, there is still the possibility of using a library that has an exploit, or coding in an exploit in higher level logic, but that is a danger for any language. I would bet that if taking an exploitation class for CS degrees was a hard requirement, where people understood the concept of stack, heap, and how the different types of exploits work, the outlook on this would change. I also wonder if teaching people C++ instead of C, and relying on built in memory management mechanisms to build software instead of making them manually write all the allocations by hand has an effect of a less understanding on what goes on under the hood.

Nursie 6y ago
> In order for a piece of software to be exploitable, you need to have an input channel that is not isolated from the functionality And prove that your input validation is correct for every possible value, and that under stress the system doesn't start doing something weird, and there are no possible integer overflows that might cause something funny to happen and ... > For example, for all the C/C++ code that I have seen that deals with web, only once I remember seeing a check on characters in the passed data being in the set of [0x10, 0x13, 0x20-0x7e], which should be the first check performed on any HTTP data passed to it Unless it's unicode of course, which it really should be these days if we're talking about the web, and when really you want a unicode parsing library to validate, and then you're reliant on that having no exploits, and anything of any significant complexity usually turns out to have some somewhere. > "Between all the other mechanisms in place, like non executable stack/heap, stack canaries, ASLR, and the tools like memcheck and valgrind, the possibility of you making an exploitable software is as low as coding it in a "proven safe" language" This is provably false though, and that's part of the point of the article, even well looked-after software written by experienced people with an eye on security suffers from problems, and with unsafe languages there are classes of attack that are just not possible with safer languages. These keep on happening regardless of the apparent skill level of the practitioner. The author has been doing it for 25 years and doesn't think they could do it reliably. I was a C programmer for 15 and I agree, past a certain level of complexity it looks like there just are going to be errors of this sort somewhere in your code. Sure, programs written in 'safe' languages are not bug-free or exploit-free, but for public-facing, networked code they do seem to be better as they eliminate a huge number of damaging attack types straight off.
- ActorNightly 6y ago
  >And prove that your input validation is correct for every possible value You don't need to check against every single value, you just need to check formatting, length, and data ranges. For your integer overflow example, you made 2 mistakes already, first is that anything that is expected to be positive should be unsigned integer and secondly, when you parse the string, you fail to check against max integer value. >Unless it's unicode of course Then validate unicode, lol. All this stuff has defined rules. Furthermore you design your code not to support unicode, and then someone inputs a name in non ASCII, the request will be rejected, which is a much better issue to have security wise rather than blindly accepting any and all input without validation. >This is provably false though Based on what, an opinion of some programmers? Thats not really "proving" anything. If you want to make a statement that most programmers don't understand things like why you should never rely on strlen, Id probably agree. But Im not really concerned with distribution of skill within the modern programmers, I against the assumption that "you should not write stuff in C because its very hard to write safe C code".

Nursie 6y ago

> In order for a piece of software to be exploitable, you need to have an input channel that is not isolated from the functionality And prove that your input validation is correct for every possible value, and that under stress the system doesn't start doing something weird, and there are no possible integer overflows that might cause something funny to happen and ... > For example, for all the C/C++ code that I have seen that deals with web, only once I remember seeing a check on characters in the passed data being in the set of [0x10, 0x13, 0x20-0x7e], which should be the first check performed on any HTTP data passed to it Unless it's unicode of course, which it really should be these days if we're talking about the web, and when really you want a unicode parsing library to validate, and then you're reliant on that having no exploits, and anything of any significant complexity usually turns out to have some somewhere. > "Between all the other mechanisms in place, like non executable stack/heap, stack canaries, ASLR, and the tools like memcheck and valgrind, the possibility of you making an exploitable software is as low as coding it in a "proven safe" language" This is provably false though, and that's part of the point of the article, even well looked-after software written by experienced people with an eye on security suffers from problems, and with unsafe languages there are classes of attack that are just not possible with safer languages. These keep on happening regardless of the apparent skill level of the practitioner. The author has been doing it for 25 years and doesn't think they could do it reliably. I was a C programmer for 15 and I agree, past a certain level of complexity it looks like there just are going to be errors of this sort somewhere in your code. Sure, programs written in 'safe' languages are not bug-free or exploit-free, but for public-facing, networked code they do seem to be better as they eliminate a huge number of damaging attack types straight off.

ActorNightly 6y ago
>And prove that your input validation is correct for every possible value You don't need to check against every single value, you just need to check formatting, length, and data ranges. For your integer overflow example, you made 2 mistakes already, first is that anything that is expected to be positive should be unsigned integer and secondly, when you parse the string, you fail to check against max integer value. >Unless it's unicode of course Then validate unicode, lol. All this stuff has defined rules. Furthermore you design your code not to support unicode, and then someone inputs a name in non ASCII, the request will be rejected, which is a much better issue to have security wise rather than blindly accepting any and all input without validation. >This is provably false though Based on what, an opinion of some programmers? Thats not really "proving" anything. If you want to make a statement that most programmers don't understand things like why you should never rely on strlen, Id probably agree. But Im not really concerned with distribution of skill within the modern programmers, I against the assumption that "you should not write stuff in C because its very hard to write safe C code".