...
|
...
|
@@ -5705,8 +5705,15 @@ int cli_checkfp_pe(cli_ctx *ctx, uint8_t *authsha1, stats_section_t *hashes, uin
|
5705
|
5705
|
}
|
5706
|
5706
|
|
5707
|
5707
|
if (EC32(cert_hdr.length) != hlen) {
|
5708
|
|
- cli_dbgmsg("cli_checkfp_pe: unexpected authenticode data length\n");
|
5709
|
|
- return CL_VIRUS;
|
|
5708
|
+ /* This is the case that MS13-098 aimed to address, but it got
|
|
5709
|
+ * pushback to where the fix (not allowing additional, non-zero
|
|
5710
|
+ * bytes in the security directory) is now opt-in via a registry
|
|
5711
|
+ * key. Given that most machines will treat these binaries as
|
|
5712
|
+ * valid, we'll still parse the signature and just trust that
|
|
5713
|
+ * our whitelist signatures are tailored enough to where any
|
|
5714
|
+ * instances of this are reasonable (for instance, I saw one
|
|
5715
|
+ * binary that appeared to use this to embed a license key.) */
|
|
5716
|
+ cli_dbgmsg("cli_checkfp_pe: MS13-098 violation detected, but continuing on to verify certificate\n");
|
5710
|
5717
|
}
|
5711
|
5718
|
|
5712
|
5719
|
at = EC32(dirs[4].VirtualAddress) + sizeof(cert_hdr);
|