- The newest Echo Show 8 just hit its lowest price ever for Black Friday
- 기술 기업 노리는 북한의 가짜 IT 인력 캠페인··· 데이터 탈취도 주의해야
- 구글 클라우드, 구글 워크스페이스용 제미나이 사이드 패널에 한국어 지원 추가
- The best MagSafe accessories of 2024: Expert tested and reviewed
- Threads will show you more from accounts you follow now - like Bluesky already does
The Bug Report – November Edition
Your Cybersecurity Comic Relief
CVE-2021-20322: Of all the words of mice and men, the saddest are, “it was DNS again.”
Why am I here?
For all our newcomers, welcome to the Advanced Threat Research team’s monthly bug report – a digest of all the latest and greatest vulnerabilities from the last 30-ish days based on merits just a tad more nuanced than sorting NVD by “CVSS > 9.0.” Instead, we focus on qualitative and experience-based analysis, relying on over 100 years of combined industry experience within our team.
To those who are returning after having read last month’s issue, I would like to congratulate you for being a Bug Report fan before it was cool – which it now most assuredly is, thanks in no small part to yours truly a litany of fascinating vulnerabilities. We encourage our veterans to stick around as long as possible, so that a year from now you can complain about how we’re washed up and how much better our early editions were.
PAN GlobalProtect VPN: CVE-2021-3064
What is it?
Palo Alto Networks (PAN) firewalls that use its GlobalProtect Portal VPN running PAN-OS versions older than 8.1.17 are vulnerable to a cutting-edge, state-of-the-art style of vulnerability known as a “stack-based buffer overflow.” Although the vulnerable code is normally not reachable, when combined with an HTTP smuggling vulnerability, CVE-2021-3064 can be used to gain remote code execution, a remote shell, and even access to sensitive configuration data according to Randori Attack Team researchers. Randori discovered the vulnerability over a year ago but chose not to disclose it to PAN until September of this year, using it as part of its “continuous and automated red team platform” during the interim – I suppose we should be thankful that PAN has claimed in its security advisory that no evidence of exploitation of this vuln has been discovered, despite its age.
Who cares?
Absence of “in-the-wild” exploitation aside, we should also be grateful that the number of people who should care is rapidly dwindling (an ever-present theme of 2021). Randori initially reported over 70,000 internet-accessible PAN firewalls running vulnerable versions of PAN-OS according to Shodan, which it later amended to 10,000. As of this writing, that number has fallen to around 7,000. Even so, 7,000 vulnerable firewalls mean an even larger number of vulnerable clients at risk of an over-the-internet attack vector requiring zero authentication. Those connecting to PAN firewalls running on VMs have even greater cause for concern as these lack ASLR, a factoid I have chosen to add to my ever-growing “why is that a thing” list, right next to the Ghostbusters remake.
What can I do?
We suggest an experiment: open the Shodan search linked above and note the total number of devices running a vulnerable version of PAN-OS. Next, call up whoever manages your firewall and demand they power it down immediately – use threats if you must. Check the Shodan scan again: has the number gone down? If so, it’s probably time to update. If you’re an Arch user and the prospect of updating terrifies you, Palo Alto has also indicated that its signatures for Unique Threat IDs 91820 and 91855 should block exploitation of CVE-2021-3064.
The Gold Standard
Be sure to stay up to date on the latest CVEs – our security bulletins are a great resource for finding product information for all kinds of critical vulnerabilities.
Linux Kernel: CVE-2021-20322
What is it?
Researchers at the University of California, Riverside have discovered a flaw in the way the Linux kernel handles “ICMP fragment needed” and “ICMP redirect” errors, allowing an attacker to quickly learn the randomized port number assigned to a UDP socket. What this description fails to convey is the big picture impact of this vulnerability, which is its use as a side-channel for the now-prehistoric DNS cache poisoning attack, in which an off-path malicious actor ‘poisons’ a DNS resolver’s cache with a false record, mapping a known domain (google.com) to an IP address of their choosing (98.136.144.138). Truly nefarious.
Who cares?
To be frank, just about everyone should be at least raising an eyebrow at this one. Although the researchers have indicated in their whitepaper that this particular side-channel only affects about 13.85% of open resolvers on the internet, it’s important to note that various security services rely on proof of domain ownership, including even the issuing of certificates, making the impact tremendous. Users of popular DNS service Quad9 have particular cause for concern, as the paper claims it falls under the vulnerable 13.85%. Linux users should also be concerned, and not just because their drivers refuse to work – DNS software such as BIND, Unbound, and dnsmasq running on their platform of choice are also vulnerable.
What can I do?
This is where things get tricky. DNS extensions that were standardized over two decades ago, such as DNSSEC and DNS cookies, should successfully mitigate this and all other DNS cache poisoning attack side channels. The unfortunate reality is that these features see very limited adoption due to backwards-compatibility concerns. While we wait for these dinosaurs holding back progress to die out, the authors of the aforementioned whitepaper have suggested some alternative mitigations, including enabling the IP_PMTUDISC_OMIT socket option, introducing additional randomization to the structure of the DNS exception cache, and configuring DNS servers with a singular default gateway to outright reject ICMP redirects. Further details can be found in section 8.4 of their paper.
The Gold Standard
Unfortunately, not every vulnerability can be adequately addressed by network security products, and this vulnerability happens to be one of those cases. Your best bet is to follow the mitigations mentioned above and keep your servers up to date.
Just About All DRAM: CVE-2021-42114 aka Blacksmith
What is it?
Blacksmith, a name referring to both the vulnerability and the fuzzer created to exercise it, is a new implementation of the Rowhammer DRAM hardware vulnerability from 2014. The crux of Rowhammer is the use of high frequency read operations to induce bit flips in neighboring regions of physical memory, which can lead to the crossing of any security barrier if the attacker can massage memory so that critical data is stored in a vulnerable physical page. Modern DRAM hardware uses a technology called Target Row Refresh (TRR) to prematurely refresh regions of physical memory targeted by common Rowhammer attacks. Researchers at ETH Zurich and their associates discovered that TRR exploits the uniform nature of memory accesses used by existing Rowhammer attacks to “catch” them, and so devised a Rowhammer attack that used non-uniform accesses, arriving at CVE-2021-42114, which bypasses TRR and all other modern Rowhammer mitigations.
Who cares?
Everyone. Just about every common electronic device you can think of uses DRAM and of the DIMMs (RAM sticks) tested, the researchers did not find a single one that was completely safe. It might be easy to presume that hardware vulnerabilities such as this are academically fascinating but have little real-world impact, but research published since 2014 has shown Rowhammer attacks successfully escape JavaScript containers in the browser, cross VM boundaries in the cloud, and even achieve RCE across networks with high enough throughput. Perhaps the greatest tragedy of Blacksmith is that it arrived a month too late – it would have fit in perfectly with Halloween monsters like Freddy Krueger or Jason Voorhees who also see new iterations every few years and refuse to stay dead.
What can I do?
Hide your PC, hide your tablet, and hide your phone, ‘cause they’re hammerin’ everybody out there. Beyond that, there’s not much to be done besides wait for JEDEC to develop a fix and for DRAM manufacturers to begin supplying hardware with the new standard.
The Gold Standard
We at McAfee Enterprise are doing everything in our power to address this critical vulnerability. In other words, we’ll be waiting for that JEDEC fix right along with you.