RE: [Full-Disclosure] Coding securely, was Linux (in)security

From: Paul Schmehl (pauls_at_utdallas.edu)
Date: 10/27/03

  • Next message: Chris Eagle: "RE: [Full-Disclosure] Coding securely, was Linux (in)security" 
    To: full-disclosure@lists.netsys.com
Date: Sun, 26 Oct 2003 22:09:47 -0600

    --On Sunday, October 26, 2003 7:25 PM -0800 Chris Eagle
    <cseagle@redshift.com> wrote:
    >
    > That is the most backward thing I have ever heard. So you are saying all
    > I need to do as a programmer is tell you not to pass a negative
    > number/null pointer/un-initialized value... to my function and I am off
    > the hook. All I can say is that I am glad utdallas doesn't have you
    > teaching programming. The fact that you are unaware what lies inside the
    > black box in no way relieves the responsibility of the designer of the
    > black box to make sure that it behaves predictably under all input cases.
    >
    No, that is not what I'm saying. What I'm saying is that the programmer
    should not *expect* the subroutine to do his error checking for him. If
    *everyone* wrote code that way, including the writer of the subroutine, we
    wouldn't have the problems we have with buffer overflows.

    The problem we have now is everyone is expecting someone *else* to do the
    error checking, when in fact everyone should be expecting exactly the
    opposite.

    However, what you are expecting the writer of the subroutine to do is
    anticipate every possible input, and that may not be possible in all cases.
    Certainly the writer should do error checking, but that doesn't alleviate
    the *user* of the subroutine from doing their job.

    Paul Schmehl (pauls@utdallas.edu)
    Adjunct Information Security Officer
    The University of Texas at Dallas
    AVIEN Founding Member
    http://www.utdallas.edu

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Chris Eagle: "RE: [Full-Disclosure] Coding securely, was Linux (in)security"

    Relevant Pages

    • Re: VB .NET OOP
      ... So, my point is, Ed, that it being a subroutine wasn't possible ... transparent moniker, Programmer Dude, because during my job ... including my personal email. ... > That may very well be because others here are police agents and ...
      (comp.programming)
    • Re: Randy vs. Betov: from an outsider
      ... I may be wrong, but, if i am wrong, i will be proven wrong by what i am doing, not by what the other are saying. ... "function points" or "measuring programmer productivity". ... this specifically covers measuring programmer productivity and program defects between assembler and high level programming. ...
      (alt.lang.asm)
    • Re: Linux / Windows GUI application with assembly
      ... consumes 99% of the computing power and a programmer gets the task to ... programmer, he will look what this subroutine does, take the processor ...
      (alt.lang.asm)
    • Re: Delphi in more schools (was Microsoft here I come)
      ... for a C programmer than for a Delphi programmer, ... You certainly missed the point of what I was saying. ... (there is only the real world, BTW). ... At least in this area of the world, Delphi has no place in a schooling ...
      (borland.public.delphi.non-technical)
    • RE: [Full-Disclosure] Coding securely, was Linux (in)security
      ... > So you're saying I don't need to worry if a file pointer is NULL before ... So I don't need to worry if an argument ... subroutine should NEVER assume that the caller has checked. ...
      (Full-Disclosure)
    • Quantcast