On Jan 19, 6:43*am, "Tomás Ó hÉilidhe" <t...@lavabit.comwrote:
Quote:
* * Usually someone writes a program and guarantees its behaviour so
long as people don't deliberately go and try to make it malfunction.
>
* * For instance, let's say we have a "Proceed" button on the dialog
box, but that this button is greyed out because the user hasn't entered
their username yet. Now let's say the user writes some code that sends a
message to the dialog box to enable the "Proceed" button even tho the
programmer didn't design the program to work correctly if "Proceed" is
clicked without there being a valid username.
>
* * So anyway, the user clicks "Proceed", the program crashes. The user
complains to the author and the author just replies "If you're gonna do
stuff like that then you can expect the thing to crash".
>
* * But what if you were writing programs which were expected to be
under constant attack? One such genre of programs would be a network
daemon. Let's say we've written a network daemon for FTP. On the other
side of the world, a hacker sends a dodgy FTP request which leads to a
buffer overflow. Presumably the hacker has the exectuable file himself
for this daemon and has observed what will happen when the buffer
overflow occurs, and tailors his input to arrange the machine code to do
exactly what he wants, e.g. call a function which will bring up a
command prompt shell for him.
>
* * I've read a bit about many of the exploits against Microsoft's
daemons, and a lot of them tend to be as a consequence of buffer
overrun. There was one such well-known buffer overrun in their file-
sharing daemon that allowed a hacker to bring up a command prompt shell
on their own machine and basically do whatever they wanted from there.
>
* * But anyway... back to programming...
>
* * I'm wondering what way people program the daemon functions which are
the interface to the outside world. Do they check every little detail of
the input scrutinously? Do they check string lengths and array indices
scrutinously? What kind of things do they watch out for? When writing
every line of code, do they be thinking in their head "Someone wants to
break this"?
>
--
Tomás Ó hÉilidhe
Check everything and, at least thru Beta make sure every error
condition is reported, I once had to according to strict NSA code
constraints we weren't allowed to use recursion--there was a check at
the entry and exit of each function to insure that the function had
only been entered and exited once.That being said, this is for a
different group
