Login
Apple and Microsoft recently released software updates to fix dozens of security holes in their operating systems. Microsoft today patched at least 60 vulnerabilities in its Windows OS. Meanwhile, Apple’s new macOS Sonoma addresses at least 68 security weaknesses, and its latest update for iOS fixes two zero-day flaws.
Last week, Apple pushed out an urgent software update to its flagship iOS platform, warning that there were at least two zero-day exploits for vulnerabilities being used in the wild (CVE-2024-23225 and CVE-2024-23296). The security updates are available in iOS 17.4, iPadOS 17.4, and iOS 16.7.6.
Apple’s macOS Sonoma 14.4 Security Update addresses dozens of security issues. Jason Kitka, chief information security officer at Automox, said the vulnerabilities patched in this update often stem from memory safety issues, a concern that has led to a broader industry conversation about the adoption of memory-safe programming languages [full disclosure: Automox is an advertiser on this site].
On Feb. 26, 2024, the Biden administration issued a report that calls for greater adoption of memory-safe programming languages. On Mar. 4, 2024, Google published Secure by Design, which lays out the company’s perspective on memory safety risks.
Mercifully, there do not appear to be any zero-day threats hounding Windows users this month (at least not yet). Satnam Narang, senior staff research engineer at Tenable, notes that of the 60 CVEs in this month’s Patch Tuesday release, only six are considered “more likely to be exploited” according to Microsoft.
Those more likely to be exploited bugs are mostly “elevation of privilege vulnerabilities” including CVE-2024-26182 (Windows Kernel), CVE-2024-26170 (Windows Composite Image File System (CimFS), CVE-2024-21437 (Windows Graphics Component), and CVE-2024-21433 (Windows Print Spooler).
Narang highlighted CVE-2024-21390 as a particularly interesting vulnerability in this month’s Patch Tuesday release, which is an elevation of privilege flaw in Microsoft Authenticator, the software giant’s app for multi-factor authentication. Narang said a prerequisite for an attacker to exploit this flaw is to already have a presence on the device either through malware or a malicious application.
“If a victim has closed and re-opened the Microsoft Authenticator app, an attacker could obtain multi-factor authentication codes and modify or delete accounts from the app,” Narang said. “Having access to a target device is bad enough as they can monitor keystrokes, steal data and redirect users to phishing websites, but if the goal is to remain stealth, they could maintain this access and steal multi-factor authentication codes in order to login to sensitive accounts, steal data or hijack the accounts altogether by changing passwords and replacing the multi-factor authentication device, effectively locking the user out of their accounts.”
CVE-2024-21334 earned a CVSS (danger) score of 9.8 (10 is the worst), and it concerns a weakness in Open Management Infrastructure (OMI), a Linux-based cloud infrastructure in Microsoft Azure. Microsoft says attackers could connect to OMI instances over the Internet without authentication, and then send specially crafted data packets to gain remote code execution on the host device.
CVE-2024-21435 is a CVSS 8.8 vulnerability in Windows OLE, which acts as a kind of backbone for a great deal of communication between applications that people use every day on Windows, said Ben McCarthy, lead cybersecurity engineer at Immersive Labs.
“With this vulnerability, there is an exploit that allows remote code execution, the attacker needs to trick a user into opening a document, this document will exploit the OLE engine to download a malicious DLL to gain code execution on the system,” Breen explained. “The attack complexity has been described as low meaning there is less of a barrier to entry for attackers.”
A full list of the vulnerabilities addressed by Microsoft this month is available at the SANS Internet Storm Center, which breaks down the updates by severity and urgency.
Finally, Adobe today issued security updates that fix dozens of security holes in a wide range of products, including Adobe Experience Manager, Adobe Premiere Pro, ColdFusion 2023 and 2021, Adobe Bridge, Lightroom, and Adobe Animate. Adobe said it is not aware of active exploitation against any of the flaws.
By the way, Adobe recently enrolled all of its Acrobat users into a “new generative AI feature” that scans the contents of your PDFs so that its new “AI Assistant” can “understand your questions and provide responses based on the content of your PDF file.” Adobe provides instructions on how to disable the AI features and opt out here.
Related tags
Over the past several years, domain name queries – a critical element of internet communication – have quietly become more secure, thanks, in large part, to a little-known set of technologies that are having a global impact. Verisign CTO Dr. Burt Kaliski covered these in a recent Internet Protocol Journal article, and I’m excited to share more about the role Verisign has performed in advancing this work and making one particular technology freely available worldwide.
The Domain Name System (DNS) has long followed a traditional approach of answering queries, where resolvers send a query with the same fully qualified domain name to each name server in a chain of referrals. Then, they generally apply the final answer they receive only to the domain name that was queried for in the original request.
But recently, DNS operators have begun to deploy various “minimization techniques” – techniques aimed at reducing both the quantity and sensitivity of information exchanged between DNS ecosystem components as a means of improving DNS security. Why the shift? As we discussed in a previous blog, it’s all in the interest of bringing the process closer to the “need-to-know” security principle, which emphasizes the importance of sharing only the minimum amount of information required to complete a task or carry out a function. This effort is part of a general, larger movement to reduce the disclosure of sensitive information in our digital world.
As part of Verisign’s commitment to security, stability, and resiliency of the global DNS, the company has worked both to develop qname minimization techniques and to encourage the adoption of DNS minimization techniques in general. We believe strongly in this work since these techniques can reduce the sensitivity of DNS data exchanged between resolvers and both root and TLD servers without adding operational risk to authoritative name server operations.
To help advance this area of technology, in 2015, Verisign announced a royalty-free license to its qname minimization patents in connection with certain Internet Engineering Task Force (IETF) standardization efforts. There’s been a steady increase in support and deployment since that time; as of this writing, roughly 67% of probes were utilizing qname-minimizing resolvers, according to statistics hosted by NLnet Labs. That’s up from just 0.7% in May 2017 – a strong indicator of minimization techniques’ usefulness to the community. At Verisign, we are seeing similar trends with approximately 65% of probes utilizing qname-minimizing resolvers in queries with two labels at .com and .net authoritative name servers, as shown in Figure 1 below.
Kaliski’s article, titled “Minimized DNS Resolution: Into the Penumbra,” explores several specific minimization techniques documented by the IETF, reports on their implementation status, and discusses the effects of their adoption on DNS measurement research. An expanded version of the article can be found on the Verisign website.
This piece is just one of the latest to demonstrate Verisign’s continued investment in research and standards development in the DNS ecosystem. As a company, we’re committed to helping shape the DNS of today and tomorrow, and we recognize this is only possible through ongoing contributions by dedicated members of the internet infrastructure community – including the team here at Verisign.
Read more about Verisign’s contributions to this area:
Minimum Disclosure: What Information Does a Name Server Need to Do Its Job? (blog)
Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution (blog)
Information Protection for the Domain Name System: Encryption and Minimization (blog)
The post Minimized DNS Resolution: Into the Penumbra appeared first on Verisign Blog.
This is the final in a multi-part series on cryptography and the Domain Name System (DNS).
In previous posts in this series, I’ve discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC).
In this final blog post, I’ll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I’ve also written about DNS encryption as well as minimization in a separate post on DNS information protection.)
In 2014, the Internet Engineering Task Force (IETF) chartered the DNS PRIVate Exchange (dprive) working group to start work on encrypting DNS queries and responses exchanged between clients and resolvers.
That work resulted in RFC 7858, published in 2016, which describes how to run the DNS protocol over the Transport Layer Security (TLS) protocol, also known as DNS over TLS, or DoT.
DNS encryption between clients and resolvers has since gained further momentum, with multiple browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the Encrypted DNS Deployment Initiative, and with further enhancements such as oblivious DoH.
The dprive working group turned its attention to the resolver-to-authoritative exchange during its rechartering in 2018. And in October of last year, ICANN’s Office of the CTO published its strategy recommendations for the ICANN-managed Root Server (IMRS, i.e., the L-Root Server), an effort motivated in part by concern about potential “confidentiality attacks” on the resolver-to-root connection.
From a cryptographer’s perspective the prospect of adding encryption to the DNS protocol is naturally quite interesting. But this perspective isn’t the only one that matters, as I’ve observed numerous times in previous posts.
A common theme in this series on cryptography and the DNS has been the question of whether the benefits of a technology are sufficient to justify its cost and complexity.
This question came up not only in my review of two newer cryptographic advances, but also in my remarks on the motivation for two established tools for providing evidence that a domain name doesn’t exist.
Recall that the two tools — the Next Secure (NSEC) and Next Secure 3 (NSEC3) records — were developed because a simpler approach didn’t have an acceptable risk / benefit tradeoff. In the simpler approach, to provide a relying party assurance that a domain name doesn’t exist, a name server would return a response, signed with its private key, “<name> doesn’t exist.”
From a cryptographic perspective, the simpler approach would meet its goal: a relying party could then validate the response with the corresponding public key. However, the approach would introduce new operational risks, because the name server would now have to perform online cryptographic operations.
The name server would not only have to protect its private key from compromise, but would also have to protect the cryptographic operations from overuse by attackers. That could open another avenue for denial-of-service attacks that could prevent the name server from responding to legitimate requests.
The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which gave the option of moving the private key and the cryptographic operations offline, into the name server’s provisioning system. Cryptography and operations were balanced by this better solution. The theme is now returning to view through the recent efforts around DNS encryption.
Like the simpler initial approach for authentication, DNS encryption may meet its goal from a cryptographic perspective. But the operational perspective is important as well. As designers again consider where and how to deploy private keys and cryptographic operations across the DNS ecosystem, alternatives with a better balance are a desirable goal.
In addition to encryption, there has been research into other, possibly lower-risk alternatives that can be used in place of or in addition to encryption at various levels of the DNS.
We call these techniques collectively minimization techniques.
In “textbook” DNS resolution, a resolver sends the same full domain name to a root server, a top-level domain (TLD) server, a second-level domain (SLD) server, and any other server in the chain of referrals, until it ultimately receives an authoritative answer to a DNS query.
This is the way that DNS resolution has been practiced for decades, and it’s also one of the reasons for the recent interest in protecting information on the resolver-to-authoritative exchange: The full domain name is more information than all but the last name server needs to know.
One such minimization technique, known as qname minimization, was identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license to its qname minimization patents.)
With qname minimization, instead of sending the full domain name to each name server, the resolver sends only as much as the name server needs either to answer the query or to refer the resolver to a name server at the next level. This follows the principle of minimum disclosure: the resolver sends only as much information as the name server needs to “do its job.” As Matt Thomas described in his recent blog post on the topic, nearly half of all .com and .net queries received by Verisign’s .com TLD servers were in a minimized form as of August 2020.
Other techniques that are part of this new chapter in DNS protocol evolution include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in the DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range proofs obtained in response to previous queries to determine on its own whether a domain name doesn’t exist. This means that the resolver doesn’t always have to ask the authoritative server system about a domain name it hasn’t seen before.
All of these techniques, as well as additional minimization alternatives I haven’t mentioned, have one important common characteristic: they only change how the resolver operates during the resolver-authoritative exchange. They have no impact on the authoritative name server or on other parties during the exchange itself. They thereby mitigate disclosure risk while also minimizing operational risk.
The resolver’s exchanges with authoritative name servers, prior to minimization, were already relatively less sensitive because they represented aggregate interests of the resolver’s many clients1. Minimization techniques lower the sensitivity even further at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver still sends the aggregate interests in full domain names at the SLD level and below2, and may also include certain client-related information at these levels, such as the client-subnet extension. The lower levels therefore may have different protection objectives than the upper levels.
Minimization techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.
These tools complement those I’ve described in previous posts in this series. Some have already been deployed at scale, such as a DNSSEC with its NSEC and NSEC3 non-existence proofs. Others are at various earlier stages, like NSEC5 and tokenized queries, and still others contemplate “post-quantum” scenarios and how to address them. (And there are yet other tools that I haven’t covered in this series, such as authenticated resolution and adaptive resolution.)
Modern cryptography is just about as old as the DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and to meet new security objectives. While they’ve often moved forward separately, as this blog series has shown, there are also opportunities for them to advance together. I look forward to sharing more insights from Verisign’s research in future blog posts.
Read the complete six blog series:
1. This argument obviously holds more weight for large resolvers than for small ones — and doesn’t apply for the less common case of individual clients running their own resolvers. However, small resolvers and individual clients seeking additional protection retain the option of sending sensitive queries through a large, trusted resolver, or through a privacy-enhancing proxy. The focus in our discussion is primarily on large resolvers.
2. In namespaces where domain names are registered at the SLD level, i.e., under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root through effective TLD” and “below effective TLD level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.
The post Information Protection for the Domain Name System: Encryption and Minimization appeared first on Verisign Blog.
Over the past several years, questions about how to protect information exchanged in the Domain Name System (DNS) have come to the forefront.
One of these questions was posed first to DNS resolver operators in the middle of the last decade, and is now being brought to authoritative name server operators: “to encrypt or not to encrypt?” It’s a question that Verisign has been considering for some time as part of our commitment to security, stability and resiliency of our DNS operations and the surrounding DNS ecosystem.
Because authoritative name servers operate at different levels of the DNS hierarchy, the answer is not a simple “yes” or “no.” As I will discuss in the sections that follow, different information protection techniques fit the different levels, based on a balance between cryptographic and operational considerations.
Rather than asking whether to deploy encryption for a particular exchange, we believe it is more important to ask how best to address the information protection objectives for that exchange — whether by encryption, alternative techniques or some combination thereof.
Information protection must balance three objectives:
The importance of balancing these objectives is well-illustrated in the case of encryption. Encryption can improve confidentiality and integrity by making it harder for an adversary to view or change data, but encryption can also impair availability, by making it easier for an adversary to cause other participants to expend unnecessary resources. This is especially the case in DNS encryption protocols where the resource burden for setting up an encrypted session rests primarily on the server, not the client.
The Internet-Draft “Authoritative DNS-Over-TLS Operational Considerations,” co-authored by Verisign, expands on this point:
Initial deployments of [Authoritative DNS over TLS] may offer an immediate expansion of the attack surface (additional port, transport protocol, and computationally expensive crypto operations for an attacker to exploit) while, in some cases, providing limited protection to end users.
Complexity is also a concern because DNS encryption requires changes on both sides of an exchange. The long-installed base of DNS implementations, as Bert Hubert has parabolically observed, can only sustain so many more changes before one becomes the “straw that breaks the back” of the DNS camel.
The flowchart in Figure 1 describes a two-stage process for factoring in operational risk when determining how to mitigate the risk of disclosure of sensitive information in a DNS exchange. The process involves two questions.
This process can readily be applied to develop guidance for each exchange in the DNS resolution ecosystem.
Three main exchanges in the DNS resolution ecosystem are considered here, as shown in Figure 2: resolver-to-authoritative at the root and TLD level; resolver-to-authoritative below these levels; and client-to-resolver.
The resolver-to-authoritative exchange at the root level enables DNS resolution for all underlying domain names; the exchange at the TLD level does the same for all names under a TLD. These exchanges provide global navigation for all names, benefiting all resolvers and therefore all clients, and making the availability objective paramount.
As a resolver generally services many clients, information exchanged at these levels represents aggregate interests in domain names, not the direct interests of specific clients. The sensitivity of this aggregated information is therefore relatively low to start with, as it does not contain client-specific details beyond the queried names and record types. However, the full domain name of interest to a client has conventionally been sent to servers at the root and TLD levels, even though this is more information than they need to know to refer the resolver to authoritative name servers at lower levels of the DNS hierarchy. The additional detail in the full domain name may be considered sensitive in some cases. Therefore, this data exchange merits consideration for protection.
The decision flow (as generally described in Figure 1) for this exchange is as follows:
Interestingly, while minimization itself is sufficient to address the disclosure risk at the root and TLD levels, encryption alone isn’t. Encryption protects against disclosure to outside observers but not against disclosure to (or by) the name server itself. Even though the sensitivity of the information is relatively low for reasons noted above, without minimization, it’s still more than the name server needs to know.
Summary: Resolvers should apply minimization techniques at the root and TLD levels. Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges.
Note that at this time, Verisign has no plans to implement DNS encryption at the root or TLD servers that the company operates. Given the availability of qname minimization, which we are encouraging resolver operators to implement, and other minimization techniques, we do not currently see DNS encryption at these levels as offering an appropriate risk / benefit tradeoff.
The resolver-to-authoritative exchanges at the SLD level and below enable DNS resolution within specific namespaces. These exchanges provide local optimization, benefiting all resolvers and all clients interacting with the included namespaces.
The information exchanged at these levels also represents the resolver’s aggregate interests, but in some cases, it may also include client-related information such as the client’s subnet. The full domain names and the client-related information, if any, are the most sensitive parts.
The decision flow for this exchange is as follows:
Summary: Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names or client-specific information. Otherwise, they should not be required to implement DNS encryption.
The client-to-resolver exchange enables navigation to all domain names for all clients of the resolver.
The information exchanged here represents the interests of each specific client. The sensitivity of this information is therefore relatively high, making confidentiality vital.
The decision process in this case traverses the first and second steps:
Summary: Clients and resolvers should implement DNS encryption on this exchange, unless the exchange is otherwise adequately protected, for instance as part of the network connection provided by an enterprise or internet service provider.
The following table summarizes the guidance for how to protect the various exchanges in the DNS resolution ecosystem.
In short, the guidance is “minimize at root and TLD, encrypt when needed elsewhere.”
| DNS Exchange | Purpose | Guidance |
|---|---|---|
| Resolver-to-Root and TLD | Global navigational availability | • Resolvers should apply minimization techniques • Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges |
| Resolver-to-SLD and Below | Local performance optimization | • Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names, or client-specific information • Resolvers and SLD servers (and below) should not be required to implement DNS encryption otherwise |
| Client-to-Resolver | General DNS resolution | • Clients and resolvers should implement DNS encryption on this exchange, unless adequate protection is otherwise provided, e.g., as part of a network connection |
If the guidance suggested here were followed, we could expect to see more deployment of minimization techniques on resolver-to-authoritative exchanges at the root and TLD levels; more deployment of DNS encryption, when needed, at the SLD levels and lower; and more deployment of DNS encryption on client-to-resolver exchanges.
In all these deployments, the DNS will serve the same purpose as it already does in today’s unencrypted exchanges: enabling general-purpose navigation to information and resources on the internet.
DNS encryption also brings two new capabilities that make it possible for the DNS to serve two new purposes. Both are based on concepts developed in Verisign’s research program.
You can read more about these two applications in my recent blog post on this topic, Authenticated Resolution and Adaptive Resolution: Security and Navigational Enhancements to the Domain Name System.
The post A Balanced DNS Information Protection Strategy: Minimize at Root and TLD, Encrypt When Needed Elsewhere appeared first on Verisign Blog.
FreshRSS