<<< Date Index >>>     <<< Thread Index >>>

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