Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Listen to your VPS Neighbours on intel Servers
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Listen to your VPS Neighbours on intel Servers

mrTommrTom Member

Ever wondered what those noisy Neighbours are doing on your VPS Host?

Now you can find out using intels latest vulnerability "Zombieload". It allows processes to listen to other processes on the same core, which is maybe not so problematic on PCs but more so on shared servers like VPS hosts.

_
"While programs normally only see their own data, a malicious program can exploit the fill buffers to get hold of secrets currently processed by other running programs. These secrets can be user-level secrets, such as browser history, website content, user keys, and passwords, or system-level secrets, such as disk encryption keys."_

It was discovered by the guys who uncovered Spectre:
https://zombieloadattack.com/
https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html

«13

Comments

  • Adam1Adam1 Member

    I like the names they give them, I'd like the next few to be called crustexploder and honeybottom

  • NeoonNeoon Community Contributor, Veteran
    edited May 2019

    That looks bad, well now we are fucked.

    The safest workaround to prevent this extremely powerful attack is running trusted and untrusted applications on different physical machines.

    If this is not feasible in given contexts, disabling Hyperthreading completely represents the safest mitigation. This does not, however, close the door on attacks on system call return paths that leak data from kernel space to user space.

    Just get yourself cheap ARM box, for small stuff.

    Thanked by 1uptime
  • AmitzAmitz Member

    Now that's gross... :-/

    Thanked by 1netomx
  • ulayerulayer Member, Host Rep

    It would be best to just disable hyperthreading altogether on sensitive hypervisors at this point. I did this on my Qubes OS workstation when Foreshadow was revealed. Hypervisors are still vulnerable to Foreshadow with SMT (hyperthreading) enabled.

  • edfoxedfox Member

    I guess my plan to migrate everything to VPS is gone.

    Lmao Intel, thank god last time i used an Intel processor was in 2007

  • uptimeuptime Member

    Turn up the Eagles

  • FHRFHR Member, Host Rep

    RedHat article https://access.redhat.com/security/vulnerabilities/mds

    Qemu/libvirt/microcode/kernel patches are in repos. Reboot is required.

    Thanked by 1ulayer
  • NeoonNeoon Community Contributor, Veteran

    @FHR said:
    RedHat article https://access.redhat.com/security/vulnerabilities/mds

    Qemu/libvirt/microcode/kernel patches are in repos. Reboot is required.

    Anyone ran benchmarks on these?
    How much %% is that gonna cost?

  • Host performance and overall availability of resources will be impacted.

    Some low end boxes will perform badly :neutral:

  • deankdeank Member, Troll

    How does AMD's SMT differ from Intel's HT?

  • ulayerulayer Member, Host Rep

    @deank said:
    How does AMD's SMT differ from Intel's HT?

    Some different sorcery!

  • FHRFHR Member, Host Rep
    edited May 2019

    @Neoon said:

    @FHR said:
    RedHat article https://access.redhat.com/security/vulnerabilities/mds

    Qemu/libvirt/microcode/kernel patches are in repos. Reboot is required.

    Anyone ran benchmarks on these?
    How much %% is that gonna cost?

    Virtualization is going to be affected a lot. For one, disabling hyper threading actually brings quite a bit of performance penalty on systems with many VMs. Note that this is mainly true for KVM and doesn't matter that much for OpenVZ. Performance hit from disabling HT alone can be as much as… 50% in cloud KVM environments (those numbers are from Red Hat).

    RedHat:

    The MDS CVE mitigations have shown to cause a performance impact. 
    The impact will be felt more in applications with high rates of
    user-kernel-user space transitions.
    For example system calls, NMIs, and interrupts.
    

    ˆˆ So basically virtualization and network stuff.

    Although there is no way to say what the impact will be for any given workload, in our testing we measured:
    
    Applications that spend a lot of time in user mode tended to show the smallest slowdown, usually in the 0-5% range.
    Applications that did a lot of small block or small packet network I/O showed slowdowns in the 10-25% range.
    Some microbenchmarks that did nothing other than enter and return from user space to kernel space showed higher slowdowns.
    
  • donlidonli Member

    That's it - from now on I'm only buying CPUs with reprogrammable microcode.

  • deankdeank Member, Troll

    It's more like we need to move on from x86.

  • NeoonNeoon Community Contributor, Veteran

    @deank said:
    It's more like we need to move on from x86.

    Well, Raspberry Pi Zero costs 5$, W costs 10$ and you can order already cheap ARM boards from china for about 10$.

    They draw you like 5$/y on power, for small applications.

  • donli said: reprogrammable microcode

    Can hacker program microcode remotely?

  • But, but, but...

    But Intel said Tuesday there's no evidence of anyone exploiting it outside of a research laboratory. "Doing so successfully in the real world is a complex undertaking," Jorgensen said.

  • edited May 2019

    system-level secrets, such as disk encryption keys

    damn..., Intel, you are such a disappointment.

    AMD stock, will keep rising.

    Thanked by 1netomx
  • donlidonli Member

    @greattomeetyou said:

    donli said: reprogrammable microcode

    Can hacker program microcode remotely?

    No, it'll have to be loaded in from 8" floppy disk (like on the Dec Vax 11/780).

  • AnthonySmithAnthonySmith Member, Patron Provider

    For Fucks Sake....

    Well that is that then, I will not stand up another intel server in the short to medium term, probably long term.

    I am tired of your shit intel.

  • edited May 2019

    AnthonySmith said: Well that is that then, I will not stand up another intel server in the short to medium term, probably long term.

    Will AMD have another hidden bomb(s) waiting to go off?

    Really hard to make investment decision. May have to strike deal with supplier that if these kinds of flaws (require major slow down because of patching) were to be discovered, they need to recall or provide relief on new purchases. So, Intel/AMD will know it is serious.

  • AnthonySmithAnthonySmith Member, Patron Provider

    greattomeetyou said: Really hard to make investment decision

    Its not that hard, intel = for sure swiss cheese, amd = might be but with less holes (so far) and not a lot of difference for end user real world performance.

  • pikepike Veteran

    Still Intel > AMD lol

  • AnthonySmithAnthonySmith Member, Patron Provider

    pike said: Still Intel > AMD lol

    oh ok then, when you put it like that, i had not considered the greater than+lol perspective!

  • @Hetzner_OL You installed MDS patch?

  • pikepike Veteran
    edited May 2019

    I'm not a provider :)

  • So work around would be to disable Hyper Threading on all Intel CPUs to mitigate this?

  • LayerVPS said: So work around would be to disable Hyper Threading on all Intel CPUs to mitigate this?

    Apply patches?

    FHR said: RedHat article https://access.redhat.com/security/vulnerabilities/mds

    Qemu/libvirt/microcode/kernel patches are in repos. Reboot is required.

  • psb777psb777 Member

    Is it really a serious issue for cloud hosting?

    In the section "Cross-VM Covert Channel" of their paper, they used a highly optimized "sender" that repeatedly loads specially crafted messages from L1 cache to registers, yet they only achieved 1.99kbit/s transmission rate. In a realistic cloud hosting environment, you have to actively "listen" (sample) for very long and filter out lots of noises to have anything remotely interesting.

Sign In or Register to comment.