RE: Update: Web browsers - a mini-farce (MSIE gives in)

From: Michael Wojcik (Michael.Wojcik_at_microfocus.com)
Date: 10/28/04

  • Next message: Martin Pitt: "[USN-4-1] Standard C library script vulnerabilities" 
    To: Valdis.Kletnieks@vt.edu
Date: Thu, 28 Oct 2004 12:09:22 -0700

    > From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
    > Sent: Thursday, 28 October, 2004 14:23
    >
    > On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:
    >
    > > You don't have to understand how to exploit a buffer overflow in
    > > order to avoid overflowing buffers.
    >
    > But you have to think of a buffer being overflowed to check for
    > it.

    Anyone who doesn't understand that a finite-size container cannot hold more
    than what it can hold is unlikely to manage to write software.

    > > You don't have to understand SQL code-injection
    > > attacks to restrict SQL input fields to valid characters.
    >
    > But you have to realize that SQL can be fed invalid
    > characters to check for it.

    No, you don't. It's enough to have a specification (that is, a contract)
    which says that input X must contain data that meets certain criteria. From
    that, the careful programmer will write a validation routine that rejects
    input which fails to meet that criteria. It doesn't matter whether the
    programmer has any understanding of SQL at all, much less what it may do
    with its input. It suffices to know that the program specification imposes
    requirements on the input.

    > > You don't have to understand cross-site scripting by embedded
    > > HTML to strip or sanitize HTML tags from user-supplied input
    > > that shouldn't have them.
    >
    > But you need to know which tags are safe and why, in order to
    > strip or sanitize it correctly.

    No you don't. You just have to sanitize the input. The HTML specification
    says that certain characters have special meaning and must be replaced with
    character entities in ordinary text. If the program is producing output
    that's supposed to be ordinary text, for consumption by an HTML agent, it
    must perform those replacements. End of story. There's no need whatsoever
    for the person writing that code to know anything more about HTML than which
    characters need to be replaced, and with what. In fact, even that's
    unnecessary, because the specification for the program should note that
    those characters need to be replaced; the programmer can remain entirely
    ignorant of HTML.

    > > You don't need to understand how signed-integer overflow could
    > > cause a problem to check for it.
    >
    > But you need to understand it *can* be a problem to check for it..

    See "finite-size container" above. I prefer to use code not written by
    idiots.

    > But you need to understand at least the basics of THAT one to
    > check for it, too...
    >
    > Puzzled by what goes there? Good. So am I - *neither* of us
    > thought of it.

    Now it's *invisible* straw men.

    > And that's the point - whatever goes in that blank space was
    > certainly just as big a problem as SQL injection or integer
    > overflows or double-frees.

    Really? I find it hard to be certain about imaginary entities, myself.

    > But we're both only human, and we'll look silly when the advisory
    > hits BugTraq or Full-Disclosure, and everybody will say "Look at
    > that, yet another dumb-ass programmer that didn't know enough to
    > check for *THAT*".

    Ah, so this really boils down to "if we can't expect programmers to
    anticipate all bugs, we can't expect them to anticipate any".

    If you can't see where the fallacy is in *that*, then I don't see much point
    in continuing this discussion.

    I'm really not interested in excuses for programmers who fail to demonstrate
    even a little discipline in their work. And that's precisely what Mangleme
    has shown. 

    -- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus
  • Next message: Martin Pitt: "[USN-4-1] Standard C library script vulnerabilities"

    Relevant Pages

    • Re: Unchecked Buffer
      ... If you are referring to the "Buffer Overflow" inherently common in many ... is an array of characters in memory that ends with the first NULL byte. ... where Windows allows a VIRUS can inject itself in the stack stack and the ...
      (microsoft.public.security)
    • Re: C-programmer needs Forth advice
      ... > I am a C and assembly programmer, so I think in variables and ... > buffer, and returns the number of characters read. ... > int read ...
      (comp.lang.forth)
    • Re: _sntprintf and _sntprintf_s
      ... I think in this case number of characters means TCHAR's, ... keep track of how much space remains in the buffer. ... If a programmer is using the ANSI version then the programmer wants to do ... calculations on the number of bytes in order to keep track of how much ...
      (microsoft.public.vc.language)
    • Re: Ancient history
      ... this environments... ... they involve exclusive assembler implementation. ... with explicit buffer lengths as part of the normal infrastructure ... ... programmer to manage buffer lengths). ...
      (sci.crypt)
    • Re: Calling unauthorized code from an authorized address space
      ... Prior to passing the buffer to a work queue for the SRB, ... possibility that the user (which can be a normal programmer) will need to ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
      (bit.listserv.ibm-main)