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