SystemZ | 2018-01-18 22:26:49 UTC | #1
Grupa badaczy odkryła bardzo poważne błędy powiązane z działaniem procesorów, nawet tych najnowszych.
Z tego powodu wszystkie usługi świadczone przez lvlup wymagają pewnych działań aby móc powstrzymać ewentualne udane ataki korzystające z wykrytych luk.
Generalnie znalezione luki są dość skomplikowane dlatego tym razem nie będę podejmować się dokładnego opisu jak dokładnie to działa. Skupię się na tym aby zabezpieczyć od strony usługodawcy to co jest możliwe.
Są to dokładnie:
- CVE-2017-5754 (Meltdown)
- CVE-2017-5753 (Spectre wariant pierwszy)
- CVE-2017-5715 (Spectre wariant drugi)
Niestety w przypadku każdej usługi będzie wymagany restart węzłów.
Łatki są przygotowywane w przyspieszonym tempie co powoduje że są czasami wadliwe co więc może być potrzeba kilkukrotnych instalacji oraz restartów.
| Usługa | CVE-2017-5754 (Meltdown) | CVE-2017-5753 (Spectre I) | CVE-2017-5715 (Spectre II) |
|---|---|---|---|
| VPS KVM | :whitecheckmark: | :whitecheckmark: | :whitecheckmark: |
| VPS OpenVZ | :x: | :x: | :x: |
| Hosting Minecraft | :x: | :x: | :x: |
| Hosting WWW | :whitecheckmark: | :whitecheckmark: | :warning: |
:whitecheckmark: - załatano
:warning: - częściowo załatane
:x: - nadal podatne
Post ten będzie edytowany aby informować o sprawie na bieżąco.
Próbne restarty na węźle KVM n67
Panel v3 zostaje zmodyfikowany aby zmniejszyć dolegliwości po restartach węzłów
https://forum.lvlup.pro/t/panel-klienta-v3-0-rc/4683/7?u=systemz
Rozpoczęcie restartów na wszystkich węzłach KVM, po 1, 2 lub 3 maszynach w jednym momencie
Wszystkie węzły KVM są już zabezpieczone przed CVE-2017-5754 (Meltdown) oraz częściowo przed CVE-2017-5715 (Spectre wariant drugi)
Węzeł n39 nie odpowiada po restarcie, trwa diagnoza problemu.
Węzeł n39 działa prawidłowo po hard reboocie.
Trwa restart hostingu WWW.
Hosting WWW ma już łatkę dla CVE-2017-5754 (Meltdown), CVE-2017-5753 (Spectre wariant pierwszy) oraz częściowo przed CVE-2017-5715 (Spectre wariant drugi)
VPS OpenVZ a także MC które działa na OpenVZ wymagają łatek które są nadal przygotowywane przez zewnętrzną firmę Cloudlinux w ramach usługi Kernelcare, należy czekać na ich wydanie które przy obecnym ich szacunku to w najlepszym wypadku piątek czyli 12.01.2018, realistyczny jest poślizg do następnego tygodnia
https://cloudlinux.com/cloudlinux-os-blog/entry/intel-cpu-bug-kernelcare-and-cloudlinux
Cloudlinux zaczyna wypuszczać łatkę na CVE-2017-5753 (Spectre I).
Ciężko oszacować kiedy trafi ona na węzły OpenVZ lecz sądzę że powinno to mieć miejsce jutro
Zainstalowane zostały nowe jądra dla węzłów KVM które powinny załatać całkowicie CVE-2017-5753 (Spectre I) i CVE-2017-5715 (Spectre wariant drugi)
Czas restartu węzłów aby zastosować łatki jest w trakcie ustaleń
Prewencyjny restart Hostingu WWW po instalacji nowego jądra
Restarty węzłów KVM zostały zaplanowane pomiędzy 22:30 a 23:30 tego samego dnia.
Węzły KVM są już odporne na CVE-2017-5754 (Meltdown) CVE-2017-5753 (Spectre I) i CVE-2017-5715 (Spectre wariant drugi)
helczyna | 2018-01-10 14:28:48 UTC | #2
Jeśli da się określić przewidywany termin załatania luk?
SystemZ | 2018-01-10 14:33:14 UTC | #3
Obecnie nie da się określić tej daty jeśli mówimy o 100% załataniu wszystkich trzech podatności.
Dostawcy sprzętu i oprogramowania nadal nie skończyli pracy nad tym.
Nieznajomy11 | 2018-01-10 14:36:06 UTC | #4
Dostałem powiadomienie, że serwer VPS mi nie odpowiada. Myślę - awaria, chociaż w sumie raczej update na dziury w intelu.* Jakże inaczej. =)
*chwilę potem dostałem powiadomienie, że już up.
SystemZ | 2018-01-10 14:38:09 UTC | #5
Restart węzła licząc ponownie włączenie wszystkich VM nie powinien zająć dłużej niż 5-10 min.
SystemZ | 2018-01-10 14:50:34 UTC | #6
helczyna | 2018-01-10 16:15:14 UTC | #7
Czyli węzły OpenVZ zostaną zrestartowane? Czy firma Cloudlinux zrobi łatki bez wymaganego restartu?
SystemZ | 2018-01-10 17:08:50 UTC | #8
Wszystkie łatki Kernelcare jakie wyszły do tej pory nie wymagały restartu gdyż jest to jedna z głównych cech tego produktu - łatanie kernela bez restartu. Należy jednak pamiętać że zmiany w jądrze są bardzo duże i nie można obiecać że restart nie będzie wymagany. Jest jeszcze kwestia microcode czyli w uproszczeniu oprogramowania procesora które też wymaga aktualizacji a najczęściej taka aktualizacja ma miejsce podczas startu systemu.
bopke | 2018-01-12 20:54:31 UTC | #9
https://ithardware.pl/aktualnosci/latkiinteladlaspectremeltdownsamezawierajapowaznyblad-4891.html
Zabawa z restartami zacznie się teraz od nowa?
tirex | 2018-01-14 00:38:48 UTC | #10
Czy te łatki mogły przyczynić się do powolnego działania /dev/random?
SystemZ | 2018-01-14 13:15:12 UTC | #11
[quote=”bopke, post:9, topic:4903”]
Zabawa z restartami zacznie się teraz od nowa?
[/quote]
Generalnie to było do przewidzenia.
Luki są bardzo poważne i wymagają bardzo dużo zmian które normalnie by wymagały pewnie miesięcy prac a tutaj wszystko starają się zrobić w dni/tygodnie co wiadomo powoduje spadek jakości kodu :unamused:
[quote=”tirex, post:10, topic:4903, full:true”]
Czy te łatki mogły przyczynić się do powolnego działania /dev/random?
[/quote]
Generalnie jeśli dobrze rozumiem chociaż część zmian to pewne zapytania do kernela są dużo wolniejsze.
Masz może jakieś konkretne metryki z tym związane dla porównania?
bopke | 2018-01-14 13:33:42 UTC | #12
[quote=”SystemZ, post:11, topic:4903”]
Luki są bardzo poważne i wymagają bardzo dużo zmian które normalnie by wymagały pewnie miesięcy prac
[/quote]
O ile dobrze pamiętam to Google podało, że Intel dowiedział się bodaj w czerwcu, mieli czas na prace nad łatkami :thinking:
Timo | 2018-01-14 13:49:33 UTC | #13
Czym by poskutkowało, dla takiego VPSowca jak ja, z serwerem załóżmy TSa, stronką www i sinusbotami, nie podejmowanie żadnych działań co do tych łatek?
Nieznajomy11 | 2018-01-14 14:23:51 UTC | #14
Tutaj chodzi bardziej o hosta, nie o guesta. VPS (guest) bez łatek na gospodarzu (hoście) jest w stanie odczytywać pamięć innych maszyn wirtualnych.
Taki pierwszy lepszy przykład: istnieje ryzyko, że vps A odczyta pamięć gospodarza, która jest akurat przydzielona do vpsa B, a on ma tam proces redisa w którym trzyma hasła swojej aplikacji lub inne dane.
W przypadku komputerów domowych działa to podobnie, lecz między aplikacjami. Aplikacja bez uprawnień administratora będzie w stanie uzyskać dostęp do pamięci innych aplikacji.
Bez aktualizowania przeglądarki mogłoby być to nawet możliwe z poziomu JavaScript.
SystemZ | 2018-01-14 17:49:54 UTC | #15
[quote=”bopke, post:12, topic:4903”]
O ile dobrze pamiętam to Google podało, że Intel dowiedział się bodaj w czerwcu, mieli czas na prace nad łatkami :thinking:
[/quote]
Miałem na myśli osoby powiązane z łatkami dla dystrybucji itp. Mój błąd, nie zerknąłem dobrze.
Tak, jak najbardziej, Intel mocno spał jak dla mnie :stuckouttongue:
bopke | 2018-01-14 18:08:02 UTC | #16
intel taki śpioch, że znając ten błąd wydał kolejne procesory, które nadal są nań podatne
Oby dostali mocno po kieszeni za to
SystemZ | 2018-01-18 13:00:35 UTC | #17
Są nowe łatki, wymagają restartu węzłów KVM.
Jakie godziny byłyby najmniej uciążliwe dla tej operacji?
Rozumiem że piątek wieczór to najgorszy możliwy termin jaki się da więc chcę go uniknąć.
Restart w sobotę czy niedzielę to też sądzę niezbyt dobry pomysł.
Na obecną chwilę sądzę że czwartek (dziś) coś około 23:00 lub piątek coś miedzy 10:00 a 12:00 byłby dla większości okej. Dajcie znać jakie są wasze potrzeby a postaram się dostosować.
luxDev | 2018-01-18 13:29:51 UTC | #18
[quote=”SystemZ, post:17, topic:4903”]
Jakie godziny byłyby najmniej uciążliwe dla tej operacji?
[/quote]
Sądzę że dzisiaj (czwartek) jest najlepszą opcją późniejszym wieczorem lub piątek rano, weekend odpada raczej 8)
Timo | 2018-01-18 13:37:32 UTC | #19
Jeśli restart na dniach, to wyłączenie dzisiaj w późnej nocy.
Pantoflarz | 2018-01-18 14:03:11 UTC | #20
sądzę że dziś w okolicach 23.00 lub poniedziałek nad ranem - wtedy też mało osób jest :)
SystemZ | 2018-01-18 14:06:42 UTC | #21
W takim razie wygląda na to że dziś około 23:00 to najlepszy termin.
Czyli wstępnie ustalone :slight_smile:
Jestem w trakcie przygotowywania wiadomości email dla klientów KVM tak aby poinformować przed tym faktem jak najwięcej osób. Chcę uniknąć niespodzianek dla klientów gdyż sygnalizowaliście mi że to by się przydało.
SystemZ | 2018-01-18 16:47:06 UTC | #22
Jestem w trakcie wysyłki powiadomień.
Do godziny 18:00 wszyscy klienci VPS KVM powinni otrzymać już maila.
Finalnie restarty odbędą się dziś pomiędzy 22:30 a 23:30.
Edit: Maile zostały wysłane, choć z tego co widzę serwery pocztowe np. WP odrzuciły wiadomości, postaram się aby na przyszłość dostarczalność była lepsza.
SystemZ | 2018-01-18 22:23:37 UTC | #23
Restarty wykonane.
Wygląda na to że wszystkie węzły KVM są teraz odporne na te trzy podatności.
helczyna | 2018-01-19 07:41:32 UTC | #24
Cloudlinux się obija czy co? Już dawno miały być łatki na OpenVZ.
[quote=”SystemZ, post:1, topic:4903”]
Cloudlinux zaczyna wypuszczać łatkę na CVE-2017-5753 (Spectre I).
Ciężko oszacować kiedy trafi ona na węzły OpenVZ lecz sądzę że powinno to mieć miejsce jutro
[/quote]
^ napisane 11 stycznia
SystemZ | 2018-01-19 10:51:07 UTC | #25
Podsumowując co piszą u siebie na blogu napotkali na wiele problemów technicznych.
Wczoraj naprawili to co znaleźli i dalej testują po dziesiątki godzin czy nie zawieszą tysięcy serwerów na całym świecie jedną łatką :stuckouttongue:
SystemZ | 2018-02-17 17:10:26 UTC | #26