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.

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 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

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 | +------------+------------------+-----------------+