Light

Episode #987 Quiz

Rethinking Revocation
Date: 2024-08-13 | Length: 2 hrs | Episode page at twit.tv

About this episode

Sitting Duck exploits misconfigured DNS delegation when domains remain pointed at shared cloud nameservers after zones are deleted, letting attackers re-register them and control web, mail, and TLS. Separately, a Microsoft RDL heap overflow enabled zero-click pre-auth RCE, AMD’s Sinkclose microcode flaw threatened boot security, and certificate revocation is shifting from OCSP back to CRLs.

Your name and email are stored only in your browser local storage for convenience. They are not retained server-side.

NameEmail

Question 1: In the 'Sitting Ducks' discussion, what specific precondition makes a domain vulnerable to takeover in a shared DNS cloud environment?

Question 1

In the 'Sitting Ducks' discussion, what specific precondition makes a domain vulnerable to takeover in a shared DNS cloud environment?

The domain's MX records were left unchanged when email hosting was moved elsewhere The domain's TLS certificate was renewed after its DNS records were migrated The domain's registrar still points to nameservers after the corresponding DNS zone was deleted The domain's zone file still contains a stale SOA record after the registrar is changed

Question 2: What attack capability did the 'MadLicense' RDL vulnerability provide according to the episode?

Question 2

What attack capability did the 'MadLicense' RDL vulnerability provide according to the episode?

A local information disclosure in the Windows licensing subsystem A post-authentication privilege escalation in the Windows Remote Desktop Gateway service A zero-day denial of service in the Windows Update service A pre-authentication remote code execution in the Windows Remote Desktop Licensing service

Question 3: What did the IOActive researchers identify as the mechanism behind AMD's Sinkclose flaw?

Question 3

What did the IOActive researchers identify as the mechanism behind AMD's Sinkclose flaw?

An obscure TClose remapping feature that can misdirect SMM code into attacker-tampered memory A failure in UEFI variable authentication that bypasses Secure Boot policy checks A broken micro-op cache that leaks System Management Mode instructions into user space A flaw in AMD's PSP signing chain that accepts forged firmware images

Question 4: Why did Let's Encrypt say it intends to end OCSP support?

Question 4

Why did Let's Encrypt say it intends to end OCSP support?

Because OCSP creates privacy risk and its operational burden is no longer justified Because OCSP was replaced by a mandatory new DNS-based revocation protocol Because browsers universally reject stapled OCSP responses in favor of CRLs Because OCSP responses cannot be cached long enough to avoid browser latency

Question 5: What was the key reason GRC's revoked.grc.com site continued to appear valid for several days after revocation?

Question 5

What was the key reason GRC's revoked.grc.com site continued to appear valid for several days after revocation?

The certificate was still within its original validity period after revocation The server kept stapling a previously cached, unexpired OCSP response The certificate authority had not yet published the revocation to any OCSP responder The browser cached a positive verdict from a local CRL mirror

Cancel

My Data//Security & Privacy//Clear Local Data

© 2026 Ken ArmstrongSecurity Now™ is a trademark of TWiT LLC. All trademarks and copyrights of the Security Now podcast are respected and reserved to their respective holders.
This is a hobby project made with love and admiration for what Steve Gibson and Leo Laporte have built over 20 years.