de SRBDS (CVE-2020-0543) kwetsbaarheid te verhelpen zonder een server reboot

Onlangs hebben academici van de Systems and Network Security Group (VUSec) van de Vrije Universiteit details gepubliceerd over CrossTalk of SRBDS (CVE-2020-0543) kwetsbaarheid in Intel processoren. De CrossTalk kwetsbaarheid maakt het mogelijk dat door aanvallers gecontroleerde code die op een CPU kern uitvoert gevoelige gegevens lekt van andere software die op een andere kern draait. In dit artikel laten we je zien hoe je deze Intel CPU kwetsbaarheid kunt verhelpen zonder een server reboot.

Wat is CrossTalk?

De CrossTalk kwetsbaarheid is een soort MDS (microarchitectural data sampling) aanval, vergelijkbaar met Spectre, Meltdown of Zombieload. Het maakt het mogelijk om gevoelige gegevens bloot te leggen en te stelen terwijl de machine er toegang toe heeft. MDS aanvallen richten zich op gebruikersgegevens terwijl ze in een voorbijgaande toestand verkeren, omdat ze zich in de CPU en vele daarmee verbonden systemen bevinden.

SRBDS/CrossTalk kwetsbaarheid is een kwetsbaarheid voor voorbijgaande uitvoering. Genoemd als een “Special Register Buffer Data Sampling” of SRBDS (CVE-2020-0543) door Intel, maakt het mogelijk dat door aanvallers gecontroleerde code op een CPU kern uitvoert, waardoor gevoelige gegevens lekken van slachtoffer software die op een andere kern uitvoert.



Figuur 1: Ontwerp van de instructie profileringsfase van CrossTalk, met dank aanVUSec

Elk systeem dat een Intel CPU gebruikt kan door deze kwetsbaarheid getroffen worden. Controleer hier of je CPU getroffen is.

Herstartloze verzachting van de SRBDS (CVE-2020-0543) kwetsbaarheid

Intel heeft zijn mitigatie voor de SRBDS kwetsbaarheid in een microcode update die op dinsdag 9 juni 2020 naar softwareleveranciers werd verspreid. Deze verzachting vereist de installatie van de nieuwste Linux Kernel patches & microcode update. Beide bewerkingen worden traditioneel uitgevoerd bij het herstarten.

Hoewel het herstarten van een paar servers niet als een probleem klinkt, is het dat zeker wel als je een SysAdmin bent die 500+ servers onder zijn hoede heeft. Het herstarten van een hele server vloot vereist meestal een grondige planning van het onderhoudsvenster. Gelukkig maakt live patching technologie het mogelijk om beveiligingsupdates de systemen tegen CrossTalk aan te brengen zonder een reboot, zowel voor microcode update als voor het aanbrengen van Linux kernel patch.

Canonical, Red Hate en andere distributieleveranciers hebben de beveiligingspatches uitgebracht voor alle ondersteunde Ubuntu distributies, Debian, CentOS, Red Hat Enterprise Linux. En, hoewel Canonical & Red Hat hun eigen oplossing hebben om kwetsbaarheden te patchen zonder opnieuw op te starten, moet je in het geval van SRBDS/CrossTalk nog steeds nodig om opnieuw op te starten een desktop of een server na de update.

KernelCare team heeft een rebootless mitigation gemaakt voor CrossTalk/SRBDS zodat je het herstarten van de servers kon vermijden om de patches aan te brengen. Hieronder vind je de instructies:

A) Als je op hardware draait, neem dan 3 stappen om je servers te beschermen tegen CrossTalk/SRBDS kwetsbaarheid zonder opnieuw op te starten:

Stap 1:Meld je aan voor een gratis proeflicentie van KernelCare

KernelCare is 30 dagen gratis te gebruiken op al je servers, geen credit card nodig om je aan te melden voor een proef. Het is ook gratis voor organisaties in de gezondheidszorg voor de rest van 2020 en voor altijd gratis voor non-profit organisaties.

Stap 2: Update de microcode zonder opnieuw op te starten

Voorbeeld: Bijwerken van microcode op RHEL

Dit is het voorbeeld van een rebootless microcode update op RHEL.Instructies voor Debian, Ubuntu, CentOS en andere distributies kun je vinden in KernelCare Documentatie.

Voor RHEL-gebaseerde distributies kun je gebruik maken van de microcode_ctl utility om microcode bij te werken.

Kijk voor je begint hier of de patches voor je distributie klaar zijn. De pagina wordt elk uur bijgewerkt.

1. Verkrijg de nieuwste microcode door het bijwerken van de microcode_ctl pakket

yum update microcode_ctl

2. Maak een force-late-intel-06-4f-01 binnen de firmware directory.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

3. Voer de microcode update uit

/usr/libexec/microcode_ctl/update_ucode

4. Forceer de kernel om de nieuwe microcode te laden

echo 1 > /sys/devices/system/cpu/microcode/reload

5. Controleer de nieuwe microcode

dmesg | grep microcode
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12
[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

6. (Optioneel) Controleer de nieuwe versie van de microcode dubbel (revisies per kern)

cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21

Stap 3: Breng KernelCare patches aan

Nu moet je de Linux Kernel bijwerken om te zorgen dat de lokale gebruiker de gegevens die je op de CPU draait niet kan lezen. Met KernelCare kun je dat doen zonder opnieuw op te starten. Als je je bij Stap 1 aanmeldde voor de proef – ben je helemaal klaar en hoef je verder niets te doen.

B) Als je op VM draait:

Je hoeft alleen de Linux Kernel binnen de VM te patchen. Zorg ervoor dat je host node ook bijgewerkt is, wat meestal door je serviceprovider gedaan wordt.

Als je KernelCare gebruikt – worden je patches automatisch door KernelCare afgeleverd en hoef je niets extra’s te doen. Zo niet –meld je dan aan voor een gratis proefversie voor 30 dagen.