full-disclosure - Outlook "cid:" handling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <e92364c304101416191ab43ef4@mail.gmail.com>
From: jftucker at gmail.com (James Tucker)
Subject: Outlook "cid:" handling - Request for Information

Outline:
======
It has recently come to my attention that it is possible to circumvent
functions inside of Microsoft Outlook 2003 and some other MUA's by
using href tags containing "cid:". By default such MUAs no longer
download web referenced images and objects, however images referenced
by "cid:" strings are embedded (as attachments with special names)
within the e-mail.

Contrary to the policy of not downloading images, it would seem that
these are packaged with the mail (decentralised) AND are displayed
despite non-image download policies.

Some limited details of the "Compatible ID" processing in MS Outlook
is detailed by the vendor here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q270922

Request:
=======
If anyone knows of a configurations which can be set to disable ALL
image processing in affected MUAs such information would be very
valuable to me.

Potential Impact:
=============
It is true that many updates for the affected software groups (office,
windows) remove currently known vulnerabilities that could be
exploited using this method. New vulnerabilities of the nature we have
seen recently would be very easy to mass produce with decentralised
(non-server based) attacks utilising this method.

At this time there is no reason why this has not been used more
extensively (best I can tell support for this method has been
available for quite some time ( as early as 2001 and possibly much
longer )).

During the early days of the recent jpeg GDI exploit I am surprised
this method of infection was not further abused. Spread of such a
thing would have been rapid, as the "user stupidity" requirement for
infection is near eradicated when using this method. The only savior
would have been in the AV companies rapid deployment of a pattern to
match infected images.