Oracle patcht 284 kwetsbaarheden in groot aantal programma's
Tijdens de eerste patchronde van 2019 heeft Oracle 284 kwetsbaarheden in een groot aantal programma's gepatcht. Via de beveiligingslekken kunnen systemen in het ergste geval op afstand en zonder authenticatie volledig worden overgenomen. Op een schaal van 1 tot en met 10 wat betreft de ernst van de kwetsbaarheden zijn er 28 met een 9,8 beoordeeld.
De meeste beveiligingslekken zijn opgelost in Fusion Middleware (62), Communications Applications (33), Oracle MySQL (30) en de virtualisatiesoftware van Oracle, zoals VirtualBox (30). In Java zijn vijf kwetsbaarheden verholpen. Het gaat om Java SE 7u201, 8u192 en 11.0.1 en Java SE Embedded 8u191 die kwetsbaar zijn. Gebruikers kunnen via Java.com de meest recente versie van de software downloaden.
Oracle blijft naar eigen zeggen geregeld berichten ontvangen van systemen die zijn gehackt omdat klanten beschikbare patches, die de aangevallen kwetsbaarheden verhelpen, niet hadden geïnstalleerd. Organisaties en beheerders krijgen dan ook het advies om de updates van de Critical Patch Update direct te installeren en ondersteunde versies van de software te blijven gebruiken.
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Reacties (12)
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
Door Anoniem:
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
daarom mag er strak ook betaald worden voor Java updates. https://www.aspera.com/en/blog/oracle-will-charge-for-java-starting-in-2019/
16-01-2019, 16:59 door
-karma4
Door Anoniem:
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
Ik snap ook niet helemaal hoe grote bedrijven steeds hiermee wegkomen. Er is kritiek genoeg: https://boingboing.net/2018/11/11/unreliable-oracle.html.
Door Anoniem:
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
Door The FOSS:
Ik snap ook niet helemaal hoe grote bedrijven steeds hiermee wegkomen. Er is kritiek genoeg: https://boingboing.net/2018/11/11/unreliable-oracle.html.
Misschien omdat dit soort applicaties meestal de core van bedrijven zijn. En dat je updates dus niet "even" zomaar door kan voeren. Je zal dit eerst een OTA straat moeten testen op de impact van je applicaties waar je bedrijf mee werkt. En voor dit soort tests moet je de benodigde resources gereed hebben om er snel mee aan de slag te gaan. Ik snap ook niet helemaal hoe grote bedrijven steeds hiermee wegkomen. Er is kritiek genoeg: https://boingboing.net/2018/11/11/unreliable-oracle.html.
En dan moet je voorspelbaarheid hebben, zodat je weet wanneer je er mee aan de slag moet kunnen gaan. Dus vaste periodes. Dus Oracle doet eigenlijk precies waar de gebruikers en het bedrijfsleven om vraagt. Voorspelbaarheid.
Door Anoniem:
En dan moet je voorspelbaarheid hebben, zodat je weet wanneer je er mee aan de slag moet kunnen gaan. Dus vaste periodes. Dus Oracle doet eigenlijk precies waar de gebruikers en het bedrijfsleven om vraagt. Voorspelbaarheid.
Door Anoniem:
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
In tegenstelling tot bijvoorbeeld Microsoft komt Oracle eens per kwartaal met updates. De volgende patchronde staat gepland voor 16 april 2019.
Dat is toch véél te lang? Dus als er een kwetsbaarheid wordt gevonden moet je 3 maanden wachten voordat het gepatcht wordt? Schandalig. Het beleid zou moeten zijn dat men constant werkt aan fixes en deze ook meteen uitbrengt zodra deze klaar en getest is. Niet bundelen en wachten, want daarmee werk je kwaadwillenden in de kaart.
Door The FOSS:
Ik snap ook niet helemaal hoe grote bedrijven steeds hiermee wegkomen. Er is kritiek genoeg: https://boingboing.net/2018/11/11/unreliable-oracle.html.
Misschien omdat dit soort applicaties meestal de core van bedrijven zijn. En dat je updates dus niet "even" zomaar door kan voeren. Je zal dit eerst een OTA straat moeten testen op de impact van je applicaties waar je bedrijf mee werkt. En voor dit soort tests moet je de benodigde resources gereed hebben om er snel mee aan de slag te gaan. Ik snap ook niet helemaal hoe grote bedrijven steeds hiermee wegkomen. Er is kritiek genoeg: https://boingboing.net/2018/11/11/unreliable-oracle.html.
En dan moet je voorspelbaarheid hebben, zodat je weet wanneer je er mee aan de slag moet kunnen gaan. Dus vaste periodes. Dus Oracle doet eigenlijk precies waar de gebruikers en het bedrijfsleven om vraagt. Voorspelbaarheid.
Mooie smoes om kosten te besparen. Maar dit zou alleen voordelen hebben indien bedrijven (ruim) van tevoren te horen zouden krijgen welke patches eraan zitten te komen en welke functionaliteit geraakt zal gaan worden. Zodat ze zich daarop kunnen voorbereiden. Indien het vooraf informeren niet aan de orde is dan is het alleen een management van resources probleem en dat vind ik persoonlijk gezeik. Want zoiets is net zo goed op te lossen met een pool van resources die in deeltijd kunnen worden ingezet om acuut patches te testen en uit te rollen.
17-01-2019, 18:28 door
karma4
Door The FOSS: ...... Want zoiets is net zo goed op te lossen met een pool van resources die in deeltijd kunnen worden ingezet om acuut patches te testen en uit te rollen.
In de complete bundeling van stacks zit van alles. De commerciële software verweven met open source versies en libraries waar dan flinke aanpassingen als configuratie en setting aan gedane zijn met koppelen aan van alles. Raak niets aan want niemand weet nog hoe het echt allemaal zit. Dan ga jij voorstellen op aangeven van ... her en der wat te veranderen. Dat is gewoon vragen om nog meer problemen.
Het is niet voor niets dat je bijvoorbeeld in de medische wereld daarop afgeschoten wordt.
18-01-2019, 05:19 door
-karma4
Door karma4:
Raak niets aan want niemand weet nog hoe het echt allemaal zit. Dan ga jij voorstellen op aangeven van ... her en der wat te veranderen. Dat is gewoon vragen om nog meer problemen.
Door The FOSS: ...... Want zoiets is net zo goed op te lossen met een pool van resources die in deeltijd kunnen worden ingezet om acuut patches te testen en uit te rollen.
In de complete bundeling van stacks zit van alles. De commerciële software verweven met open source versies en libraries waar dan flinke aanpassingen als configuratie en setting aan gedane zijn met koppelen aan van alles. Raak niets aan want niemand weet nog hoe het echt allemaal zit. Dan ga jij voorstellen op aangeven van ... her en der wat te veranderen. Dat is gewoon vragen om nog meer problemen.
Ik had het alléén over hoe je resources alloceert voor patches. De rest verzin je er zelf bij in je verwarde denkproces.
Door karma4: Het is niet voor niets dat je bijvoorbeeld in de medische wereld daarop afgeschoten wordt.
Lul toch niet zo man! (Ik heb medische software geschreven en het is pijnlijk duidelijk dat jij alleen maar wat roept vanaf de wal.)
Door The FOSS:
Mooie smoes om kosten te besparen. Maar dit zou alleen voordelen hebben indien bedrijven (ruim) van tevoren te horen zouden krijgen welke patches eraan zitten te komen en welke functionaliteit geraakt zal gaan worden. Zodat ze zich daarop kunnen voorbereiden. Indien het vooraf informeren niet aan de orde is dan is het alleen een management van resources probleem en dat vind ik persoonlijk gezeik.
Nee er zit veel meer achter. Oa je weet bijvoorbeeld wanneer je geen andere changes moet gaan uitvoeren, want mogelijk moet je iets aan je core applicaties iets aan aanpassen. Nieuwe releases van andere applicaties kunnen dus alvast hierop afgestemd worden.Mooie smoes om kosten te besparen. Maar dit zou alleen voordelen hebben indien bedrijven (ruim) van tevoren te horen zouden krijgen welke patches eraan zitten te komen en welke functionaliteit geraakt zal gaan worden. Zodat ze zich daarop kunnen voorbereiden. Indien het vooraf informeren niet aan de orde is dan is het alleen een management van resources probleem en dat vind ik persoonlijk gezeik.
En ik weet niet in wat voor een omgeving jij werkt, maar communicatie naar eind gebruikers en downtime regelen van je applicaties is meestal het lastigste. Iedereen wil er iets over te zegen hebben, en kunnen dat meestal ook gewoon doen. Immers iedereen is belangrijk.
Met vaste datums is het al gepland en gecommuniceerd.
Want zoiets is net zo goed op te lossen met een pool van resources die in deeltijd kunnen worden ingezet om acuut patches te testen en uit te rollen.
Pool met deeltijd resources... Klinkt leuk, maar als je ook maar een beetje ervaring hebt in een Enterprise dan moet je nu erg lachen. Je wilt deeltijd resources aan de core van je infrastructuur laten sleutel? Nog even er vanuit gaande dat je deze pool hebt, want dat zal al een uitzondering zijn.
18-01-2019, 10:32 door
-karma4
@Anoniem et al - Allemaal smoezen om een schrijnend gebrek aan flexibiliteit te maskeren.
Door The FOSS: @Anoniem et al - Allemaal smoezen om een schrijnend gebrek aan flexibiliteit te maskeren.
Wat begrijp jij niet aan het feit dat in enterprise omgevingen resources geregeld moet worden en met de gebruikers gecommuniceerd moet worden ?En dat je niet zomaar even een update kunt installeren in enterprise omgevingen ?
Niet meepraten over dingen waar je geen verstand van hebt
Door The FOSS:
...
Ik had het alléén over hoe je resources alloceert voor patches. De rest verzin je er zelf bij in je verwarde denkproces.
Aangezien je meteen op de mans speelt toon je feitelijk je eigen verstoorde denken. Het begint al met het idee dat als iedereen de code zou kunnen zien dat er dan vanzelf wat gebeurt om die code goed en veilig te maken....
Ik had het alléén over hoe je resources alloceert voor patches. De rest verzin je er zelf bij in je verwarde denkproces.
Dat is in de tijden van Edsger Dijkstra al weerlegd. Toch jammer dat daar niet op doorgebouwd is,
Lul toch niet zo man! (Ik heb medische software geschreven en het is pijnlijk duidelijk dat jij alleen maar wat roept vanaf de wal.)
Veel interessanter en wezenlijker is de goedkeuring en review van de werking door anderen en vervolgens de integratie in een compleet werkend operationeel geheel. Daar mis je zo te zien gewoon alles en gezien je reacties ben je er ook niet geschikt voor.
@karma4 Jouw reactie zegt weer veel over jouw inschattingsvermogen. Want ik heb op topniveau software ontwikkeld. In de hele ratjetoe aan entreprise level context. Been there, done that.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
