full-disclosure - Flaws in the new security functions of SP2

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]

From: ju at heisec.de (Juergen Schmidt)
Subject: Flaws in the new security functions of SP2 - revisited

A couple of days I posted an advisory about flaws in a new
security functions of Service Pack 2 (for details, see:
http://www.heise.de/security/artikel/50051). Now I would
like to share some additional information which has been
found out in conjunction with Sven Ritter, a German
developer.

1) The Windows Explorer caching issue

We gave a second look at the issue reported previously that
Windows Explorer under certain conditions launches files
using outdated Zone ID information from a system cache.
Further inspection reveals that this does not only affect
Explorer but any software which launches applications or
scripts using the ShellExecuteEx function supplied by
Windows.

The Internet Security Manager is in charge of determining
the zone of a file (CLSID_InternetSecurityManager). This
object contains a cache (CSecurityManager::CSecMgrCache)
which stores zones which have been determined previously.
When the function is called again, the method
CSecurityManager::MapUrlToZoneInternal will first check
whether there is a cached request for the corresponding file
or URL. If there is cached information, the method will
return the previously determined zone -- even if the file's
Zone ID has changed in the meantime. Since the Internet
Security Manager is loaded as a COM object into the current
process, the cache is local to that process. This explains
why the problem can be "alleviated" by restarting Windows
Explorer.

It appears that the cache size is limited to four entries.
If four files with different names are launched after the
start of application XY, the function will recognize the
changed Zone ID of application XY.

2) Other Execution Paths

The previous advisory showed how cmd.exe completely ignores
Zone IDs. Further tests revealed other execution paths which
circumvent checks contained in SP2.

Refresher: When downloading files through Internet Explorer
and Windows Messenger or saving attachments transferred
Outlook Express, the file is given a Zone ID saved in an
Alternative Data Stream. When a downloaded application or
script is launched, Windows displays a security warning
which alerts the user to the fact that this file has been
downloaded from the Internet and that it could be dangerous.

If you extract files from a ZIP archive which has been
downloaded from the Internet using XP's built-in ZIP Wizard
(using File/Extract all), SP2 sets the Zone ID for the
extracted files. However, if the ZIP archive is opened with
a double-click and an executable file is extracted by Drag &
Drop to the desktop or using Copy & Paste, no Zone ID is
set.

Additionally Zone IDs are not set on files marked as
Read-only -- even when using the Wizard. If the
downloaded archive evil.zip contains evil1.exe (attrib
-R) and evil2.exe (attrib +R) and you extract them with
the Wizard into the folder evil, opening evil1 gives
you a warning, opening evil2 not.

bye, ju

-- 
Juergen Schmidt    Chefredakteur  heise Security   www.heisec.de
Heise Zeitschriften Verlag,  Helstorferstr. 7,  D-30625 Hannover
Tel. +49 511 5352 300 FAX +49 511 5352 417    EMail ju@...sec.de