Pi-hole FTL v5.5 #1034
Merged
Pi-hole FTL v5.5 #1034
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…inimize padding). This reduces the size of query, client, and regex records by 8 bytes per item. Note that this optimization was done on x86_64 and may not apply for other architectures (32bit architectures already used less padding). Signed-off-by: DL6ER <[email protected]>
…rom increasing the memory needs unintentionally (e.g. due to sub-optimal padding) Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
… default to differentiate easily what was forwarded (ID will be >= 0) and what not (ID == -1). Store the upstream server also for other query types that were forwarded (like queries blocked during CNAME inspection). Signed-off-by: DL6ER <[email protected]>
…happen (we just enforce the maximum in this case) Signed-off-by: DL6ER <[email protected]>
Fix for Query Log filtering and memory optimizations
Config option MAXDBDAYS fixes and tweaks
According to UEFI[1] and PXE[2] specs, PXE clients are required to have `PXEClient` identfier in the vendor-class field of DHCP requests, and PXE servers should also include that identifier in their responses. However, the firmware of servers from a few vendors[3] are customized to include a different identifier. This patch adds an option named `dhcp-pxe-vendor` to provide a list of such identifiers. The identifier used in responses sent from dnsmasq is identical to that in the coresponding request. [1]: https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf [2]: http://www.pix.net/software/pxeboot/archive/pxespec.pdf [3]: For instance, TaiShan servers from Huawei, which are Arm64-based, send `HW-Client` in PXE requests up to now. Signed-off-by: Miao Wang <[email protected]> Signed-off-by: DL6ER <[email protected]>
Rather that letting the kernel pick source ports, do it ourselves so that the --min-port and --max-port parameters are be obeyed. Signed-off-by: DL6ER <[email protected]>
The problem is in the sort_rrset() function and allows a remote attacker to overwrite memory. Any dnsmasq instance with DNSSEC enabled is vulnerable. Signed-off-by: DL6ER <[email protected]>
At any time, dnsmasq will have a set of sockets open, bound to random ports, on which it sends queries to upstream nameservers. This patch fixes the existing problem that a reply for ANY in-flight query would be accepted via ANY open port, which increases the chances of an attacker flooding answers "in the blind" in an attempt to poison the DNS cache. CERT VU#434904 refers. Signed-off-by: DL6ER <[email protected]>
Use the SHA-256 hash function to verify that DNS answers received are for the questions originally asked. This replaces the slightly insecure SHA-1 (when compiled with DNSSEC) or the very insecure CRC32 (otherwise). Refer: CERT VU#434904. Signed-off-by: DL6ER <[email protected]>
If an RR is of a type which doesn't need canonicalisation, bypass the relatively slow canonicalisation code, and insert it direct into the digest. Signed-off-by: DL6ER <[email protected]>
… cached. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Previously, such queries would all be forwarded
independently. This is, in theory, inefficent but in practise
not a problem, _except_ that is means that an answer for any
of the forwarded queries will be accepted and cached.
An attacker can send a query multiple times, and for each repeat,
another {port, ID} becomes capable of accepting the answer he is
sending in the blind, to random IDs and ports. The chance of a
succesful attack is therefore multiplied by the number of repeats
of the query. The new behaviour detects repeated queries and
merely stores the clients sending repeats so that when the
first query completes, the answer can be sent to all the
clients who asked. Refer: CERT VU#434904.
Signed-off-by: DL6ER <[email protected]>
If we add the EDNS client subnet option, or the client's MAC address, then the reply we get back may very depending on that. Since the cache is ignorant of such things, it's not safe to cache such replies. This patch determines when a dangerous EDNS option is being added and disables caching. Note that for much the same reason, we can't combine multiple queries for the same question when dangerous EDNS options are being added, and the code now handles that in the same way. This query combining is required for security against cache poisoning, so disabling the cache has a security function as well as a correctness one. Signed-off-by: DL6ER <[email protected]>
Unlike COPTS=-DHAVE_DNSSEC, allow usage of just sha256 function from nettle, but keep DNSSEC disabled at build time. Skips use of internal hash implementation without support for validation built-in. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
PromoFaux
approved these changes
Jan 19, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Release, see blog post for further information