Opdatering 1. November 2022 16:10.
OpenSSL teamet har lanceret information om ændringer der sker imellem 3.0.6 og 3.0.7, kort opsummeret er det muligt at lave en buffer overrun, når et certifikats indhold tjekkes, kan e-mail feltet være ugyldigt (ved ekstra . punktum karakterer) og få OpenSSL koden og derved server/klienten til at crashe, hvilket enten kan være en denial of service eller muligvis fjern-eksekvering af kode.
Det kan ske for en klient ved at et servercertifikat indeholder den ugyldige e-mail men kræver også at klienten stoler på certifikatet (ikke sandsynligt), eller for en server ved at klienten skal identificere sig med et klientcertifikat som er ugyldigt (muligt, men få systemer anvender dette).
Niveauet af sårbarheden er samtidigt blevet nedgraderet fra Critical til High, fordi undersøgelser med andre software virksomheder der bruger OpenSSL, har vist at det kun sjældent er et reelt problem i virkeligheden.
Ud fra nuværende information bedømmer vi at der vil være meget lille risiko for nogen af vores kunder er reelt påvirkede af dette. Det ville kræve at man har et nyt system online fx Ubuntu 22.04 eller Amazon Linux 2022 og samtidigt at serveren tillader klientcertifikater som brugergodkendelse.
Vores anbefaling er stadig at snarest muligt opdatere klienter og servere der har OpenSSL 3.0.x til 3.0.7 eller højere når muligt.
Se hele posten om det fra OpenSSL’s site her
Oprindelig post 31. Oktober 2022.
OpenSSL er et open-source software bibliotek som bruges til brug af SSL/TLS og inkluderer basis kryptografiske funktioner. Det anvendes af en lang række server (og klient) software til at håndtere SSL/TLS, specielt på linux baserede systemer.
OpenSSL har annonceret at de 1. November 2022 i tidsrummet kl. 14-18 dansk tid, udgiver en haster sikkerhedsrelease OpenSSL version 3.0.7, som løser en højeste niveau kritisk sårbarhed der findes i OpenSSL version 3.0.0-3.0.6.
Fordi annonceringen kommer uden nogen information overhovedet om hvad sårbarheden er og med højeste klassificering “Critical” og det kun er anden gang at en sårbarhed har denne klassificering, siden OpenSSL introducerede deres klasser i 2014, tyder det meget kraftigt på at vi får en alvorlig sårbarhed som vil have en eller flere af følgende egenskaber:
- Sårbarheden er relevant dvs. er ikke kun teoretisk og er mulig for normale konfigurationer som er i brug i produktion.
- Få OpenSSL til at crashe og afsløre dele af hukommelsen, som HeartBleed der var af denne klassificering.
- Få OpenSSL til at eksekvere kode, evt. med overtagelse af serveren som følge.
Sårbarheden påvirker ikke OpenSSL version 1.1.1 og tidligere, som lige nu er mere udbredt i brug end den nyere 3.0 serie som først udkom for lidt over et år siden. Der er altså en stor chance for at ældre systemer der er i produktion i dag ikke er påvirkede.
Fordi softwaren ofte er installeret via en pakke manager som fx yum eller apt, kan det tage tid for opdateringen at være tilgængelig for alle, men hvis den er så alvorlig som der nu ligges op til vil det være i enhver server administrators interesse at få opdateret hurtigt og evt. manuelt installere versionen på serveren. Dette er også en af årsagerne til at det er annonceret inden det udgives, da det giver OS og software firmaer tid til at planlægge opdateringen, inden det bliver frigivet til internettet hvad sårbarheden er, som typisk vil være en nedtælling til at sårbarheden begynder at blive misbrugt aktivt.
OpenSSL bruges i en lang række af software, servere og operativsystemer fx Apache2, Nginx, Postfix, XAMPP, pfSense, FreePbx, F5 BIG-IP, Cisco WSA, Symantec VIP Gateway, HAProxy, Asterisk, Tomcat, MySQL, Ubuntu, RHEL, CentOS.
Vi har indtil videre set OpenSSL 3.0 bliver brugt i Ubuntu 22.04 LTS, MacOS Ventura, Fedora 36, Node.js 18.x-19.x, MariaDB 10.9, Tomcat 10.1. Se liste der bliver opbygget med software der er eller ikke er sårbar her .
Vores anbefaling:
- Tag den her sårbarhed alvorligt, den vil formodentlig være en af de større. (Vi kan tage fejl)
- Start allerede nu på at lave en oversigt over software der bruger OpenSSL, specifikt fra 3.0 og op. Start med servere der kommunikerer på internettet som har højest risiko.
- Afsæt tid tirsdag fra 14.00 og frem til at være klar til at reagere på hvad sårbarheden reelt gør og om nogle af jeres systemer er ramt og evt. skal tages offline eller opdateres med det samme.
- Opdater andre ikke kritiske systemer snarest muligt og tjek løbende efter opdateringer som vil begynde at komme på software der er påvirket.
På de fleste systemer hvor der er OpenSSL installeret, kan man se versionen ved at skrive kommandoen: openssl version