Hi @ll,

this is basically a followup to <http://seclists.org/oss-sec/2016/q1/58>

CVE-2016-1281 is NOT FIXED!

I've retested the current "VeraCrypt Setup 1.17.exe" on a fully
patched Windows 7, and it is STILL (or AGAIN) vulnerable there.

The following DLLs are loaded from the "application directory"
and their DllMain() executed: VSSAPI.dll, ATL.dll, VSSTrace.dll.

See <https://cwe.mitre.org/data/definitions/426.html>,
<https://cwe.mitre.org/data/definitions/427.html> and
<https://capec.mitre.org/data/definitions/471.html> for details
about this well-known and well-documented beginner's error!

Due to the application manifest embedded in the executable installer
which specifies "requireAdministrator" the installer is run with
administrative privileges ("protected" administrators are prompted
for consent, unprivileged standard users are prompted for an
administrator password); execution of the DLLs therefore results
in an escalation of privilege!

For software downloaded with a web browser the "application
directory" is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for prior
art!


Mitigation:
~~~~~~~~~~~

DUMP executable installers, build packages for the target OS' native
installer instead!

See <http://home.arcor.de/skanthak/!execute.html>
as well as <http://home.arcor.de/skanthak/sentinel.html> for the long
sad story of these vulnerabilities.


stay tuned
Stefan Kanthak


Timeline:
~~~~~~~~~

2015-12-23    vulnerability report sent to author

2016-01-03    author confirmed vulnerability, got CVE-2016-1281

              worked with author until he finally was able to build
              an installer which didn't show this vulnerability.

              Also notified author:
              "as soon as Microsoft introduces new/other dependencies
               between Windows' system DLLs or refactors them (again)
               this vulnerability will VERY likely resurface again."

2016-01-11    report published by author (see above)

2016-07-01    vulnerability report sent to author ("I told you so!")

              NO RESPONSE

2016-07-17    report published