81–90 of 218 posts
At Appcanary, we're thinking about opening up our vulnerability database to be browsable and searchable by the public. If you're not sure which version has the patch for this vulnerability in your distro, here's what we know: Ubuntu - https://appcanary.com/vulns/45984 Debian - https://appcanary.com/vulns/45983 Amazon Linux - https://appcanary.com/vulns/45992 Centos - no patch yet If you found this useful, please let…
Earlier quoted context omitted.
It looks like my kernel updates are being held back: ~ $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: ffmpeg libva1 linux-generic linux-headers-generic linux-image-generic 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. The newest available version of linux-image-gene…
Most of my 16.04 instances that are configured to auto-update have installed the new kernel already.
After things randomly broke 3 times I decided not to add the backports PPA, and to do manual updates every now and then.
Earlier quoted context omitted.
..because you don't know the difference between upgrade and dist-upgrade. use dist-upgrade or just explicitly install those packages.
No, dist-upgrade would be 14.04 -> 16.04. I don't want 16.04; I want to stay on 14.04.
That is a reasonable assumption, but it is incorrect. Check the man page for apt-get.
On Ubuntu systems, the command to upgrade to a new release is "do-release-upgrade". Insanity, but there it is.
Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds Date: Thu Oct 13 13:07:36 2016 -0700 mm: remove gup_flags FOLL_WRITE games from __get_user_pages() commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() ra…
Seems to be fixed by this commit (in 4.8.3). commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds Date: Thu Oct 13 13:07:36 2016 -0700 mm: remove gup_flags FOLL_WRITE games from __get_user_pages() commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() ra…
A link would be appreciated. The text is truncated at N columns on mobile.
If you have an iPhone you can scroll horizontally even if it doesn't look like you can (though I am also annoyed by HN truncating the text)
It's probably the most serious Linux local privilege escalation ever. Look, the Azimuth people have forgotten more about reliable exploit development than I have ever known, but, no, as stated, this is clearly not true. Not long ago, pretty much all local privesc bugs were practically 100% reliable. What I think they mean to say is that this is unusually reliable for a kernel race. I still think, though, that the rig…
Earlier quoted context omitted.
Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with…
I know what everything else is, but what is CFI? An attempt at googling came up with results that didn't make any sense right away.
There's more to it, but that's the flavor of it.
Earlier quoted context omitted.
Most of my 16.04 instances that are configured to auto-update have installed the new kernel already.
I've set up cron jobs in the past which automatically ran apt-get update && apt-get upgrade, but it's sometimes caused things to unpredictably break, especially when you have the backports PPA. After things randomly broke 3 times I decided not to add the backports PPA, and to do manual updates every now and then.
See also: https://help.ubuntu.com/lts/serverguide/automatic-updates.ht...
Earlier quoted context omitted.
You said it: If you are not explicitly on the business of providing external access to your machine, the privesc isn't your problem (it's a problem, and it's bad, though), it's the fact that anybody could exploit the privesc in the first place.
no, because a bug like this turns any code execution exploit into remote root...
Earlier quoted context omitted.
I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
> Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). This assertion confuses me. I use fail2ban on boxes I have key-only ssh configured for. Are you aware fail2ban works for services other than ssh? If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them. I also get much (much!) cleaner logs thanks to fail2ban.
I suspect that you're confusing fail2ban and port-knocking (or using fail2ban as a port-knocker).
The point of fail2ban is to prevent an attacker from brute-forcing your server. In a key-only config, the chances of getting brute forced is smaller (by a few orders of magnitude) than getting hit by an asteroid and having the server get hit by an asteroid, so fail2ban doesn't really help.
_In theory_, the same would be true for port-knocking.
However, in practice, sshd can have security holes which a malicious scanner could exploit. And while port-knocking doesn't help against a determined attacker (it's subject to MITM, replay-attacks), it does help with defense-in-depth.