OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Tod Harter (tharteraptusventures.com)
Date: Wed Mar 27 2002 - 11:21:50 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    I think its fair to say that a mod_perl developer (for example) in theory
    cannot CREATE a BO vuln. On the other hand, you can certainly make it a lot
    harder for some of them to be exploited. It is a reasonable philosophy to
    ASSUME that any C library you might use could be vulnerable and thus check
    all your input data before you make calls to perl packages that rely on
    binary code. Likewise though I would say it is good practice for not only the
    authors of the underlying C code to check inputs, but a good argument could
    be made that "glue" code shouldn't be passing bad args either, so there are a
    lot of levels where BO attacks can be stopped when you are in something like
    perl.

    The web server itself just plain better be secure though. Nothing in web app
    coding is ever going to save you from bad web server code.

    On Monday 25 March 2002 22:19, Christopher Todd wrote:
    > >assuming your webserver is coded perfectly w/ no
    > >BOs....and all the mods that allow for different
    > >webApp langs to work are also coded
    > >correctly.....then as I understand it the only way to BO
    > >code would be if the CGIs were written in C/C++.
    > >
    > >Any webApps written in PHP/ASP(jscript,C#)/JSP
    > >would have features in the langs themselves that
    > >prevent one from assigning a static mem buffers.
    >
    > In the context of coding up web applications, yes, the classic
    > "smashing the stack for fun and profit" buffer overflows are only
    > possible if your CGIs are written in C/C++ (probably - never say
    > never in security :). Most of the languages used for web application
    > development nowadays (Java, Perl, PHP, Python, VBScript, etc.) are
    > interpreted languages in which the interpreter handles all the memory
    > allocation, thus preventing the programmer from shooting themselves
    > in the foot with unchecked buffers. Which is not to say that
    > developers using those languages have no ammo, mind you...
    >
    > >excuse my ignorance...as I don't know enough about
    > >BOs as I should
    >
    > For some fun background reading on BOs, you can check out Phrack 49:
    > http://phrack.org/show.php?p=49&a=14
    >
    > Regards,
    > Chris