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-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Sep 2003 12:18:31 -0400 (EDT)
From: Birl <sbirl@...ple.edu>
To: BugTraq@...urityfocus.com
Subject: Re: base64

As it was written on Sep 22, thus "Ilya Teterin"  typed:

alienhard:  Consider we decoding data which contains padding character
alienhard:  ('=') at the unexpected place. What we should do with such
alienhard:  data? The specification of base64 decoding does not tell us
alienhard:  what we MUST or even MAY do with such data... So, we can do
alienhard:  anything we like to do:
alienhard:
alienhard:  1. threat padding character as end of the encoded data
alienhard:  2. ignore padding character
alienhard:  3. decode padding character as well as some other character from base64 alphabet
alienhard:  4. do something else ;-)
alienhard:
alienhard:  I have tested some popular implementations (such as email
alienhard:  clients, GNU utilities, RTL and other development's
alienhard:  libraries). All items (1)-(4) are actually present.
alienhard:
alienhard:  Is it dangerous? Sure. Consider antiviral software, which
alienhard:  implements behaviour (1), and e-mail client, which implements
alienhard:  behaviour (2). Attacker can insert padding character in the
alienhard:  beginning of the encoded data, and antiviral software will
alienhard:  think encoded data is empty. But e-mail client will think
alienhard:  differentother way ;-) So, bypassing of content-filtering and
alienhard:  antiviral protection is obvious subject for this issue.
alienhard:
alienhard:  How to solve this issue? I believe we should rewrite at least
alienhard:  filtering systems to block malformed base64-encoded data
alienhard:  because we don't know is it malicious or not. Otherwise, we
alienhard:  can meet new powerful e-mail worm.
alienhard:
alienhard:  -----
alienhard:  "Will research information security for food!"

Excuse my ignorance.  I tried to pook around some B64 attachements in my
email files for an answer.

Are you stating that an =

1) should not appear in B64 at all
2) should not appear in the middle of a line, but only at the EOLN
3) should only appear at the end of a B64 file

Answering that question could help me better determine how to write a
procmail filter for this.

Next question:  Does the = actually corrupt an attachment, assuming it's a
                legimate B64 file, or does the decode still succeed?

Thanks
Birl