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]
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ