101–110 of 186 posts
Earlier quoted context omitted.
> JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.
It also consumes lots of CPU to scan memory this way, so just be on the lookout for webpages consuming lots of unexpected CPU.
I use AWS instances (multi-tenant). I understand that by now AWS hypervisors have been patched. Does that fully protect my unpatched AWS instances from this CPU-level issues? If not, is there any way to protect my AWS instance from a rogue unpatched attacker instance running on the same hypervisor? In other words, with the current CPUs deployed at AWS, will it be possible for an attacker to simply launch an unpatched…
No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.
Quick sketch: disable EPT and go back to shadow paging. Maintain a third page table with any kernel pages unmapped. Invisibly swap between on syscalls.
Earlier quoted context omitted.
Almost all Linux Mint users "piggy back" on top of the most recent Ubuntu Long Term Support (LTS) release. Currently the most recent Ubuntu LTS is 16.04 and by default it uses the 4.4 Linux kernel. There are patches for the 4.4 kernel from the kernel.org team and the Ubuntu team are testing and integrating these patches. The most recent updates from the Ubuntu team about Meltdown and Spectre is available from this UR…
So, there is NO kernel update available for Ubuntu 16.04 at this time.
With so much going on - is there a way in linux to know whether my system is patched or not? Similar to the powershell script for Windows?
A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...
dmesg -H | grep 'page tables isolation'
[ +0.000000] Kernel/User page tables isolation: enabled
grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!"
Unpatched!
cat /proc/cpuinfo | grep pti
fpu_exception : yes
uname -a
Linux host 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
EDIT: Maybe this is because it is Xen guest. Do I need pti on a XEN guest if the host is fully patched?
Reading between the lines, it seems this is a pretty colossal fuckup by Intel; both in terms of the bug but especially how it was handled.
What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this…
I share your concern. Based on my admittedly loose understanding, although the Spectre vulnerability is "more difficult" to exploit, I suspect it's a matter of time before exploits become more common. And the Spectre vulnerability is the one that requires a BIOS/firmware update. So that's a bit alarming for me since at least one of my several workstations is using a 5+ year old desktop board (an Intel board, ironical…
https://wiki.archlinux.org/index.php/microcode
https://wiki.debian.org/Microcode
Also, directly from Intel:
While the regular approach to getting this microcode update is via a BIOS update, Intel realizes that this can be an administrative hassle. The Linux operating system has a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system.
Source: https://downloadcenter.intel.com/download/27337/Linux-Proces...
Apple probably delivers them through EFI updates, but of course, getting updated EFI firmware from Apple was never a problem.
FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…
So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course).
As to whether Red Hat has kernel developers, of course it does. :-) Much of Red Hat's popularly began as a Linux distribution. If you're curious, the LWN publishes statistics about who contributes to the Linux kernel, and the most recent one is for the 4.11 development cycle -- https://lwn.net/Articles/720336/
(Disclosure: /me is a Red Hatter.)
This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.
It's not supposed to install via "apt upgrade", as that command won't pull in new packages or remove packages. Unlike most, kernel packages can co exist so they are all separate packages. Thus need the extra "apt-get dist-upgrade" or "apt full-upgrade" variants as they are new dependencies.
I don't see why "apt upgrade" wouldn't install the new kernel. It's hard to tell what when wrong without knowing any details.
Anyway, if apt decided to hold back a package for some reason, most of the time you should be able to install it with "apt(-get) install". Do not install packages with dpkg unless you know what you're doing.
Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?
Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.
Does that mean that we are soon going to be vulnerable to remote exploits via WASM as well? Do mitigation attempts such as reducing the JavaScript timing resolution aslo apply to WASM?
FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…
There's such a thing called: 'embargo period', wherein CVEs are (in most cases) responsibly disclosed to various parties---including several Linux distributions---much ahead than the general public, to coordinate security errata. So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course). As to whether Red Hat has kernel developers…
And, correct me if I'm wrong, but apparently calling Linus Torvalds and Greg KH the general public (as far as Spectre and its (poor for now) mitigations are concerned) is the new norm. I'm not sure of what the community will think of that. And of the corporate actors involved in that curious choice.