{"uuid": "9efbe787-3003-4087-a55d-9abe4fe0ea39", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CISCO-SA-20160218-GLIBC", "type": "seen", "source": "https://t.me/informationsec/693", "content": "\u0627\u0637\u0644\u0627\u0639\u0627\u062a \u062a\u06a9\u0645\u06cc\u0644\u06cc \u062f\u0631 \u062e\u0635\u0648\u0635 \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631\u06cc Glibc \u0648 \u0631\u0648\u0634\u0647\u0627\u06cc Mitigation \u0622\u0646\n\nhttps://sourceware.org/bugzilla/show_bug.cgi?id=18665\n\n- Mitigating factors for UDP include:\n\u00a0 - A firewall that drops UDP DNS packets > 512 bytes.\n\u00a0 - A local resolver (that drops non-compliant responses).\n\u00a0 - Avoid dual A and AAAA queries (avoids buffer management error) e.g.\n\u00a0 \u00a0 Do not use AF_UNSPEC.\n\u00a0 - No use of options edns0 in /etc/resolv.conf since EDNS0 allows\n\u00a0 \u00a0 responses larger than 512 bytes and can lead to valid DNS responses\n\u00a0 \u00a0 that overflow.\n\u00a0 - No use of RES_USE_EDNS0 or RES_USE_DNSSEC since they can both\n\u00a0 \u00a0 lead to valid large EDNS0-based DNS responses that can overflow.\n\n- Mitigating factors for TCP include:\n\u00a0 - Limit all replies to 1024 bytes.\n\n- Mitigations that don't work:\n\u00a0 - Setting options single-request does not change buffer management\n\u00a0 \u00a0 and does not prevent the exploit.\n\u00a0 - Setting options single-request-reopen does not change buffer\n\u00a0 \u00a0 management and does not prevent the exploit.\n\u00a0 - Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC\n\u00a0 \u00a0 unconditionally enables the dual query.\n\u00a0 \u00a0 - The use of sysctl -w net.ipv6.conf.all.disable_ipv6=1 will not\n\u00a0 \u00a0 \u00a0 protect your system from the exploit.\n\u00a0 - Blocking IPv6 at a local or intermediate resolver does not work to\n\u00a0 \u00a0 prevent the exploit. The exploit payload can be delivered in A or\n\u00a0 \u00a0 AAAA results, it is the parallel query that triggers the buffer\n\u00a0 \u00a0 management flaw.\n\n\u2796\u2796\u2796\u2796\n@informationsec\n\n\u067e\u06cc\u06a9\u0631\u0628\u0646\u062f\u06cc Bind \u0628\u0631\u0627\u06cc truncation bit set(BIND 9 CONFIGURATION REFERENCE)\n\nnamed.conf \ud83d\udc49 options \ud83d\udc49rate-limit \ud83d\udc49 [ slip number ; ]\n\u2796\u2796\u2796\u2796\nDnsmasq\nhttp://www.thekelleys.org.uk/dnsmasq/doc.html\nhttps://wiki.debian.org/HowTo/dnsmasq\n\u2796\u2796\u2796\u2796\nASLR technique\nhttps://en.wikipedia.org/wiki/Address_space_layout_randomization\n\u2796\u2796\u2796\u2796\n@informationsec\n\nRule \u0647\u0627\u06cc \u067e\u06cc\u0634\u0646\u0647\u0627\u062f\u06cc  Mitigate \u0627\u06cc\u0646 \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631\u06cc \u062a\u0648\u0633\u0637 snort\nCVE-2015-7547 (GlibC bug) snort rules\nhttp://seclists.org/snort/2016/q1/285\n\u2796\u2796\u2796\u2796\n@informationsec\n\u0648\u0636\u0639\u06cc\u062a \u0627\u06cc\u0646 \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631\u06cc \u0648 \u062a\u062c\u0647\u06cc\u0632\u0627\u062a \u0648 \u0645\u062d\u0635\u0648\u0644\u0627\u062a \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631 Cisco\nhttps://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160218-glibc\n\u2796\u2796\u2796\u2796\n\u0631\u0627\u0647\u06a9\u0627\u0631 \u067e\u06cc\u0634\u0646\u0647\u0627\u062f\u06cc \u0628\u0631\u0627\u06cc Mitigate \u0627\u06cc\u0646 \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631\u06cc \u062f\u0631 \u0645\u062d\u0635\u0648\u0644\u0627\u062a Cisco\nCVE-2015-7547, glibc vulnerability; its impact on Cisco products and our mitigation solutions\n\nhttp://info.stack8.com/blog/cve20157547-google-glibc-vulnerability-cisco-products\n\u2796\u2796\u2796\u2796\n\u0648\u0636\u0639\u06cc\u062a \u0627\u06cc\u0646 \u0622\u0633\u06cc\u0628 \u067e\u0630\u06cc\u0631\u06cc \u062f\u0631 Debian\nhttps://security-tracker.debian.org/tracker/CVE-2015-7547\n\u2796\u2796\u2796\u2796\nCVE-2015-7547-poc\nhttps://github.com/fjserna/CVE-2015-7547\n\n@informationsec", "creation_timestamp": "2026-08-23T00:00:40.348849Z"}