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?
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
[ reply ]