Since the 1st of February multiple major DNS (defined) resolvers removed resolver workarounds. The resolvers involved in the initiative include ISC, Cloudflare, Facebook, Cisco, Google (among others).
The workarounds were removed to stop DNS queries not compliant with the following official Requests for Comments (RFC) 1035 and 2671 from being completed(resolved). In more depth; the DNS Flag day page explains these workarounds are being removed due to:
The current DNS is unnecessarily slow and inefficient because of efforts to accommodate a few DNS systems that are not in compliance with DNS standards established two decades ago.
To ensure further sustainability of the system it is time to end these accommodations and remediate the non-compliant systems. This change will make most DNS operations slightly more efficient, and also allow operators to deploy new functionality, including new mechanisms to protect against DDoS attacks.
It appears that DNS amplification and DNS flood attacks are the threats attempting to be mitigated with these changes. A full list of the types of DDoS (defined) attacks is available from the following Cloudflare page (at the end of that page):
It will be interesting to see the effect of these changes on the DNS infrastructure when it is again targeted by botnets (defined) (e.g. made up of Internet of Things (IoT)(defined) or compromised systems or by other means. Such botnets can make use a command and control (C2) (defined) infrastructure.
For 5 days within February this year; an information disclosure issue affected Cloudflare’s infrastructure. This led to their systems inadvertently leaking private session keys, website cookies, encryption keys and passwords.
Why should this vulnerability be considered important?
The scale of the issue was large, affecting an estimated 2 million websites. This flaw was due to a coding error within a parser (defined) (undetected at the time) used to modify HTML webpages and related to how the memory containing buffers (defined) of their NGINX (defined) web server functioned. Google Project Zero vulnerability researcher Tavis Ormandy contacted Cloudflare over Twitter who mitigated the issue in 47 minutes and completed their work in less than 7 hours; an incredibly swift resolution. Cloudflare later noted it would usually take 3 months to resolve an issue similar to this.
How can I protect myself from this vulnerability?
Cloudflare documented their findings of this incident within this blog post. Their analysis shows no evidence of attackers using the leaked information for malicious account access, accessing sensitive information or fraudulent purchases (in the case of exposed credit card numbers).
Cloudflare is continuing to review the leaked information and working to remove it from third party caches. They have committed to a review (both internal and with the assistance of external auditor Veracode) of the parser code which inadvertently lead to this information leakage.
As a precaution I would recommend monitoring any affected accounts for unwanted activity and change passwords and enable 2 factor authentication should any unwanted activity take place. The list of affected websites is here.