Buck Huppmann said: >"Be liberal in what you accept, and conservative in what you send." >-- jon >RFC-1122 (originates in RFC760) > >or was that wisdom for a different time? Funny you bring up that quote, as I've been thinking about it for a while now too. I think that's wisdom for a different time, at least security-wise. While anti-virus products seem to be the focus, "conflicting interpretation errors" apply to other kinds of software. Reports of these errors also seem to be increasing, or maybe it's just my own awareness. Think of how browsers render malformed HTML and web content differently, which can facilitate cross-site scripting attacks and increases the space of "bad content" that application programmers must watch out for. The Ptacek/Newsham paper on evading IDS, which is several years old, also deals with conflicting interpretation errors. If it is reasonable to have third-party products inject themselves between a "sender" and a "receiver" for the purposes of security, then "be conservative in what you accept, and reject (or at worst canonicalize) all else" seems to be the only way to reduce this apparently growing class of security issues. In the long term, some ways of partially moving in this direction would be to (1) remove ambiguity from standards documents and explicitly dictate how violations should be handled, and (2) release associated test suites along with standards documents. The world might be a nicer place if every new protocol came with a PROTOS-style vulnerability test suite to identify and get rid of the worst and most frequently occurring classes of bugs (as an example, buffer overflows in the "GET" command have affected dozens of implementations of both HTTP and FTP), as well as "expected" inconsistencies like the ones being discussed in this thread. - Steve
