* 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
