Date: Mon, 8 Jan 2018 18:15:45 +0100 From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= <fernando.apesteguia@gmail.com> To: Baho Utot <baho-utot@columbus.rr.com> Cc: Aryeh Friedman <aryeh.friedman@gmail.com>, User Questions <freebsd-questions@freebsd.org> Subject: =?UTF-8?B?UmU6IE1lbHRkb3duIOKAkyBTcGVjdHJl?= Message-ID: <CAGwOe2aZr5==KFdKb9SHLh9YRy5VCpxPN3d5AY1bLed5o5EV2w@mail.gmail.com> In-Reply-To: <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com> References: <f9cc484e-be92-7aff-52fe-38655e85dbaa@columbus.rr.com> <CAH78cDqPnOUGoU=6x-BiugnpjmjYcd=CZS3fSNaX5tq-Uvma7g@mail.gmail.com> <bc9ad15b-a718-b901-76fa-bc43ce0c1f1a@columbus.rr.com> <3AECDC7F-8838-4C09-AC7F-117DFBAA326C@sigsegv.be> <20180108085756.GA3001@c720-r314251> <CAGBxaXnSRwtS=mbdsePyKvyZjTpu1tvo2O61SW60yQfdDJH4gA@mail.gmail.com> <48211515-cc6b-522b-ccd2-4d0c1f6a2072@columbus.rr.com> <CAGBxaXm=6NbZ%2Bcz6WGB7YY7NT_%2BxOhdxb17ORTsQs5e7RvqKaQ@mail.gmail.com> <44279dcb-7b15-865a-ca71-938b3832d0e7@columbus.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 8, 2018 at 1:53 PM, Baho Utot <baho-utot@columbus.rr.com> wrote= : > > > On 1/8/2018 7:37 AM, Aryeh Friedman wrote: >> >> >> >> On Mon, Jan 8, 2018 at 7:28 AM, Baho Utot <baho-utot@columbus.rr.com >> <mailto:baho-utot@columbus.rr.com>> wrote: >> >> >> >> On 1/8/2018 4:15 AM, Aryeh Friedman wrote: >> >> On Mon, Jan 8, 2018 at 3:57 AM, Matthias Apitz <guru@unixarea.de >> <mailto:guru@unixarea.de>> wrote: >> >> As I side note, and not related to FreeBSD: My Internet >> server is run by >> some webhosting company (www.1blu.de <http://www.1blu.de>), >> >> they use Ubuntu servers and since >> yesterday they have shutdown SSH access to the servers >> argumenting that >> they want >> protect my (all's) servers against attacks of Meltdown and >> Spectre. >> >> Imagine, next time we have to shutdown all IOT gadgets... >> >> >> >> Not always possible for things like medical test >> equipment/devices. For >> example I maintain a specialized EMR for interacting with Dr. >> prescribed >> remote cardiac monitors. Having those off line is not an >> option since >> they are used to detect if the patient needs something more >> serious like a >> pace maker (also almost always a IoT device these days) surgery. >> >> The actual monitoring is done on Windows and was attacked by some >> ransomeware via a bit coin miner that somehow installed it >> self. Since >> all the users claim that they don't read email/upload/download >> executables >> or any other of the known attack vectors this leaves something >> like >> Meltdown or Spectre. We have also detected issues on the >> CentOS that has >> the non-medical corporate site on it. The only machine left on >> touched on >> the physical server (running some bare metal virtualization >> tool) is the >> FreeBSD machine that runs the actual EMR we wrote. >> >> TL;DR -- It seems Linux and Windows already have issues with >> these holes >> but I have seen little to no evidence that FreeBSD (when run as >> a host). >> In general when ever any virtualization issue (like the bleed >> through on >> Qemu last year) comes up FreeBSD is the one OS that seems to be >> immune >> (thanks to good design of the OS and bhyve). This is the main >> reason why >> I chose FreeBSD over Linux as the reference host for PetiteCloud. >> >> >> This is not operating system specific, read the papers on theses >> two. it attacks the cpu, usally through a JIT >> >> >> Please learn a little OS design theory before making insane claims. >> Specifically it *ONLY* effects OS's that rely on the specific CPU >> architecture (vs. a generic one). Namely if you strictly partition the page >> table between userland and kernel space (which xxxBSD has always done an= d >> Linux has not) and don't use any CPU specific instructions to do so (except >> for protected vs. unprotected mode in the original 386 design FreeBSD does >> not do this while yet again microslut and linux do). >> >> For more info go read the more technical thread then here in -hackers@ and >> -current@. > > > > Go read the papers Spectre and Meltdown. > This attacks Intel and Arm processors, AMD processors seems to not have the > issue. Intel is issuing new firmware for their processors. > Why is does then Apple have the problem as well? About AMD, they seem to be affected by at least two variants of these attacks: https://www.amd.com/en/corporate/speculative-execution Cheers > > From the papaer > > Modern processors use branch prediction and speculative > execution to maximize performance. For example, if > the destination of a branch depends on a memory value > that is in the process of being read, CPUs will try guess > the destination and attempt to execute ahead. When the > memory value finally arrives, the CPU either discards or > commits the speculative computation. Speculative logic > is unfaithful in how it executes, can access to the victim=E2=80=99s > memory and registers, and can perform operations with > measurable side effects. > Spectre attacks involve inducing a victim to speculatively > perform operations that would not occur during > correct program execution and which leak the victim=E2=80=99s > confidential information via a side channel to the adversary. > This paper describes practical attacks that combine > methodology from side channel attacks, fault attacks, > and return-oriented programming that can read arbitrary > memory from the victim=E2=80=99s process. More broadly, the > paper shows that speculative execution implementations > violate the security assumptions underpinning numerous > software security mechanisms, including operating system > process separation, static analysis, containerization, > just-in-time (JIT) compilation, and countermeasures to > cache timing/side-channel attacks. These attacks represent > a serious threat to actual systems, since vulnerable > speculative execution capabilities are found in microprocessors > from Intel, AMD, and ARM that are used in billions > of devices. > > And: > > Abstract > The security of computer systems fundamentally relies > on memory isolation, e.g., kernel address ranges are > marked as non-accessible and are protected from user > access. In this paper, we present Meltdown. Meltdown > exploits side effects of out-of-order execution on modern > processors to read arbitrary kernel-memory locations > including personal data and passwords. Out-of-order > execution is an indispensable performance feature and > present in a wide range of modern processors. The attack > is independent of the operating system, and it does not > rely on any software vulnerabilities. Meltdown breaks > all security assumptions given by address space isolation > as well as paravirtualized environments and, thus, > every security mechanism building upon this foundation. > On affected systems, Meltdown enables an adversary to > read memory of other processes or virtual machines in > the cloud without any permissions or privileges, affecting > millions of customers and virtually every user of a > personal computer. We show that the KAISER defense > mechanism for KASLR [8] has the important (but inadvertent) > side effect of impeding Meltdown. We stress > that KAISER must be deployed immediately to prevent > large-scale exploitation of this severe information leakage. > > > One of the central security features of today=E2=80=99s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other=E2=80=99s memories > and prevent user applications from reading or writing > kernel memory. This isolation is a cornerstone of our > computing environments and allows running multiple applications > on personal devices or executing processes of > multiple users on a single machine in the cloud. > On modern processors, the isolation between the kernel > and user processes is typically realized by a superviOne of the central > security features of today=E2=80=99s operating > systems is memory isolation. Operating systems ensure > that user applications cannot access each other=E2=80=99s memories > and prevent user applications from reading or writing > kernel memory. This isolation is a cornerstone of our > computing environments and allows running multiple applications > on personal devices or executing processes of > multiple users on a single machine in the cloud. > On modern processors, the isolation between the kernel > and user processes is typically realized by a supervisor > bit of the processor that defines whether a memory > page of the kernel can be accessed or not. The basic > idea is that this bit can only be set when entering kernel > code and it is cleared when switching to user processes. > This hardware feature allows operating systems to map > the kernel into the address space of every process and > to have very efficient transitions from the user process > to the kernel, e.g., for interrupt handling. Consequently, > in practice, there is no change of the memory mapping > when switching from a user process to the kernel > novel attack that allows overcoming memory isolation > completely by providing a simple way for any user process > to read the entire kernel memory of the machine it > executes on, including all physical memory mapped in > the kernel region. Meltdown does not exploit any software > vulnerability, i.e., it works on all major operating > systems. Instead, Meltdown exploits side-channel information > available on most modern processors, e.g., modern > Intel microarchitectures since 2010 and potentially > on other CPUs of other vendors. > > Notice: > > Meltdown does not exploit any software vulnerability, i.e., it works on all > major operating systems. > > Your turn > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGwOe2aZr5==KFdKb9SHLh9YRy5VCpxPN3d5AY1bLed5o5EV2w>