Assume program under constant attack

Discussion in 'C Programming' started by Tomás Ó hÉilidhe, Jan 19, 2008.

  1. 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
     
    Tomás Ó hÉilidhe, Jan 19, 2008
    #1
    1. Advertising

  2. Tomás Ó hÉilidhe

    CBFalconer Guest

    Tomás Ó hÉilidhe wrote:
    >

    .... 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jan 19, 2008
    #2
    1. Advertising

  3. Tomás Ó hÉilidhe

    Jack Klein Guest

    Jack Klein, Jan 20, 2008
    #3
  4. Tomás Ó hÉilidhe

    Guest

    On Jan 19, 6:43 am, "Tomás Ó hÉilidhe" <> wrote:
    >     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
     
    , Jan 20, 2008
    #4
  5. Tomás Ó hÉilidhe

    JimS Guest

    On Sat, 19 Jan 2008 08:47:32 -0500, CBFalconer <>
    wrote:

    >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
     
    JimS, Jan 20, 2008
    #5
  6. Jack Klein:

    > On Sat, 19 Jan 2008 11:43:21 GMT, "Tomás Ó hÉilidhe" <>
    > wrote in comp.lang.c:
    >
    > ...absolutely nothing at all about the C language.




    Never written a C program?


    --
    Tomás Ó hÉilidhe
     
    Tomás Ó hÉilidhe, Jan 20, 2008
    #6
  7. Tomás Ó hÉilidhe

    Randy Howard Guest

    On Sat, 19 Jan 2008 05:43:21 -0600, Tomás Ó hÉilidhe wrote
    (in article <Xns9A2A773F3746Ctoelavabitcom@194.125.133.14>):

    > 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.



    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
     
    Randy Howard, Jan 20, 2008
    #7
  8. Tomás Ó hÉilidhe

    Syren Baran Guest

    Tomás Ó hÉilidhe schrieb:
    >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.
     
    Syren Baran, Jan 22, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    263
    Peter Pearson
    Jan 9, 2009
  2. Palestinians Under Attack

    , Jan 12, 2009, in forum: C Programming
    Replies:
    0
    Views:
    327
  3. Replies:
    0
    Views:
    282
  4. Josh Sharpe
    Replies:
    1
    Views:
    217
    Brian Candler
    Sep 21, 2010
  5. Steven D'Aprano
    Replies:
    9
    Views:
    167
    Michael Poeltl
    Feb 16, 2013
Loading...

Share This Page