bugtraq - Re: base64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200309262056.h8QKusjN015113@linus.mitre.org>
Date: Fri, 26 Sep 2003 16:56:54 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: Re: base64

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