Monday, February 22nd, 2016

Time	Event
1:49p	GNU C Library 2.23 released Version 2.23 of the GNU C Library (glibc) has been released. The headline feature this time around seems to be Unicode 8.0.0 support; there are a number of API changes, performance improvements and security fixes as well. (Comment on this)
6:06p	Security advisories for Monday Arch Linux has updated chromium (code execution) and thunderbird (multiple vulnerabilities). Debian has updated chromium-browser (multiple vulnerabilities), didiwiki (unintended access), and xdelta3 (code execution). Debian-LTS has updated openssl (man-in-the-middle attacks) and python-imaging (denial of service). Fedora has updated graphite2 (F23: multiple vulnerabilities), kscreenlocker (F23; F22: restriction bypass), mariadb (F23: multiple vulnerabilities), nettle (F22: improper cryptographic calculations), ntp (F22: multiple vulnerabilities), php-horde-horde (F23; F22: cross-site scripting), poco (F23; F22: SSL server spoofing), python-pillow (F22: denial of service), qemu (F23: multiple vulnerabilities), and thunderbird (F23: multiple vulnerabilities). openSUSE has updated chromium (13.1: multiple vulnerabilities), chromium (13.1: code execution), erlang (13.2: man-in-the-middle attack), ffmpeg (Leap42.1: denial of service), obs-service-download_files, (Leap42.1, 13.2: code injection), postgresql93 (Leap42.1, 13.2: multiple vulnerabilities, one from 2007), qemu (Leap42.1: two vulnerabilities), chromium (SPH for SLE12; Leap42.1, 13.2: code execution), kernel (13.2: two vulnerabilities), and xdelta3 (13.2; 13.1: code execution). SUSE has updated postgresql93 (SLE12: multiple vulnerabilities, one from 2007). (Comment on this)
11:50p	Kaminsky: A Skeleton Key of Unknown Strength Dan Kaminsky looks at the Glibc DNS bug (CVE-2015-7547). "We’ve investigated the DNS lookup path, which requires the glibc exploit to survive traversing one of the millions of DNS caches dotted across the Internet. We’ve found that it is neither trivial to squeeze the glibc flaw through common name servers, nor is it trivial to prove such a feat is impossible. The vast majority of potentially affected systems require this attack path to function, and we just don’t know yet if it can. Our belief is that we’re likely to end up with attacks that work sometimes, and we’re probably going to end up hardening DNS caches against them with intent rather than accident. We’re likely not going to apply network level DNS length limits because that breaks things in catastrophic and hard to predict ways." (Comment on this)

<< Previous Day

2016/02/22 [Calendar]

Next Day >>