Skip site navigation (1)Skip section navigation (2)
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>