Re[2]: OT: Re: Secure popen

From: Barclay Osborn (barclayat_private)
Date: Tue Jun 26 2001 - 10:02:50 PDT

  • Next message: Devdas Bhagat: "Re: Principle of Inclusion?"

    Even though this thread has gone on way to long ...
    
    On Mon, 25 Jun 2001 02:58:45 -0700 Ben Ford <Ben Ford <bfordat_private>> wrote:
    > >>lots of people, especially beginners just happen to write CGI programs in
    > >>perl and since they are not yet capable programmers, they write insecure
    > >>code.  beginners don't write CGI programs in C++ because it is outside the
    > >>capability of beginners to do so.  a skilled programmer will write quality
    > >>code with either language.
    >
    > <snip comment>
    > You are saying that Perl is insecure because it is easier to write for 
    > and there are more newbies using it . . .
    
    No!  I believe Glenn's comment was *not* saying perl is insecure, but that
    there exist a large supply of vulnerable programs due to the ease of
    learning perl and the number of people that do end up starting with it.
     
    > . . . so why don't these newbies ever learn?  
    
    Who says they don't?  But who says they go back and fix all their old
    buggy code they previously released?
    
    > If Perl is easier, it should be easier to master, right?  
    
    I think it's naive to assume that learning curves are linear.
    
    > And if you've mastered the language, you should be able to program
    > securely, right?  
    
    Not if you're not thinking about security.
    
    > So if Perl is easier to learn, then it should be more secure.  However . . .
    
    http://everything2.com/index.pl?node=Logical+Fallacy
    
    > . . . C is harder to learn, so it stands to reason that more people will 
    > make mistakes writing it, and therefore pump out insecure programs by 
    > the bushel.  But not compared to Perl!
    
    This (referring to the "harder to learn" and "not compared to") is
    difficult to quantify when taking into account each language's life
    span, architectural span, typing, scoping, standard usage, general
    integratration, types of problems each lend themselves to, etc.  Since
    it's unquantified even with the rawest of numbers (as of yet), I'll
    ignore it.
    
    There's a big difference between language and programmer.  While one may
    argue that a given language "promotes" one behavior or another on the
    part of the programmer, or likewise "discourages" some other behavior,
    the onus is still on the programmer.  The quality of the programmer
    shouldn't be used as the sole judge of the language, if judging the
    language.  And, the quality of the language shouldn't be used as the
    sole judge of the programmer, if judging the programmer.  Yes, the two
    are inter-related and will certainly affect the evolution of each other,
    but they shouldn't be confused.
    
    That said, I do agree that some PL's help the programmer write more
    securely, but more for their immediate properties, not what they
    reflect.  E.g., throw Ada into Crispin's typing discussion, and you've
    got something very resistant to type mismatches.  Hell, it's even
    difficult to purposely make it marshal data between between types
    (compartively speaking).  Move more runtime checking (type, bounds) into
    the PL and you get more resilency.  Use well defined and enforced name
    spaces.  Lexical OR dynamic scoping.  Narrow, well-defined interfaces. 
    As I believe someone else pointed out, using OOB signalling in a PL can
    improve security - control can't be confused for data and vice versa. 
    That's all off the top of my head right now....
    
    > Since real life is not what is shown by a simple logics experiment, 
    > there must be other factors that are not taken into account.  Namely, 
    > that Perl is cheesecloth when it comes to security.
    > 
    > -b
    
    I think you're trying to justify your conclusion, not conclude with
    justification. 
    
    -Barclay
    



    This archive was generated by hypermail 2b30 : Thu Jun 28 2001 - 09:09:32 PDT