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-prev] [day] [month] [year] [list]
Message-ID: <200309262038.h8QKcNI31094@gator.earlhood.com>
Date: Fri, 26 Sep 2003 15:38:22 -0500
From: Earl Hood <earl@...lhood.com>
To: bugtraq@...urityfocus.com
Subject: Re: base64



Those following this thread may be interested in checking out RFC
3548: <http://www.faqs.org/rfcs/rfc3548.html>.  It appears to address
some of the concerns raised in this thread and what the recommended
practices are.

It is worth noting the RFC 2045 states that decoders *must* ignore
invalid characters when decoding.  However, I believe RFC 2045 is
ambiguous about '='.  If it appears in the middle of input stream,
it could imply end-of-data or an invalid character if you take the
approach that '=' is only a valid base64 character at the end of
encoded data.

The following is written in the Security Considerations of
RFC 3548:

   When implementing Base encoding and decoding, care should be taken
   not to introduce vulnerabilities to buffer overflow attacks, or
   other attacks on the implementation.  A decoder should not break
   on invalid input including, e.g., embedded NUL characters (ASCII 0).

   If non-alphabet characters are ignored, instead of causing rejection
   of the entire encoding (as recommended), a covert channel that can
   be used to "leak" information is made possible.  The implications
   of this should be understood in applications that do not follow
   the recommended practice.

--ewh


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ