Kritiek beveiligingslek in FreeBSD maakt remote code execution mogelijk
Een kritiek beveiligingslek in FreeBSD maakt remote code execution mogelijk, waarbij een aanvaller in hetzelfde netwerksegment moet zitten als het doelwit. Er zijn beveiligingsupdates uitgebracht om het probleem te verhelpen. De kwetsbaarheid (CVE-2025-14558) doet zich voor bij het verwerken van router advertisement (RA) packets die onderdeel zijn van het IPv6 stateless address autoconfiguration (SLAAC) mechanisme.
SLAAC zorgt ervoor dat clients op het netwerk hun eigen ip-adres en gateway kunnen instellen, zonder dat hiervoor een DHCP-server is vereist. Wanneer een client online komt stuurt die een Router Solicitation bericht. Een router in het netwerk zal vervolgens met een RA-bericht antwoorden. Dit bericht bevat onder andere informatie over de te gebruiken gateway en dns-servers.
Twee programma's binnen FreeBSD zijn verantwoordelijk voor het verwerken van de RA-packets. Deze programma's blijken de inhoud van de RA-berichten niet goed te valideren. De programma's geven de inhoud onaangepast door aan een shell-script binnen FreeBSD. Een aanvaller kan hier misbruik van maken door een RA-bericht te versturen met daarin een shell-commando dat vervolgens onaangepast door het shell-script op het FreeBSD-systeem van het doelwit wordt uitgevoerd.
Om een dergelijk RA-bericht te kunnen versturen moeten de aanvaller en het slachtoffer wel op hetzelfde netwerksegment zitten. Securitybedrijf Tenable heeft de impact van de kwetsbaarheid op een schaal van 1 tot en met 10 beoordeeld met een 9.8. Gebruikers die geen IPv6 gebruiken en IPv6-gebruikers van wie het FreeBSD-systeem geen RA-berichten accepteert lopen geen risico om te worden aangevallen. Alle FreeBSD-gebruikers worden echter opgeroepen om de beveiligingsupdate te installeren.
Eerst Microsoft en nu FreeBSD. Zo meteen ook nog eentje in Linux of Apple?
(Ik vind het principe van netwerk data naar een shellscript pipen eigenlijk wel een beetje slordig...)
Eerst Microsoft en nu FreeBSD. Zo meteen ook nog eentje in Linux of Apple?
(Ik vind het principe van netwerk data naar een shellscript pipen eigenlijk wel een beetje slordig...)
Heb je wel eens de klassieke netwerk init scripten in Linux bekeken ?
Het was zeker niet ongebruikelijk om parameters geleerd via DHCP met shell scripten in het systeem te zetten (dns, ntp) .
Het heeft wat lelijks inderdaad.
Eerst Microsoft en nu FreeBSD. Zo meteen ook nog eentje in Linux of Apple?
(Ik vind het principe van netwerk data naar een shellscript pipen eigenlijk wel een beetje slordig...)
Microsoft IP stack is "geleend" van FreeBSD, dus niet heel verbazing wekkend dat als een van beide problemen heeft dat de ander het ook heeft.
Apple is ook FreeBSD gebaseerd..cc
Linus stack heeft een onafhankelijke ontwikkeling. Dit heeft weinig met scripting oid van doen. SLAAC wordt geheel in de kernel IP-stack afgehandeld. DHCPv6 is bedoeld voor hoger niveau zoals prefix delegation opvragen, dns servers opvragen etc.
Eerst Microsoft en nu FreeBSD. Zo meteen ook nog eentje in Linux of Apple?
(Ik vind het principe van netwerk data naar een shellscript pipen eigenlijk wel een beetje slordig...)
Microsoft IP stack is "geleend" van FreeBSD, dus niet heel verbazing wekkend dat als een van beide problemen heeft dat de ander het ook heeft.
Vraag me af hoeveel er nog over is van de FreeBSD stack . En zeker keuzes userland/kernel , dingen als address assignment zitten vaak buiten de kernel , en hebben toch al interactie met veel andere services.
Apple is ook FreeBSD gebaseerd..cc
Linus stack heeft een onafhankelijke ontwikkeling. Dit heeft weinig met scripting oid van doen. SLAAC wordt geheel in de kernel IP-stack afgehandeld. DHCPv6 is bedoeld voor hoger niveau zoals prefix delegation opvragen, dns servers opvragen etc.
Dat is ietwat onjuist .
Hoewel SLAAC en DHCPv6 gezamelijk gebruikt _kunnen_ worden, hebben ze overlappende mogelijkheden .
DHCPv6 kan ook gebruik worden voor adres krijgen (totaal zonder SLAAC) ;De default gateway moet van RA komen.
De split is deel van het historische gevecht tussen netwerk en server silos .
De IPv6 designers wilden alles om online te komen in de netwerk stack trekken zodat ze zonder die vervelende _systeem_beheerders konden leven (want DHCP beheer was altijd _systeem_ beheer, geen _netwerk_ beheer) .
En DHCPv6 is er omdat een client haast altijd veel meer nodig heeft dan een adres (en de DNS server die er in slaac bij gekludged is ) - en allerlei accounting zaken (wie heeft wanneer welk adres) erg veel makkelijker zijn op een dhcp server dan wanneer dat door tig gateway routers uitgegeven wordt.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Wij zoeken een Junior DevOps Engineer!
Ben jij nieuwsgierig, leergierig en klaar om je te verdiepen in de wereld van DevOps? In deze functie krijg je alle ruimte om te groeien. Je werkt met de nieuwste technologieën en krijgt intensieve begeleiding van ervaren security professionals zodat je je in korte tijd kunt ontwikkelen tot een volwaardige DevOps Engineer. Je werkt in Den Haag en werkt samen met een team dat kennis, humor en uitdaging moeiteloos weet te combineren. Are you ready for a challenge?