(fwd) Fwd: [ICS-VU-638779, CERT/CC VU#473698] Predictable DNS Transaction IDs in uClibc, uClibc-ng [labs-advisory@nozominetworks.com]
----- Forwarded message from Nozomi Networks Labs Advisory <labs-advisory@nozominetworks.com> ----- Date: Mon, 2 May 2022 17:01:29 +0200 From: Nozomi Networks Labs Advisory <labs-advisory@nozominetworks.com> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0 To: Waldemar Brodkorb <wbx@uclibc-ng.org> Subject: Fwd: [ICS-VU-638779, CERT/CC VU#473698] Predictable DNS Transaction IDs in uClibc, uClibc-ng Hello Waldemar, although we would have preferred an explicit confirmation from you, given the lack of alternatives and having received the approval from CERT/CC, we proceeded with the disclosure of the vulnerability to the mailing list. I kindly ask you to publish our email (the same that I am forwarding to you now) to https://mailman.openadk.org/mailman3/hyperkitty/list/devel@uclibc-ng.org/ . Best regards, Andrea Palanca -------- Forwarded Message -------- Subject: [ICS-VU-638779, CERT/CC VU#473698] Predictable DNS Transaction IDs in uClibc, uClibc-ng Date: Mon, 2 May 2022 16:53:48 +0200 From: Nozomi Networks Labs Advisory <labs-advisory@nozominetworks.com> To: devel@uclibc-ng.org Hello, as per our last interaction with Mr. Brodkorb (https://mailman.openadk.org/mailman3/hyperkitty/list/devel@uclibc-ng.org/thr...), in accordance with CERT/CC as per VINCE case VU#473698 (ICS-VU-638779), with this email we proceed with the public disclosure of the vulnerability. ----------------------------------- Vendor: uClibc, uClibc-ng Vendor URL: https://www.uclibc.org/, https://www.uclibc-ng.org/ Affected firmware: uClibc: All versions, uClibc-ng: All versions Vulnerability: Predictable DNS Transaction IDs Authors: Giannis Tsaraias (Cyber Threat Analyst @ Nozomi Networks), Andrea Palanca (Security Researcher @ Nozomi Networks) ----------------------------------- Vulnerability: The uClibc and uClibc-ng libraries generate DNS requests with incremental transaction IDs, while, at the same time, not enforcing any explicit port randomization techniques during the network connection. This may result in the possibility for an attacker to perform DNS Cache Poisoning attacks. More information in the "Exploitability" section here below. The vulnerability was confirmed statically and dynamically on version 0.9.33.2. By downloading all releases available on uClibc website, the vulnerability was confirmed statically in all versions (up to and including 0.9.33.2). Additionally, by downloading all releases of the uClibc-ng available, the vulnerability was confirmed statically for this library in all versions (up to and including 1.0.38, latest available at the time of the research). ----------------------------------- Details: The following analysis contains source code extracted from uClibc version 0.9.33.2. The uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”. At line #1240, the function declares a static variable “last_id”. This variable contains the value of the transaction ID used in the last DNS request, and is initialized with the value “1” at the first invocation of “__dns_lookup”. Additionally, at line #1260, the function declares a variable “local_id”. This variable contains the value of the transaction ID that will be used in the upcoming DNS request, and is left uninitialized. At line #1309, at the first DNS request, the “local_id” variable is initialized with the value of the transaction ID of the last DNS request (“last_id”). Line #1320 is the actual core of the vulnerability: “local_id” is updated by incrementing by “1” its old value. After doing a bitwise AND at line #1321, this value is also stored inside “last_id” variable at line #1323. Finally, at line #1335, the value of “local_id” is copied inside the struct resolv_header “h” variable, which represents the actual content of the header of the DNS request. No other updates are done to the value of “local_id” or “last_id” in the remaining part of the function. Additionally, no UDP source port randomization is done (e.g., by explicitly invoking a “bind” with a random UDP source port) prior to performing the transmission of the DNS request. ----------------------------------- Exploitability: In order to exploit the vulnerability, given that the transaction ID is predictable, an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, if the operating system is configured to use a fixed or predictable source port, it is likely that the issue can be trivially exploited in a reliable way. If the operating system applies randomization of source port (which is done by all OSs nowadays - for instance, modern Linux kernels use range 32768–60999), exploitability depends on the capacity of the attacker to bruteforce the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response. In this situation, exploitability depends on factors such as the bandwidth at disposal of the attacker, or on the response time of the DNS query. Additionally, it is more likely that an attacker is able to succeed at least once in performing a DNS poisoning attack if the target device performs a great number of identical queries in a given time frame, compared to a target that performs just sporadic queries. ----------------------------------- Remediation: It is recommended to harden the implementation of the “__dns_lookup” function by including unpredictable, random transaction IDs at each DNS request. pub rsa4096 2021-01-21 [SC] [expires: 2025-01-20] 8B8C7C296AEC8BD654FF69A6797E06A000A77236 uid Nozomi Networks Labs Advisory <labs-advisory@nozominetworks.com> sub rsa4096 2021-01-21 [E] [expires: 2025-01-20] pub rsa4096 2021-01-21 [SC] [expires: 2025-01-20] 8B8C7C296AEC8BD654FF69A6797E06A000A77236 uid Nozomi Networks Labs Advisory <labs-advisory@nozominetworks.com> sub rsa4096 2021-01-21 [E] [expires: 2025-01-20] ----- End forwarded message -----
Hi All, As mentioned in my previous message, attached is a patch which uses /dev/urandom to generate a random id for dns query id field. However if it is not able to access urandom file, then it falls back to the old logic of simple incrementing counter. Have done some minimal test on my linux system and it seems to be working fine. diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c index 92a65d0dc..c37f6fab7 100644 --- a/libc/inet/resolv.c +++ b/libc/inet/resolv.c @@ -255,6 +255,7 @@ Domain name in a message can be represented as either: #include <sys/stat.h> #include <sys/param.h> #include <bits/uClibc_mutex.h> +#include <fcntl.h> #include "internal/parse_config.h" /* poll() is not supported in kernel <= 2.0, therefore if __NR_poll is @@ -1045,6 +1046,20 @@ static int __decode_answer(const unsigned char *message, /* packet */ return i + RRFIXEDSZ + a->rdlength; } + +uint16_t dnsrand_next(int urand_fd, int def_value) { + if (urand_fd == -1) return def_value; + uint16_t val; + if(read(urand_fd, &val, 2) != 2) return def_value; + return val; +} + +int dnsrand_setup(int *urand_fd, int def_value) { + *urand_fd = open("/dev/urandom", O_RDONLY); + if (*urand_fd == -1) return def_value; + return dnsrand_next(*urand_fd, def_value); +} + /* On entry: * a.buf(len) = auxiliary buffer for IP addresses after first one * a.add_count = how many additional addresses are there already @@ -1070,6 +1085,7 @@ int __dns_lookup(const char *name, /* Protected by __resolv_lock: */ static int last_ns_num = 0; static uint16_t last_id = 1; + static int urand_fd = -1; int i, j, fd, rc; int packet_len; @@ -1149,7 +1165,7 @@ int __dns_lookup(const char *name, } /* first time? pick starting server etc */ if (local_ns_num < 0) { - local_id = last_id; + local_id = dnsrand_setup(&urand_fd, last_id); /*TODO: implement /etc/resolv.conf's "options rotate" (a.k.a. RES_ROTATE bit in _res.options) local_ns_num = 0; @@ -1159,8 +1175,9 @@ int __dns_lookup(const char *name, } if (local_ns_num >= __nameservers) local_ns_num = 0; - local_id++; + local_id = dnsrand_next(urand_fd, local_id++); local_id &= 0xffff; + DPRINTF("uClibc:DBUG:local_id:0x%hx\n", local_id); /* write new values back while still under lock */ last_id = local_id; last_ns_num = local_ns_num;
Hi, Do note that the local_id passed to dnsrand_next requires pre increment for simple counter based fallback to work. ie ++local_id rather than local_id++
Hi, On Wed, May 04, 2022 at 05:31:55PM -0000, hanishkvc@gmail.com wrote:
Hi All,
As mentioned in my previous message, attached is a patch which uses /dev/urandom to generate a random id for dns query id field. However if it is not able to access urandom file, then it falls back to the old logic of simple incrementing counter. Have done some minimal test on my linux system and it seems to be working fine.
I've took a look at how to fix this yesterday and maybe this can be fixed the same way musl does, from src/network/res_mkquery.c: /* Make a reasonably unpredictable id */ clock_gettime(CLOCK_REALTIME, &ts); id = ts.tv_nsec + ts.tv_nsec/65536UL & 0xffff; My 2cent
diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c index 92a65d0dc..c37f6fab7 100644 --- a/libc/inet/resolv.c +++ b/libc/inet/resolv.c @@ -255,6 +255,7 @@ Domain name in a message can be represented as either: #include <sys/stat.h> #include <sys/param.h> #include <bits/uClibc_mutex.h> +#include <fcntl.h> #include "internal/parse_config.h"
/* poll() is not supported in kernel <= 2.0, therefore if __NR_poll is @@ -1045,6 +1046,20 @@ static int __decode_answer(const unsigned char *message, /* packet */ return i + RRFIXEDSZ + a->rdlength; }
+ +uint16_t dnsrand_next(int urand_fd, int def_value) { + if (urand_fd == -1) return def_value; + uint16_t val; + if(read(urand_fd, &val, 2) != 2) return def_value; + return val; +} + +int dnsrand_setup(int *urand_fd, int def_value) { + *urand_fd = open("/dev/urandom", O_RDONLY); + if (*urand_fd == -1) return def_value; + return dnsrand_next(*urand_fd, def_value); +} + /* On entry: * a.buf(len) = auxiliary buffer for IP addresses after first one * a.add_count = how many additional addresses are there already @@ -1070,6 +1085,7 @@ int __dns_lookup(const char *name, /* Protected by __resolv_lock: */ static int last_ns_num = 0; static uint16_t last_id = 1; + static int urand_fd = -1;
int i, j, fd, rc; int packet_len; @@ -1149,7 +1165,7 @@ int __dns_lookup(const char *name, } /* first time? pick starting server etc */ if (local_ns_num < 0) { - local_id = last_id; + local_id = dnsrand_setup(&urand_fd, last_id); /*TODO: implement /etc/resolv.conf's "options rotate" (a.k.a. RES_ROTATE bit in _res.options) local_ns_num = 0; @@ -1159,8 +1175,9 @@ int __dns_lookup(const char *name, } if (local_ns_num >= __nameservers) local_ns_num = 0; - local_id++; + local_id = dnsrand_next(urand_fd, local_id++); local_id &= 0xffff; + DPRINTF("uClibc:DBUG:local_id:0x%hx\n", local_id); /* write new values back while still under lock */ last_id = local_id; last_ns_num = local_ns_num;
Hi, I agree with you partly, but given that on embedded targets realtime clock is a optional feature enabled/available or otherwise, one needs to provide multiple options, do have a look at the newer patch I had released earlier, It provides options for either a) retaining the simple counter logic as existing logic OR b) use urandom if available (one may have many embedded systems with linux or bsds or so with urandom but not necessarily realtime clock). c) else try realtime clock if available, d) if nothing else just use a ever running prng. In the case of urandom or clock it will be used to seed the prng periodically.
On Thu, May 05, 2022 at 04:46:06PM -0000, hanishkvc@gmail.com wrote:
Hi,
I agree with you partly, but given that on embedded targets realtime clock is a optional feature enabled/available or otherwise, one needs to provide multiple options, do have a look at the newer patch I had released earlier, Yes, I agree, I've expected clock not being availble but I didn't knew it was optional. (I didn't looked at your patch yet, I've just subscribed)
It provides options for either
a) retaining the simple counter logic as existing logic OR
b) use urandom if available (one may have many embedded systems with linux or bsds or so with urandom but not necessarily realtime clock).
c) else try realtime clock if available,
d) if nothing else just use a ever running prng.
In the case of urandom or clock it will be used to seed the prng periodically.
Sounds resonable! Cheers
participants (3)
-
hanishkvc＠gmail.com -
Jules Maselbas -
Waldemar Brodkorb