Assume program under constant attack

[Tomás Ó hÉilidhe]

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"?

 

[CBFalconer]

.... snip ...

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"?

If they don't check, someone or thing will break.

 

[Jack Klein]

....absolutely nothing at all about the C language.

I'd suggest you look for a group where this would be topical. Perhaps

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[ediebur]

    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"?

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

 

[JimS]

Tomás Ó hÉilidhe wrote:

When writing every line of code, do they be thinking in their
head "Someone wants to break this"?

Yes.

Jim

 

[Tomás Ó hÉilidhe]

Jack Klein:

...absolutely nothing at all about the C language.

Never written a C program?

 

[Randy Howard]

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"?

Pretty much, they either do, or they get burned. There is a good book
that gives some insight into some of this, sort of from the "black hat"
perspective.

It's called "The Shellcoder's Handbook". If you aren't upon on the
slang, you might think that has something to do with shell scripting.
Not true at all. See if your bookstore has a copy and take a peek and
see if it's what you're looking for.

 

[Syren Baran]

When writing
every line of code, do they be thinking in their head "Someone wants to
break this"?

Oehm? Is there a other way?
Last time i wrote a webserver it was too simple anyway. Attacks against
web servers can generally be grouped into buffer overflow and directory
traversal attacks.
Buffer overflow=> (in java) ArrayIndexOutOfBoundsException => not even a
DOS attack
Directory traversal => foolproof URLDecoder+explicit declaration of
directories and files to be served => yawn

To provide at least some on topic information. Once the input has been
verified by the network layer further array checks are redundant (yeah,
well maybe if its a project with several people one might want to check
again, just in case, in the core).
As a side node i might add that servers in the windows world probably
havent heard nearly as much about robust coding, since i dont know of
any protocoll firewalls on linux.