SuperSluether disturbed my sleep to write:

Hi,

My Raspberry Pi and Ubuntu Server already have the updated version of libc6. Is a reboot still required? I thought only kernel updates required a reboot.

When you update a shared library, any running program that uses that library still has the *old* copy in memory until that program is restarted. Say you've got a program named "foo" running on your server that uses a library named "libbar", and you upgrade libbar without restarting foo. The running instance of foo still has the *old* version of libbar in its memory, and will not get the new one until it's restarted. Most libraries aren't so central to everything that runs in Linux, and restarting the programs that use the library in question is a perfectly fine way to ensure you get the new library loaded. But libc is so very central to absolutely *everything* (or nearly so) in Linux that the best way to ensure everything gets the new, patched versions is simply to reboot. -- Saint Aardvark the Carpeted http://saintaardvarkthecarpeted.com Because the plural of Anecdote is Myth.

Based on the exploit, aren't, at most, only the exits vulnerable? I didn't think middles would do any DNS resolving. Those like me running debian and putting off doing a reboot might find needrestart (package of same name) and checkrestart (package debian-goodies) useful. On Tue, 23 Feb 2016, at 07:16 AM, Dmitrii Tcvetkov wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On Mon, 22 Feb 2016 21:16:42 -0800 Saint Aardvark the Carpeted <aardvark@saintaardvarkthecarpeted.com> wrote:

...

Most libraries aren't so central to everything that runs in Linux, and restarting the programs that use the library in question is a perfectly fine way to ensure you get the new library loaded. But libc is so very central to absolutely *everything* (or nearly so) in Linux that the best way to ensure everything gets the new, patched versions is simply to reboot.

It is true, but still reboot should not be so essential for glibc upgrade. You can just restart (not reload, SIGHUP will not help) services on your server and they will load new glibc. This will allow yout to delay server reboot until next kernel upgrade.

IOW server reboot is easier but is not necessary. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQEcBAEBCAAGBQJWzAdnAAoJEG7QE8vSCezkgTkIAL/B0wBlY/TEvinnIPjj3SLO loZLceYMnxEscnPTmEGCFY/9w2T+0XCW/sFSOrGd9ji9V5Fubuo06wzqUStsuLwq HaMuaCLFo4cSI1nHyx99Uu5WG0/Oy2HAVHOsoSSyKT+2XkCKxii4KKtSCXxIUbHk gUujxXTNhknh8hIXS66mgVIYB26r1rLDcHTO7/LGPcooJjrnP+RbDobEk5e/yqEI NMQjVDienm/+xWmIBfQBJp98Fi0+I79u4duSs06lRD95mKyxB8oUqw9eD6VOHHwB 0MQQbRO67mqFrCTi1T1WhSjjj4xsvLfjQSf31PfZm/PCEL6aJ3LFoTP6VkPjMjY= =6tI4 -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Louie Cardone-Noott:

Those like me running debian and putting off doing a reboot might find needrestart (package of same name) and checkrestart (package debian-goodies) useful.

Under Gentoo "lib_users -s" is a useful command IMO to see if a in-use lib was changed. - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlbMyt4ACgkQxOrN3gB26U699gD/U9s7pjWorGXEEZ9yvjM50IIg o/EpBZ34y6hGxnWtpNkA/jnroRaIsIqTsrVxrMpV1OkGVHYvuib2uW/XQUGLmLqy =lLbN -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23.02.2016 22:12, Tom van der Woerdt wrote:

Op 23/02/16 om 22:10 schreef Toralf Förster:

...

Louie Cardone-Noott:

...

Those like me running debian and putting off doing a reboot might find needrestart (package of same name) and checkrestart (package debian-goodies) useful.

Under Gentoo "lib_users -s" is a useful command IMO to see if a in-use lib was changed.

On most linuxes you can do this with "lsof | grep DEL | grep lib"

Here is a version with better filtering and output: lsof -n +c 0 | grep 'DEL.*lib' | awk '1 { print $1 ": " $NF }' | sort -u -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWzNLfAAoJEJe61A/xrcOQA5AQAI+cXfFAqLcEYdeupGcqjLtf 8Mjyyxq10jtB/zpqbxWqdIxyiDJmF3tzKJmzmrKzNmLsz8hfQbFxYLsZjlhdOHX4 N4fMxCX1FNrxKC4TuGFu3PMeFZlmieIGYF8MVg/yZJ0rx4LlA86t2cDXOzi2Qn57 5DGSoyQ8Ll3XBzDhBYJvPmz7kCc0oyjVO+S0m6+uJc9UMeJtuIrMJGEqQzk//pFC ltV24qPF1NhtHbHIsNbmjAnTj+KZ5lDnwWHfc6YNGeiPYH+3DtgT8H/rd9I0Vdv/ QkBaq90okwu0UC1K1PeREol60StSkDbCPzVpqWzVgbB0sq2GoVlccgSog2hwuzUJ mriWh4JxF41NCF0sKNAUVEBHb1VsQQQPn7RVjfHBurDYsDcmPK1LXMDI/AeuWEU0 EX10Fwl7YRzk3UfRICZwT2yVXm3ep9kweKXdMWs4Ql5dM/Y3LQl0/fTm4IzCrO5C wp5qDQqD5OHRsroG5KTKTS5u0Vw2mkESmVfx40NxWhxPZCsYE35IVsarSfSvDFxt 88mKimYqJUYShBAjKfVtB+yWKzHXOMm5TaQdxYbLHVxYo/b9ndlM/IiyFP4U/HuJ YmnjMywZE44bJr+SYfgcUn3SWNFY4VrO9qf2Uoh8VtKbHsGOj+SLdG1nLnQOfELU eaCkGMX0sBif5lhe/Tr+ =v/3o -----END PGP SIGNATURE-----

you say that 64% of the guard relays and 51% of the exit relaysare are unpatched ?

These numbers are not based on relaycount but on guard/exit probability (so it takes a relay's contributed bandwidth/consensus weight into account). If you are more interested in relay counts: 3754 out of 7268 relays are probably vulnerable (51%).

...

+------------+------------------+-----------------+ | cwfraction | guardprobability | exitprobability | +------------+------------------+-----------------+ | 0.586 | 0.639 | 0.518 | +------------+------------------+-----------------+

2016-02-23: +------------+------------------+-----------------+ | cwfraction | guardprobability | exitprobability | +------------+------------------+-----------------+ | 0.560 | 0.621 | 0.466 | +------------+------------------+-----------------+