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

Message-ID: <200309230052.h8N0qQLK043440@mailserver2.hushmail.com>
Date: Mon, 22 Sep 2003 17:52:25 -0700
From: <latte@...hmail.com>
To: alienhard@...l.ru, bugtraq@...urityfocus.com
Subject: RE: base64

What about this section:

" Because it is used only for padding at the end of the data, the
occurrence of any '=' characters may be taken as evidence that the
end of the data has been reached (without truncation in transit).  No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three. "

From: http://www.ietf.org/rfc/rfc1521.txt?number=1521

Seems to suggest that it should be treated as the end of
input.

-----Original Message-----
From: "Ilya Teterin" [mailto:alienhard@...l.ru]
Sent: Monday, 22 September 2003 10:50 PM
To: bugtraq@...urityfocus.com
Subject: base64

Consider we decoding data which contains padding character ('=') at the
unexpected place. What we should do with such data? The specification
of base64 decoding does not tell us what we MUST or even MAY do with
such data... So, we can do anything we like to do:

1. threat padding character as end of the encoded data
2. ignore padding character
3. decode padding character as well as some other character from base64
alphabet
4. do something else ;-)

I have tested some popular implementations (such as email clients, GNU
utilities, RTL and other development's libraries). All items (1)-(4)
are actually present.

Is it dangerous? Sure. Consider antiviral software, which implements
behaviour (1), and e-mail client, which implements behaviour (2). Attacker
can insert padding character in the beginning of the encoded data, and
antiviral software will think encoded data is empty. But e-mail client
will think differentother way ;-) So, bypassing of content-filtering
and antiviral protection is obvious subject for this issue.

How to solve this issue? I believe we should rewrite at least filtering
systems to block malformed base64-encoded data because we don't know
is it malicious or not. Otherwise, we can meet new powerful e-mail worm.

-----
"Will research information security for food!"

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427