* 32-bit x86 running on 64-bit x86 Windows needs to get SKUSiPolicy.p7b from sysnative.
* Also fix automatic extension switching in file dialog and a small MinGW warning in Bled.
* This adds ZIP64 support, which is required to extract zip archives that are larger than 4GB.
* Closes#2264
* Also fix a MinGW warning in pki.c and improve the UEFI revocation messages.
* Remove duplicates from Microsoft's SKUSiPolicy.p7b
* Also display the number of revoked from embedded
* Also use Microsoft's official capitalization for SKUSiPolicy.p7b's target path
* Instead of embedding the content of the most recent revoked bootloader hashes in db.h
we now parse the system's SkuSiPolicy.p7b to do so. This has the drawback of not alerting
users running Rufus on systems where SkuSiPolicy.p7b is not up to date, but I believe the
trade-off is worth it.
* We now also copy the system's SkuSiPolicy.p7b to the created media when possible (for
Windows 10 or later), so that Microsoft's WDAC UEFI revocations can apply during boot.
* This reverts much of commits f6ac559f4d and 1947266837
so that we call the Windows APIs directly again, while ensuring that, by the time we load the DLLs,
sideloading mitigation has already been applied by the application.
* This is a continuation of #1877, and should help prevent re-introducing side-loading issues when we
link against new libraries, as well as allow us to drop some of the manual DLL hooking we've been
doing to prevent it, to clean up the code.
* Note that this is a bit more complex than what the stackoverflow post suggests, because we need to
create delayloaded libs for both 32-bit and 64-bit, which use a different calling convention and
therefore need to use different .def files. So there's a lot of gymkhana involved, with Makefiles
and whatnot, to get us there.
* Also simplify the use of CM_Get_DevNode_Registry_PropertyA() in dev.c since recent versions of
MinGW now have support for it.
* Also fix 2 small issues in net.c (potential overflow) and format.c (memory leak).
* WinTrust.lib is responsible for the MSASN1.dll sideloading issue described in #1877,
so, since we only use it for WinVerifyTrustEx(), hook into that function manually.
* Closes#1877 for the MinGW side.
* Note that we will probably try to use the method suggested by @assarbad and documented at
https://stackoverflow.com/questions/1851267/mingw-gcc-delay-loaded-dll-equivalent/70416894#70416894
to try to put an end to the problem of DLL side loading.
* This basically means that the script is validate *TWICE*, using two
completely independent signatures, before it is allowed to run, which
should add another mitigation layer against TOCTOU (which we already
friggin' mitigated against anyway) and other potential vectors of
attack.
* Also remove -DisableFirstRunCustomize option and the associated cookie
prompt monitoring, which the latest version of Fido no longer requires.
* Also update WDK version for signtool and flesh out PKI error messages.
* Also disable Launch button while we do so
* Also add new <Ctrl>-<Alt>-<Y> cheat mode
* Also terminate update thread before exiting if running
* Also set version to rufus-next
* *THIS* is what you need to do to replace Microsoft's broken SetDllDirectory("")
implementation and mitigate DLL sideloading from local directories.
* Also fix some comment typos
* Also add a retry in PKI's GetSignatureName()
* This should help with getting a "The downloaded executable is
missing a digital signature" message when launching an update.
* Closes#1130
* Add timestamp processing for nested signature and check for anomalous differences
* Also prevent attack scenarios that may attempt to leverage multiple nested signatures or countersigners
* Simplify code by using CryptDecodeObjectEx/WinVerifyTrustEx and improve timestamp reporting
* This commit effectively fixes https://www.kb.cert.org/vuls/id/403768 (CVE-2017-13083) as
it is described per its revision 11, which is the latest revision at the time of this commit,
by disabling Windows prompts, enacted during signature validation, that allow the user to
bypass the intended signature verification checks.
* It needs to be pointed out that the vulnerability ("allow(ing) the use of a self-signed
certificate"), which relies on the end-user actively ignoring a Windows prompt that tells
them that the update failed the signature validation whilst also advising against running it,
is being fully addressed, even as the update protocol remains HTTP.
* It also need to be pointed out that the extended delay (48 hours) between the time the
vulnerability was reported and the moment it is fixed in our codebase has to do with
the fact that the reporter chose to deviate from standard security practices by not
disclosing the details of the vulnerability with us, be it publicly or privately,
before creating the cert.org report. The only advance notification we received was a
generic note about the use of HTTP vs HTTPS, which, as have established, is not
immediately relevant to addressing the reported vulnerability.
* Closes#1009
* Note: The other vulnerability scenario described towards the end of #1009, which
doesn't have to do with the "lack of CA checking", will be addressed separately.
* MSG_002 doesn't display in RTL
* Update Policy dialog loses RTL setting after the first paragraph
* Some text displayed in native Windows message boxes is not using RTL
(even as the Message Box itself will display the rest of the UI elements as RTL)
* Detect if the relevant language pack is installed and use MessageBoxEx to
display native message box buttons using the selected language.
* All theses issues are part of #621
* Also remove trailing whitespaces
Pete Batard