The depth of investigation of CVE-2 0 1 5-5 4 7 7&CloudFlare Virtual DNS how to protect their users-vulnerability warning-the black bar safety net

ID MYHACK58:62201567372
Type myhack58
Reporter 佚名
Modified 2015-09-25T00:00:00


Last week, the ISC released a patch that fixes the BIND9 DNS server in a remote exploit the vulnerability. This exploit will cause the server during the processing of a data packet when the occurrence of a crash. ! The announcement pointed out, the server in the processing TKEY the type of the query when an error occurred, this error causes the assertion to fail, and this fail and cause a server crash. Because the assertion is in the query parsing process occurs, so this problem can not be avoided: the server receives the data packet, the first thing to do is to parse the query, then according to the need to make the appropriate decision. TSIG is a DNS server using a verify each other's Protocol. In this Agreement the context used in the TKEY query. Unlike a conventional DNS query, the TKEY query the information, there is an EXTRA/ADDITIONAL section in this section contains information about the TKEY Type“meta”record. ! Because now the use of the data package have been disclosed, so I think we can look at the exploit code. Then we'll take a look at this crash examples of output results: 0 3-Aug-2 0 1 5 1 6:3 8:55.509 message. c:2 3 5 2: REQUIRE(name == ((void)0)) failed, back trace 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #0 0x10001510d in assertion_failed()+0x5d 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #1 0x1001ee56a in isc_assertion_failed()+0xa 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #2 0x1000bc31d in dns_message_findname()+0x1ad 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #3 0x10017279c in dns_tkey_processquery()+0xfc 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #4 0x100016945 in ns_query_start()+0x695 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #5 0x100008673 in client_request()+0x18d3 0 3-Aug-2 0 1 5 1 6:3 8:55.510 #6 0x1002125fe in run()+0x3ce 0 3-Aug-2 0 1 5 1 6:3 8:55.510 exiting (due to assertion failure) [1] 3 7 3 6 3 abort (core dumped) ./ bin/named/named-f-c named. conf The above crash code to our revelation,it tells us It is by the assertion failure causes the crash,and tell us the problem occurs somewhere in the message. c:2 3 5 2. The following is exploit code summary: // -- faa3b61 -- lib/dns/message. c isc_result_t dns_message_findname(dns_message_t msg, dns_section_t section, dns_name_t target, dns_rdatatype_t type, dns_rdatatype_t covers, dns_name_t name, dns_rdataset_t rdataset) { dns_name_t foundname; isc_result_t result; / * XXX These requirements are probably too intensive, especially * where things can be NULL, but as they are they ensure that if * something is NON-NULL, indicating that the caller expects it * to be filled in, that we can in fact fill it in. / REQUIRE(msg != NULL); REQUIRE(VALID_SECTION(section)); REQUIRE(target != NULL); if (name != NULL) ==> REQUIRE(name == NULL); [...] Here, we found a function"dns_message_findname", this function is based on the message section in the given name and type lookup having the same name and type RRset's. This function is applied to a very common C API: to get the results in the results is filled with the caller passing a pointer (dns_name_t name, dns_rdataset_t rdataset)。 ! Ironically, these pointers the verification process is really very strict: if the pointer does not point to(dns_name_t )NULL, REQUIRE assertion will fail and the server will crash, it will not try to recover. Call this function code must be extremely careful to put the pointer passed to NULL dns_name_t, the function will populate into the code back to find the name. In the non-memory-safe language, when the assertion is invalid when the crash will often occur. Because when there is an abnormality, the program is likely no way to clean up its own memory. So, in the continuing investigation, we through the stack to find the illegal calls. The next step is dns_tkey_processquery, the following is a simplified summary: // -- faa3b61 -- lib/dns/tkey. c isc_result_t dns_tkey_processquery(dns_message_t msg, dns_tkeyctx_t tctx, dns_tsig_keyring_t *ring)

[1] [2] [3] next