Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel http://dirtycow.ninja/
And? Honestly, the way people create names and websites for these things, you'd think it's a fund-raiser for something, not a critical security bug. On Fri, Oct 21, 2016 at 5:22 PM, I <beatthebastards@inbox.com> wrote:
Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
On 10/21/2016 06:23 PM, Tristan wrote:
And?
Honestly, the way people create names and websites for these things, you'd think it's a fund-raiser for something, not a critical security bug.
Tristan, they know this. They are even good-natured enough to make fun of it themselves. From http://dirtycow.ninja/
What's with the stupid (logo|website|twitter|github account)?
It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand. So we created a website, an online shop, a twitter account, and used a logo that a professional designer created.
The point is, please check for the latest kernel patches for your relay's Linux distribution. Each effort to harden and secure your relay strengthens the entire network. -- Jesse
Test, not working on my side. Some demos on your side? Le 22/10/2016 à 00:22, I a écrit :
Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
https://security-tracker.debian.org/tracker/CVE-2016-5195 Remember, to know your current debian linux kernel : uname -a If your kernel is not up to date : apt-get update && apt-get dist-upgrade && reboot I :
Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel
-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
Would it be acceptable to configure unattended-upgrades to automatically reboot the system when required? I already have it configured to check for and install all updates to Ubuntu and Tor once a day, but I still need to manually reboot to apply kernel upgrades. On Sat, Oct 22, 2016 at 6:26 PM, Petrusko <petrusko@riseup.net> wrote:
https://security-tracker.debian.org/tracker/CVE-2016-5195
Remember, to know your current debian linux kernel : uname -a
If your kernel is not up to date : apt-get update && apt-get dist-upgrade && reboot
I :
Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel
-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
I don't think it would be a terrible idea but it is always possible that your server will fail to reboot after a kernel upgrade. This leaves it offline without a general idea of why it is offline. I do use unattended-upgrades to automatically restart most services though. On Sat, Oct 22, 2016 at 07:02:21PM -0500, Tristan wrote:
Would it be acceptable to configure unattended-upgrades to automatically reboot the system when required? I already have it configured to check for and install all updates to Ubuntu and Tor once a day, but I still need to manually reboot to apply kernel upgrades.
On Sat, Oct 22, 2016 at 6:26 PM, Petrusko <[1]petrusko@riseup.net> wrote:
[2]https://security-tracker.debian.org/tracker/CVE-2016-5195 Remember, to know your current debian linux kernel : uname -a If your kernel is not up to date : apt-get update && apt-get dist-upgrade && reboot I : > Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel > > [3]http://dirtycow.ninja/ -- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5 _______________________________________________ tor-relays mailing list [4]tor-relays@lists.torproject.org [5]https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Finding information, passing it along. ～SuperSluether
References
1. mailto:petrusko@riseup.net 2. https://security-tracker.debian.org/tracker/CVE-2016-5195 3. http://dirtycow.ninja/ 4. mailto:tor-relays@lists.torproject.org 5. https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Jason Jung 7942 B145 5E45 1D53 37C8 1204 8DA4 A1DB CBE6 35AE
On 10/22/2016 08:02 PM, Tristan wrote:
Would it be acceptable to configure unattended-upgrades to automatically reboot the system when required? I already have it configured to check for and install all updates to Ubuntu and Tor once a day, but I still need to manually reboot to apply kernel upgrades.
This is not a good idea. For one, the new kernel could break your network connection, which happened to me this morning after I rebooted a personal machine. Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day. You also need to be careful with automatically installing updates in a production environment, as one of them could break something and it would be some time before you noticed. I prefer to review the updates before I install them and watch the apt-get log in case there are any issues. Debian systems may even show you the changelogs. If an update breaks SSH for whatever reason, at least I'm logged on and can fix it. It would be difficult to fix if the update happened automatically. Some downsides are documented here: https://wiki.ubuntu.com/AutomaticUpdates and elsewhere online. -- Jesse
Hate to tell you this, but both problems are still a reality whether the machine reboots automatically or not. If I manually reboot for a kernel update that breaks network access, I still won't have SSH. And if I reboot manually after every kernel update, my stability will still suffer. On Oct 22, 2016 8:26 PM, "Jesse V" <kernelcorn@torproject.org> wrote:
On 10/22/2016 08:02 PM, Tristan wrote:
Would it be acceptable to configure unattended-upgrades to automatically reboot the system when required? I already have it configured to check for and install all updates to Ubuntu and Tor once a day, but I still need to manually reboot to apply kernel upgrades.
This is not a good idea. For one, the new kernel could break your network connection, which happened to me this morning after I rebooted a personal machine. Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day.
You also need to be careful with automatically installing updates in a production environment, as one of them could break something and it would be some time before you noticed. I prefer to review the updates before I install them and watch the apt-get log in case there are any issues. Debian systems may even show you the changelogs. If an update breaks SSH for whatever reason, at least I'm logged on and can fix it. It would be difficult to fix if the update happened automatically.
Some downsides are documented here: https://wiki.ubuntu.com/AutomaticUpdates and elsewhere online.
-- Jesse
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day.
Unattended-Upgrade::Automatic-Reboot "true"; Does not reboot your machine "once a day", it reboots when a new kernel requires a reboot. Which on Debian stable / Ubuntu LTS is far from being a daily event. And the frequency of reboots actually should not differ compared to manual reboots.
I know some people using this for applying kernel updates without rebooting, but don't know how good it is: https://www.cloudlinux.com/all-products/product-overview/kernelcare On 23 October 2016 at 09:16, nusenu <nusenu@openmailbox.org> wrote:
Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day.
Unattended-Upgrade::Automatic-Reboot "true";
Does not reboot your machine "once a day", it reboots when a new kernel requires a reboot. Which on Debian stable / Ubuntu LTS is far from being a daily event. And the frequency of reboots actually should not differ compared to manual reboots.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi folks, I think this is a very extreme and unnecessary solution. While it is good to keep relays up, this may be unreliable. It is good to perform maintenance regularly, and reboots are often best. Also, it appears to be proprietary technology. I would not advise proprietary technology on a Tor relay as it opens up a whole other can of worms, who controls the software etc. Can people really not afford to reboot once a month or similar? Uptime is good but the only reliable way to apply kernel updates has always been reboots. Restarting also can apply updates to certain system services as well, if I am correct. -- D On 23 October 2016 09:42:38 BST, Jonathan Baker-Bates <jonathan@bakerbates.com> wrote:
I know some people using this for applying kernel updates without rebooting, but don't know how good it is:
https://www.cloudlinux.com/all-products/product-overview/kernelcare
On 23 October 2016 at 09:16, nusenu <nusenu@openmailbox.org> wrote:
Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day.
Unattended-Upgrade::Automatic-Reboot "true";
Does not reboot your machine "once a day", it reboots when a new kernel requires a reboot. Which on Debian stable / Ubuntu LTS is far from being a daily event. And the frequency of reboots actually should not differ compared to manual reboots.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Rebooting also makes sure updates are applied correctly. If a shared library updates, the old version is still in use until whatever program using it stops, and the new version is loaded on the next run. On Oct 23, 2016 10:07 PM, "Duncan Guthrie" <dguthrie@posteo.net> wrote:
Hi folks,
I think this is a very extreme and unnecessary solution. While it is good to keep relays up, this may be unreliable. It is good to perform maintenance regularly, and reboots are often best. Also, it appears to be proprietary technology. I would not advise proprietary technology on a Tor relay as it opens up a whole other can of worms, who controls the software etc. Can people really not afford to reboot once a month or similar? Uptime is good but the only reliable way to apply kernel updates has always been reboots. Restarting also can apply updates to certain system services as well, if I am correct.
-- D
On 23 October 2016 09:42:38 BST, Jonathan Baker-Bates < jonathan@bakerbates.com> wrote:
I know some people using this for applying kernel updates without rebooting, but don't know how good it is:
https://www.cloudlinux.com/all-products/product-overview/kernelcare
On 23 October 2016 at 09:16, nusenu <nusenu@openmailbox.org> wrote:
Second, you will reduce the uptime and stability of your relay, thus it will lose consensus weight if you reboot the machine once a day.
Unattended-Upgrade::Automatic-Reboot "true";
Does not reboot your machine "once a day", it reboots when a new kernel requires a reboot. Which on Debian stable / Ubuntu LTS is far from being a daily event. And the frequency of reboots actually should not differ compared to manual reboots.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
------------------------------
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I don't know if it's possible to load a new kernel without rebooting... But I think people who doesn't want to reboot because feared of a bad reboot, loose SSH or anything else... If OS's teams are updating a system for security, I prefer a bad reboot (backups are done before!) than a system with a lot of security holes, sick of botnets or sending spams every seconds, a Tor relay controlled by bad hands... :s On other servers (debian/raspbian) I usually use "apticron", it sends everyday mails to root or another admin@domain.com, with summary about updates available for the host.
but I still need to manually reboot to apply kernel upgrades.
-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
Would it be acceptable to configure unattended-upgrades to automatically reboot the system when required? I already have it configured to check for and install all updates to Ubuntu and Tor once a day, but I still need to manually reboot to apply kernel upgrades.
I think Unattended-Upgrade::Automatic-Reboot "true"; is a good practice for (lazy) tor servers operators to keep running patched kernels automatically, since automation usually reduces the time until the system is patched (and if necessary rebooted) - even if the operator does not follow security announce mailing lists.
participants (9)
-
Duncan Guthrie -
I -
Jason Jung -
Jesse V -
Jonathan Baker-Bates -
Nenad Marjanovic -
nusenu -
Petrusko -
Tristan