Beveiligingsonderzoekers vinden opnieuw groot lek in Microsoft Azure

Beveiligingsonderzoekers van cloudsecuritydienst Wiz hebben een kwetsbaarheid ontdekt in Azure die virtuele Linux-machines treft. De kwetsbaarheid zit in de opensourcedienst OMI, die geïnstalleerd wordt bij het inschakelen van logging, reporting of managementopties in Azure UI.

De onderzoekers van Wiz noemen de kwetsbaarheid 'Omigod'. Via de kwetsbaarheid in OMI kan remote root code execution uitgevoerd worden. Dat is vooral een probleem als een netwerkbeheerder de firewall buiten de virtuele machine uitzet. Die firewall staat standaard aan en beperkt de toegang van OMI tot het interne netwerk.

OMI, of Open Management Interface, is een programma dat geïnstalleerd wordt zodra een Azure-dienst zoals distributed logging en managementopties worden aangezet. OMI werkt zoals Windows Management Instrumentation, maar dan voor Azure. Het schakelt het verzamelen van logs en metrics in en maakt voor een deel remote management mogelijk. OMI wordt standaard uitgevoerd als Azure-klanten een virtuele Linux-machine opzetten in hun cloudomgeving en bepaalde diensten aanzetten. Volgens de onderzoekers van Wiz gebeurt dit zonder hun weten en kunnen kwaadwillenden een van vier kwetsbaarheden gebruiken om de rootprivileges uit te breiden, tenzij er een patch tegen de zerodays is geïnstalleerd.

Microsoft heeft inmiddels een patch tegen de kwetsbaarheden beschikbaar gesteld voor klanten. De kwetsbaarheden zijn geregistreerd onder CVE-2021-38647, CVE-2021-38648, CVE-2021-38645 en CVE-2021-38649. Vooral die eerste kwetsbaarheid is ernstig en heeft als cijfer 9,8 van de 10 gekregen. De kwetsbaarheid treft Azure-klanten op Linux-machines als ze gebruikmaken van een van de volgende tools: Azure Automation, Azure Automatic Update, Azure Operations Management Suite, Azure Log Analytics, Azure Configuration Management of Azure Diagnostics. Volgens Wiz is dit waarschijnlijk niet de volledige lijst tools waarbij stilletjes OMI wordt aangezet en het bedrijf roept op om het te melden als OMI bij meer programma's wordt aangezet.

In gesprek met Ars Technica vertellen de onderzoekers dat het niet makkelijk was om de kwetsbaarheid te melden bij Microsoft en aan responsible disclosure te doen. Volgens Microsoft viel de kwetsbaarheid buiten de scope van de responsible disclosure van Azure, omdat het gaat om een extern opensourceprogramma. OMI is inderdaad open source, maar werd in 2012 door Microsoft gedoneerd aan The Open Group. Sindsdien leverden medewerkers van Microsoft de grote meerderheid van de commits. Daarnaast voert Microsoft de tool automatisch uit binnen Azure zonder dat een beheerder hiervan op de hoogte is. Uiteindelijk heeft Microsoft voor de kwetsbaarheid in totaal zeventigduizend dollar aan bugbounties uitgekeerd.

Het is de tweede keer in relatief korte tijd dat er een kwetsbaarheid wordt gedicht in Azure. Eind augustus betrof het een kwetsbaarheid die kwaadwillenden onbeperkt toegang gaf tot accounts en databases van Azure-klanten via de databasedienst Cosmos DB. Ook die kwetsbaarheid werd ontdekt door beveiligingsonderzoekers van Wiz.

Reacties (96)

[closefuture]

Wiz’s research team recently discovered a series of alarming vulnerabilities that highlight the supply chain risk of open source code, particularly for customers of cloud computing services.

Nogal rare framing aangezien het gewoon een opensource project van Microsoft zelf is. En de kwestbaarheid komt voor zover ik kan zien ook niet uit een library die niet van Microsoft is.

[HollowGamer]

Nogal een rare redenering inderdaad. Zonder de source was dit lek waarschijnlijk niet gevonden, maar wellicht dus wel misbruikt.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 06:37]

[Carharttguy]

Je moet het toch eerst vinden voor je het kan misbruiken?

[FlaffTweakr]

Als je slim bent, doe je dat in de omgekeerde volgorde

[pgerrits]

Als je criminele intenties hebt doe je dat. Met normen en waarden en een braaf burger doet het zoals Carharttguy het zegt.

[Reactie gewijzigd door pgerrits op 23 juli 2024 06:37]

[GeroldM]

Als je criminele intenties hebt doe je dat. Met normen en waarden en een braaf burger doet het zoals Carharttguy het zegt.

En Nationale Staten met hun veiligheidsdiensten dan? Deze maken ook graag gebruik van ongepubliceerde beveiligingsfouten. Staten welke door mensen met normen en waarden zijn opgezet.

[Wilke]

Ook in gecompileerde code kun je prima zoeken naar lekken. Het kost alleen meer moeite - maar met disassemblers kan dat nog redelijk meevallen.

[Tom Paris]

Ja en nee... Het project is open-source gemaakt door Microsoft, en de meeste commits kwamen van Microsoft, maar Microsoft was formeel niet meer de eigenaar van de software en daarmee ook niet eindverantwoordelijk. Toch installeert Microsoft deze tool in elke Linux VM. Het is weldegelijk een risico als een dergelijke tool niet meer onderhouden wordt of als een malicious actor bewust kwetsbare code commit. Dus nu moet ik als Azure klant maar hopen dat 'de community' 1) code up to date houdt, en 2) opmerkt als iemand kwetsbare code commit.

Van beide gevallen zijn genoeg voorbeelden hoe dat heeft kunnen leiden tot exploits...

Dit is geen betoog tégen open source software, maar je moet het wel meenemen in je threatmodel.

[closefuture]

Het project is open-source gemaakt door Microsoft, en de meeste commits kwamen van Microsoft, maar Microsoft was formeel niet meer de eigenaar van de software en daarmee ook niet eindverantwoordelijk.

Dus het is iets gemaakt door MS (en geopensourced door MS), word onderhouden door MS, de source staat in de Microsoft organisatie in Github, in de license file staat Copyright Microsoft en je moet als OSS contributer een CLA ondertekenen dat je het eigendom van je contributie overdraagt aan Microsoft.

En toch is Microsoft volgens jou formeel geen eigenaar?

[gorgi_19]

De licentie is MIT, dus hoe zou je het eigendom overdragen aan Microsoft?

[closefuture]

Doordat je eerst dit document: https://opensource.micros...ion-license-agreement.pdf moet ondertekenen voordat je contributie (pull request) geaccepteerd word. Waarna Microsoft mede-eigenaar word van je code.

Dat je code daarna ook onder MIT vrijgegeven word staat daar los van. Er zit een verschil tussen wie er eigendom hebben van de broncode en onder welke licenties de broncode dan toevallig ook nog verstrekt word zoals bijvoorbeeld de MIT licentie. De eigenaar kan namelijk ook ervoor kiezen om de broncode onder een andere licentie dan de MIT vrij te geven. Zelfs een commerciele licentie of eigendom over te dragen.

Echter kan jij als gebruiker van de code onder MIT license niet eigendom overdragen of de code onder een licentie verstrekken die botst met de MIT license.

[michelr]

Dus nu moet ik als Azure klant maar hopen dat 'de community' 1) code up to date houdt, en 2) opmerkt als iemand kwetsbare code commit.

Dat is sowieso met OSS.

[TheekAzzaBreek]

Als MS zijn handen er van af trekt met de mededeling 'is open source, je moet niet bij ons zijn' vind ik dat niet zo'n gekke redenering. Gelukkig is MS bijgedraaid.

[anboni]

Je zou toch denken dat we rondom Linux de FUD periode wel ontgroeid zouden zijn...

[Slavy]

En toch blijven al die consultants roepen "cloud is veilig en beter". Zoals verwacht lijkt het niet anders te zijn dan on-premesis.

[Cergorach]

En toch blijven al die consultants roepen "cloud is veilig en beter".

Dat ligt er enorm aan wat je ziet als veilig en beter. Wiz gaat niet jou lokale oplossing bekijken naar issues, dat doen de blackhat hackers wel. Dus als iemand bij jullie OMI had deployed en dezelfde vulnerability had gemaakt, dan had er niemand aan de bel getrokken en was je omgeving comprimised door hackers. In het geval van Azure wordt dit gevonden.

Het issue met on-premises is dat de bedrijven die dit zelf doen, het niet hun core business is, maar ter ondersteuning van de core business. Daardoor zal er niet de hoeveelheid aandacht/resources worden besteed zoals dat bij bv. een MS Azure gebeurd. Omdat de security issues op je on-premises omgeving niet worden gevonden door het eigen personeel, betekend niet dat ze er niet zijn.

De 'cloud' is niet intrinsiek veilig of beter, in de praktijk blijkt dat echter wel het geval te zijn in het gros van de gevallen. Niet omdat het cloud is, maar omdat er een enorme partij achterzit die dat beheert en ontwikkeld die geen equivalent kent bij de partijen die hun IT on-premises hosten.

[BytePhantomX]

Deze nuance is geheel terecht. Alleen wordt dat er vaak niet bij verteld door Microsoft en zeker niet door de vele partners waar je mee in zee gaat.

En daarnaast verwacht je van een partij als Microsoft dat ze het dan ook heel serieus nemen. En daar zie je ook het nodige mis gaan. Ze pushen blijkbaar nog steeds kwetsbare tools zonder dat je daar als klant controle over hebt:
https://twitter.com/chrismckee/status/1438078026202374145

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 06:37]

[multikoe]

Deze nuance is geheel terecht. Alleen wordt dat er vaak niet bij verteld door Microsoft en zeker niet door de vele partners waar je mee in zee gaat.

misschien lees ik het verkeerd, maar de nuance die @Cergorach aanbrengt is nu juist dat de beveiliging bij cloudoplossingen veel meer aandacht krijgt dan bij on-premise installaties.

Dat er zaken mis gaan is onvermijdelijk, waar gewerkt wordt vallen spaanders, maar @Cergorach betoogd dus dat het veel minder vaak mis gaat bij cloudproviders dan bij on premise installaties. En dat is uiteindelijk waar je als klant gebaat bij bent.

[the_shadow]

Alleen wordt dat er vaak niet bij verteld door Microsoft en zeker niet door de vele partners waar je mee in zee gaat.

Dit ben ik niet met je eens. De partners kan ik niet over oordelen, maar Microsoft blijft er, waar je ook bezig bent in Azure of in O365, er op hameren dat beveiliging niet 100% door hen gegarandeerd kan worden, maar dat een zeer groot gedeelte afhankelijk is van de inrichting die de afnemende organisatie doet. En dat is waar het 9 van de 10 keer spaak loopt.

[Cergorach]

Deze nuance is geheel terecht. Alleen wordt dat er vaak niet bij verteld door Microsoft en zeker niet door de vele partners waar je mee in zee gaat.

Dan praat je niet met de juiste mensen bij MS en wellicht dat je dan ook niet samenwerkt met de juiste partners. Maar ik begrijp wat je bedoelt. De sales gasten verkopen je mooie roze wolken en op basis daarvan wordt een contract getekend bij veel te veel bedrijven. Pas daarna gaan de reguliere ITers ermee aan de slag en zou je wellicht een realistischer beeld krijgen. Dat betekend niet dat het een slechte oplossing is, maar sales mensen zijn over het algemeen te onzeker en hebben niet genoeg kennis van zaken om nuance aan te brengen. Daarnaast is er niet altijd even goede IT kennis aanwezig (of onafhankelijk) binnen de organisatie waaraan het wordt verkocht. Daarnaast is nog eens de vraag of de beslissers de nuance begrijpen...

[Marve79]

Of ik nu een Windows of Linux server bij MS in het datacenter draai of in mijn eigen datacenter dat maakt ook weinig uit qua security.

Ik vind wel bepaalde dingen meer geschikt als clouddienst, zoals Exchange en Sharepoint bijv. en daarmee ook veiliger dan on-prem omdat MS die wel up-to-date houdt. Bij veel bedrijven zie je dat zolang het werkt niemand eraan durft te komen.

[freaky]

Ligt dat dan aan de cloud of de beheerders?

Niet dat het andersom niet gebeurd overigens. Meerdere ervaringen dat iets in cloud gepatched werd en klant vervolgens 3 dagen problemen had.

Maar dan heeft de klant gewoon 3 dagen pech.

[Marve79]

Klopt idd maar dat is dan ook simpeler te communiceren naar de gebruiker. De Cloud ligt eruit wij kunnen er niks aan doen. Terwijl als on prem er 10 minuten uit ligt wordt er moord en brand geschreeuwd hoe dat nou toch mogelijk is.

Plus het voordeel is, als er een probleem is in de cloud zijn miljoenen gebruikers affected en is de druk bij bijv. Microsoft ontzettend hoog om het zsm op te lossen. Als ik on prem een probleem heb en een ticket inschiet bij MS kan ik het wel shaken.

[Cergorach]

Plus het voordeel is, als er een probleem is in de cloud zijn miljoenen gebruikers affected en is de druk bij bijv. Microsoft ontzettend hoog om het zsm op te lossen.

Ehhh... Ken je nog die oude, oude OneDrive for Business client die als je er verkeerd naar keek al een corrupted database gaf? Dat heeft vele jaren geduurd voordat dit is 'opgelost' door een andere client van MS. Jaren lang had elke organisatie die het gebruikte hier last van. Zelfs zo erg dat we bij tig klanten geen SharePoint Online en OneDrive for Business implementeerde, maar concurrerende producten of thirdparty products maar gingen inzetten. MS kon het kennelijk geen moer schelen, want die Office 365 licenties waren toch al verkocht voor Exchange Online en Azure AD...

Dat is slechts een enkel voorbeeldje, een van velen. Waarbij ook MS kiest voor prioriteiten die zeker niet altijd in lijn liggen met die van hun (grote) klanten.

Microsoft/Office 365 en Azure hebben heel, heel veel voordelen, maar zeker ook significante nadelen. Het is echter nog steeds zo dat de voordelen veel groter zijn dan de nadelen en dat is dan ook waar MS naar blijft streven. Zo hoeft niet alles perfect te werken, maar zolang het beter/goedkoper blijft dan de concurrerende oplossingen, hebben ze niets te vrezen. En dat is nog altijd zo.

En zo hebben we ook in de Service Health portal items open staan die al weken zo niet maanden openstaan...

[Berlinetta]

Ja dat komt omdat er ergens een andere groep mensen worden ingeschakeld om dit soort taken doen.
Geen systeembeheerders. ontzettend bizar wat ik hier tegenkom.

[S.McDuck]

Want een willekeurige verkoper adviseert ook bij het andere merk te gaan kijken omdat die beter is?
Alle bedrijven zijn er om geld te verdienen, niet om jou het beste product of dienst te bieden.

[Rdam]

Vergelijk: Jij levert jouw baas ook niet het beste werk of product? Jij zit daar ook enkel voor het verdienen van geld?

Misschien zijn er ook bedrijven (of personen) die wel een goed product of dienst willen leveren en daarmee geld verdienen. Jouw benadering is erg negatief en mijns inziens zeker niet waar.

[Zackito]

Wellicht eerst verdiepen wat de techgiganten allemaal doen voor het voorkomen van hacks en het opsporen van mogelijke lekken, het monitoren en uitlezen van data etc. Daar gaan serieuze bedragen heen en dat bevestigd hoe serieus ze het nemen.

https://finance.yahoo.com...yQLLAR2U4KKi7GlTf4ityVLdG

[Enai]

Als Microsoft consultant kan ik je niet verzekeren dat de cloud waterdicht is, maar wel dat Microsoft veel geld uitgeeft aan security terwijl je als klant nog te gierig bent voor een business analyst.

Het zou interessant zijn om te weten wat Wiz denkt over jouw on-prem server met Windows Server 2012 R2, maar je keert geen bug bounty uit, dus de enige mensen die zich interesseren in je security, zijn de hackers. Tja.

[hiostu]

Gemiddeld gezien is de cloud wel veiliger ja. En dat komt, omdat er nu 1 partij is die veel tijd en moeite investeert in het fixen en updaten van dit soort issues. Terwijl het anders weer afhankelijk is van 100en verschillende mensen voor verschillende bedrijven die allemaal moeten zorgen dat alles up-to-date blijft.

Tevens ligt het er natuurlijk ook heel erg aan wat je gebruikt in de cloud. Gebruik je IaaS, PaaS, of SaaS. Bij IaaS zal je nog steeds heel veel zelf moeten inregelen en kun je alles net zo (un)secure maken als je het doet in je eigen omgeving.

[XBL]

Voor VMs (IaaS) maakt het idd niet heel veel uit. Voor serverless cloud toepassingen (waar imo de kracht van de public cloud écht ligt) natuurlijk wel. Ik kan een complete applicatie met backend en alles in de cloud hosten, zonder me druk te maken over security patches e.d., als ik alles op SaaS en PaaS diensten draai.

[klakkie.57th]

Punt is net dat je, je eigenlijk wel druk moet maken.
nu ga je er vanuit dat de cloudprovider het wel doet voor jou, maar je kan dit niet of nauwelijks controleren.

[crazyx]

On promise kan je dat toch ook niet of nauwelijks controleren? Behalve dat je weet dat je de laatste versie (in het beste geval) van pakket x geïnstalleerd hebt. Het is niet dat je dan wel weet welke bugs en security problemen er inzitten.

[klakkie.57th]

Neen maar je weet wel welke versie je draait, dat was mijn punt.

[michelr]

In sommige opzichten niet nee. Probleem begint als klanten denken dat ze niet in actie hoeven komen omdat infrastructuur door andere partij gerund wordt.

[EchoWhiskey]

"Zoals verwacht lijkt het niet anders te zijn dan on-premesis."

Uiteraard niet...
Het draait alleen op een andere dan je eigen premesis.... Wat is je punt?

Cloud kan een aantal (beheer)zaken van je weg nemen, wellicht kosten technisch beter maar is perse niet veiliger.
En nee.... Ik ben geen consultant... (teminste niet meer )

[wica]

Bugs kunnen voorkomen, niets ergs aan.

Volgens de onderzoekers van Wiz gebeurt dit zonder hun weten en kunnen kwaadwillenden een van vier kwetsbaarheden gebruiken om de rootprivileges uit te breide

Maar software installeren, zonder dat de klant er zich bewust van is en met root rechten. Is denk ik nog vele malen erger.

[latka]

Je draait een managed service bij een 3rd party provider. Het is geen kale VM die je afneemt. Dan mag je verwachten dat je 0% controle hebt over die machine en welke software er (bij) geinstalleerd wordt.

[cracking cloud]

Dus ook al investeert microsoft jaarlijks 1 miljard dollar in cloud security, dan nog kunnen ze deze dingen niet zelf vinden

[bonus]

Je bent vaak blind voor je eigen fouten, dat is overal zo

[HollowGamer]

Daarom kan opensource juist erg belangrijk zijn voor een (IT/tech-)bedrijf.

Er zitten in vrijwel elk stuk code ergens wel een fout (nog niet meteen een security risk), maar als je alles gesloten houdt is de kans vrij klein dat het uiteindelijk ontdekt wordt. Daarom is het ook goed om derden naar je code te laten kijken, vaak zit je al vast in je eigen bubbel en zijn er ook developers die er (helaas) niet veel om geven.

[RGAT]

Derde partijen naar je software laten kijken heeft echter niets met open source te maken, dan kan closed source ook gewoon doen alleen hebben ze dan een NDA nodig.
Helaas zien we vaak genoeg dat hoewel iedereen naar de code KAN kijken bij open source, dat vrijwel niemand met genoeg kennis het ook echt doet...

[bonus]

Precies dat bedoel ik ook. Je bent gewend om dingen op jouw manier te doen. Dus b.v. ook een keyboard input, een bepaalde flow en als er dan ineens iemand het heel anders doet kun je wel een heel gekke en onverwachte dingen zien of gaan gebeuren. Software zonder fouten, als je het mij vraag bestaat dat niet
En bij iedere extra functie, update of aanpassing is de kans er gewoon dat er ook een fout wordt geintroduceerd...

[CivLord]

Maar dan moeten die derden wel bereid zijn om je code helemaal uit te pluizen. Dat doen de meesten niet voor niets (bug-bounties zij leuk, maar te onzeker om daar al je tijd op te gaan zetten). De big bucks in het vinden van fouten zit in het maken en gebruiken van exploits. Dus hoe makkelijker je het maakt om lange complexe code (te lang en te complex om voor de gemiddelde 'hobbyist' interessant te zijn om een paar weken 's avonds door te vlooien) door anderen in te zien, hoe makkelijker je het de makers van xploits maakt.

[Marve79]

Je kunt onmogelijk alles zelf vinden, al investeer je 100 miljard.

Ik moet wel zeggen dat $70K bounty weinig klinkt, voor zo'n kritische bug.

[batjes]

Dat is niet helemaal waar. Met een -praktisch- onberperkt budget is het prima mogelijk om foutloze code te schrijven.

De software voor het Apollo programma was bugvrij, geen enkele vlucht zijn er fouten geweest (buiten de fouten die veroorzaakt werden door kosmische straling, maar die fouten werden opgevangen door het systeem viervoudig uit te rusten). Nu is niet elk beveiligingslek een bug, maar veruit de meeste wel.

Voor praktisch alle software is de tijd en geld er niet voor om op dat niveau te komen.

[Huugje]

Nogal een aparte vergelijking. Programmatuur uit de jaren zestig is wat omvang betreft nauwelijks te vergelijken met dat van tegenwoordig. Logisch dat het dan ook eenvoudiger was om dat bugvrij te maken.

[Enai]

Eh, in de jaren zestig kon men met die beperkte software naar de maan. Tegenwoordig heeft men 8 MB aan js nodig en gaat enkel je surfervaring naar de maan.

[Huugje]

Daar ging de discussie niet over.

[batjes]

Klopt, toen moest nog elk bitje met de hand gezet worden. Spaceshuttle is ietsjes jonger en had ook 0 software fouten(genoeg andere fouten). Het is allemaal omvangrijker geworden, maar of het complexer is geworden.. Geen enkele moderne computer kan iets dat de Turing Machine niet kan (geef het wel de tijd ). De computers in Apollo waren hun tijd jaren vooruit. Bijna futuristisch.

Heeft vooral te maken met budget. NASA kan zich in veel van hun projecten gewoon geen fouten permiteren.

Foutloze code heeft geen exploits en er bestaat foutloze -complexe- code. Het ging mij om het hypothetishe onbeperkte budget.

Kleine nuance, ook voor @RGAT de Apollo software was bugvrij (er heeft zich tijdens het programma nooit een software bug opgetreden), Spaceshuttle was foutloos (geen enkele fout in ~500.000 regels code)

[_Pussycat_]

Dat er geen fout opgetreden is betekent toch niet dat de SW bugvrij is? Er zijn een paar maandlandingen geweest, dat veroorzaakt niet alle mogelijke input.

[mjtdevries]

Dat ligt ook aan je definitie van bugvrij.

Tijdens de landing naar de maan van Apollo 11 heeft Neil Amstrong uiteindelijk de computer navigatie uit gezet en is op handbesturing over gegaan omdat de computer steeds foutmeldingen bleef geven en het scherm een aantal keren secondenlang uit ging, waardoor de astronauten geen informatie meer hadden.

Dat is niet bepaald hoe de computer had horen te werken tijdens de landing.

Achteraf bleek de reden en was de computer druk bezig om andere dingen uit te zetten om te zorgen dat de kritische berekeningen (de navigatie) goed bleef werken.

Noem je dat een bug?
Het was absoluut niet de bedoeling dat de scherm een aantal keren uit ging tijdens die cruciale en gevaarlijke landing procedure. In de meeste definities valt dat wel onder de noemer bug.

Maar de software heeft wel gedaan wat het voor ontworpen was: alle prio geven aan de belangrijkste taak en de rest negeren.
https://medium.com/softwa...ed-apollo-11-4fb37dfad652

[WhatsappHack]

“Maar de software heeft wel gedaan wat het voor ontworpen was”

Dan is het toch letterlijk geen bug, maar een feature? Dat het effect van de feature niet gewenst is is dan weer een ander verhaal en dat kunnen de ontwikkelaars aanpassen. Maar de software deed 100% wat men dus doelbewust wilde dat het deed.

Als dat dus de bedoeling was, al had men er misschien niet goed over nagedacht, is ‘t geen software bug maar eerder een ontwerpfout.

-edit- verderop staat in een andere comment een link naar het hele verhaal. Er zat een “bug” in een ander onderdeel (eigenlijk hadden de astronauten iets uit moeten zetten blijkbaar, dus ook daar is “bug” discutabel), dat daardoor steeds nutteloos queries bleef sturen en daarmee de CPU dreigde te overbelasten. De “crashes” waren dus inderdaad geen bug maar een feature, maar de feature had niet in actie hoeven te komen als dat systeem niet nodeloos nog aan had gestaan en dure CPU-resources had benut.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:37]

[mjtdevries]

Dat het effect van de feature niet gewenst is

Dat hoort ook bij de definie van een bug.

https://nl.wikipedia.org/wiki/Bug_%28technologie%29

Een storing in de werking van een programma, ook wel goedmoedig "onbedoelde functionaliteit" genoemd

Dat de berekeningen door gingen maar schermen en allerlei andere zaken uitvielen tijdens de cruciale landingsfase was duidelijk onbedoelde functionaliteit. Niet voor niets zette Armstrong de computer uit, want die schermen met informatie hadden ze nodig.
En bij typische oorzaken van bugs staat:

onvoldoende rekening houden met alle voorkomende (normale) invoer en omstandigheden;

Wat hier duidelijk van toepassing is.

Dus volgens de definitie van wikipedia was het wel degelijk een bug.

Maar de software deed 100% wat men dus doelbewust wilde dat het deed.

Was het 100% doelbewust dat de schermen uit vielen en de astronauten geen flauw idee hadden of de computer nog de kritische berekeningen aan het uitvoeren was? Was het doelbewust dat het zoveel onzekerheid gaf dat Armstrong op handbediening over schakelde voor de landing?
Ik durf te stellen dat de programmeur die aspecten niet doelbewust voor ogen had.

[Reactie gewijzigd door mjtdevries op 23 juli 2024 06:37]

[CivLord]

Foutloze code heeft geen exploits en er bestaat foutloze -complexe- code. Het ging mij om het hypothetishe onbeperkte budget.

Dat hoeft niet zo te zijn. Foutloze code kan bij onverwachte (combinatie van) input onverwachte output geven. Dan kan de code 100% foutloos geschreven zijn, maar heeft de software toch een mogelijke exploit.

[RGAT]

Behalve de paar bugs die de software dus wel had... Daarnaast zal je vandaag meer dan genoeg potentiele lekken kunnen vinden in dergelijke software. Verschil is dat Apollo nou niet al te veel connecties naar buiten toe heeft zoals een webserver of cloud-based-virtualisatie-platform...

Perfect dichte code schrijven is makkelijk:

exit

Dit is perfect veilig in veel talen, het doet echter niets, geen functies etc.
Het is wel heel makkelijk te roepen dat software die niet te vergelijken is beter is, zelfde als roepen dat een fiets beter is dan melk...

[Caelestis]

Had een keer een toets op school 'exit' gebruikt in een debugging routine.
Kreeg een punt aftrek omdat ik het gebruikte.

[Wouterie]

Hoe kom je erbij dat de software bug-vrij was? De software deed wat het moest doen, maar om te stellen dat het bug-vrij is omdat het deed wat het moest doen, is een beetje kort door de bocht. "Ik kan typen en printen met Word dus het is bug-vrij." Tja.

[Taghorn]

Mwah, Apollo 11 had wel degelijk een bug in de code. Gelukkig niet kritiek. Vereist wel manual ipv automatisch flight:
https://www.wired.com/sto...1-mission-out-of-control/

[WhatsappHack]

Als ik dat hele verhaal lees, is volgens mij het probleem dat de astronauten iets aan hadden laten staan waarvan het eigenlijk uit moest. Dit genereerde meer load op de CPU dan kon tijdens dat extreem zware en cruciale deel van de vlucht, waardoor een fail-safe mechanisme binnen het OS routines met lage prioriteit een memory dump liet doen, dan de resources deed vrijkomen dmv een reset en zo de processen met top prioriteit konden blijven functioneren zonder enig dataverlies.

Volgens mij is dat dan human error + een feature ipv een bug die de “crashes” veroorzaakt? De software deed precies waarvoor het doelbewust ontworpen was om zo te functioneren als ik ‘t zo zie. Afijn.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:37]

[arthur-m]

Super interessant trouwens dat bit-flipping. Heeft YT channel veritasium recent nog een aflevering over gemaakt: https://youtu.be/AaZ_RSt0KP8

[cracking cloud]

Precies. Ik bedoel maar, security is enorm complex

[Iblies]

Je kunt onmogelijk alles zelf vinden, al investeer je 100 miljard.
….

Sorry maar dit is extreem onzinnig en een dooddoener.

Waar het draait is dat je afwijkingen relatief snel kunt opmerkingen, inventariseren, repliceren, etc, etc.
Dat werkt niet met een database die in alles een beetje goed moet zijn op een platform dat ook allerlei partijen moet bedienen.


Wat je dan nodig hebt zijn specialisten die het complete proces continu in de gaten houden en indien nodig zelf software gaan schrijven.


En de illusie;

al investeer je 100 miljard.

Hou op. If you pay peanuts, you get monkeys.
Alleen de benelux zou onder het mom an “staatsveiligheid” 1000den mensen in dienst moeten hebben die niks meer of minder doen dan code schrijven, inventariseren, aanpassen, etc. Het idee moet worden losgelaten dat iets van staatsbelang is geworden, toevertrouwd moet worden aan een commercieel bedrijf uit de VS dat zowel andere belangen kent en ten alle tijde aan de VS-overheid verantwoording moet afleggen.


1 mld euro kan je ruwweg 10k programmers opleveren a 100k de persoon. Mijn inziens compleet verantwoord gezien de belangen.

[Reactie gewijzigd door Iblies op 23 juli 2024 06:37]

[crazyx]

Dus je hoopt specialisten te vinden voor 100k per persoon, en dan ook nog 10.000 stuks. En die hebben blijkbaar geen overhead.

Het soort mensen die hier goed in zijn, zijn heel erg schaars.

[Iblies]

Het soort mensen die hier goed in zijn, zijn heel erg schaars.

Heb je daar niet al het probleem 🙂 Op dit moment wordt er heel veel verwacht van een heel klein groepje mensen waar ook aan alle kanten aan wordt getrokken.

En het gevaar daarbij is dat een lek bij wijze van een halve opleiding nodig heeft, je moet in grote lijnen weten hoe het werkt maar je hoeft het niet op te lossen.


Gezien de afhankelijkheid lopen we al minstens 10 jaar achter en blijven we achter lopen waarbij alle kaarten op enkele commerciële instellingen is gezet.

[CivLord]

1 mld euro kan je ruwweg 10k programmers opleveren a 100k de persoon. Mijn inziens compleet verantwoord gezien de belangen.

Wanneer je € 100.000 beschikbaar stelt om iemand in dienst te nemen, betekent dat na huisvestingskosten, apparatuur, sociale premies en belasting dat zo iemand misschien 30.000 netto overhoudt. Hoeveel specialisten van het niveau dat jij bedoelt zijn bereidt om voor ongeveer € 2.500 netto per maand te werken?
Misschien moet je wat minder gevatte quotes gebruiken (jij bent hier degenen die peanuts wilt betalen) en je redenatie iets beter doordenken.

[Iblies]

Geen idee welke methodieken je er op nahoud ?

Na werkgeverslasten kom je uit op ongeveer 70k bruto,

https://www.berekenhet.nl...etto-salaris.html#calctop
is 46k netto,
delen door 14 (vakantiegeld en extra maand), +3400 netto per maand .

Misschien moet je wat minder gevatte quotes gebruiken (jij bent hier degenen die peanuts wilt betalen) en je redenatie iets beter doordenken.

Je bent vrij om uit te leggen waarop deze emotionele explosie is gebaseerd, namelijk niet op feiten.

[CivLord]

Misschien moet je eens met een werkgever gaan praten. Die zal je vertellen dat jouw methode niet klopt.
Maar ook voor € 3.400 netto per maand krijg je niet de door jou gewenste specialisten.

Wanneer je mijn laatste opmerking een emotionele explosie noemt ben je zelf een beetje emotioneel in de war vermoed ik.

[Iblies]

Misschien moet je eens met een werkgever gaan praten. Die zal je vertellen dat jouw methode niet klopt.

Kun je dit ook toelichten anders dan alleen claims waar je dus geen verstand van hebt?

Maar ook voor € 3.400 netto per maand krijg je niet de door jou gewenste specialisten.

Volgens jou rekenmethode , dus delen door 12, kom je uit op +€3800 netto.

Welke bronnen gebruik jij uberhaupt?


Dan kun je wel heel populair gaan roepen “dat je de specialisten” niet kunt krijgen,
maar dat is juist het verwijt.

Hoe kan het dat we hier niet een eigen bataljon aan codeurs hebben terwijl Microsoft er volgens een recent artikel +47k heeft,
https://www.theverge.com/...arning-numbers-statistics

Zal nou meer zijn,
maar gezien hun productfolio is dat niet extreem veel werknemers.

[CivLord]

Welke bronnen gebruik jij uberhaupt?

Ik gebruik mijn dagelijkse ervaring op het gebied van lonen, loonheffingen en loonkosten.
Ik heb er dus iets meer verstand van dan jij.

[Iblies]

En dat zeg je tegen een fiscalist die bij verschillende bedrijven langskomt met hun verschillende cao’s en extra regelingen 👍


Heeeeel goed van je dan met je delen door 12.

[CivLord]

Ah, dan ben jij dus die fiscalist die mooie praatjes verkoopt en vertrokken bent wanneer de belastingdienst langs komt voor een controle en een paar fikse correcties oplegt!

Wanneer je snel iets uitrekent en op grofweg 10.000 afrondt dan maken een paar honderd euro verschil tussen 1/12 of 1/14 ook niet zo veel uit. Misschien heb je er over heen gelezen dat ik ongeveer schreef. Delen door 14 had het netto maandloon nog eens grofweg € 350 lager gemaakt en had mijn argument dus nog sterker gemaakt.

[Iblies]

Probeer je je eigen onkunde te verbergen door mij te proberen ridiculiseren.

Wat schattig 😇

Wanneer je snel iets uitrekent en op grofweg 10.000 afrondt dan maken een paar honderd euro verschil tussen 1/12 of 1/14 ook niet zo veel uit. Misschien heb je er over heen gelezen dat ik ongeveer schreef. Delen door 14 had het netto maandloon nog eens grofweg € 350 lager gemaakt en had mijn argument dus nog sterker gemaakt.

Geen idee wat voor administratie regels dit allemaal zijn.

Een werknemer die 100k pj kost,
daar ontvangt de werknemer ongeveer 2/3 bruto van, de rest is ruwweg werkgeverslasten en kosten werkplek.

70k bruto betekent 46k netto.


Als 46k-30k= 16k verschil voor jouw binnen de marges valt en je maakt mij verwijten 😁🤣

[Goffo]

Vallen bounties onder die 1 miljard?

[Vinnie.1234]

Geen fouten/kwetsbaarheden is praktisch onmogelijk... Wat gister veilig was, is dat vandaag niet meer

[BytePhantomX]

Dat er bugs zijn, dat is haast niet vermijden. Alleen de manier waarop Microsoft er mee omgaat is bedroevend. Printernightmare duurt maanden voor het gefixed is en ze zijn niet volledig open over of het nu wel of niet is opgelost. De vorige lek in Azure werd ook beperkt bekend gemaakt. En bij deze zie je ook dat ze 'moeilijk' doen:

Despite the obvious severity of OMIGOD—which includes four separate but related bugs Wiz discovered—the company had difficulty getting Microsoft to pay it a bounty for its discovery and responsible disclosure. In a series of emails Ars reviewed, Microsoft representatives initially dismissed the vulnerabilities as "out of scope" for Azure. According to Wiz, Microsoft representatives in a phone call further characterized bugs in OMI as an "open source" problem.

Technisch zal het natuurlijk kloppen, maar als er responsible disclosure wordt gedaan op iets dat zoveel impact de Azure omgeving heeft, dan is 70k toch helemaal niks?

Microsoft heeft als mantra dat alles naar de cloud moet omdat het dan bij default meer secure is. Dan is het beschermen van je reputatie en hoe pro-actief je met dit soort dingen omgaat gigantisch belangrijk. En naar mijn idee maken ze hier recent erg veel missers.

[hiostu]

Zelfde reden dat een bedrijf als Apple miljarden spendeert aan de veiligheid van de iPhone, en ze toch elke keer weer nieuwe jailbreaks vinden binnen enkele dagen/weken.

[fapkonijntje]

Zelfde reden dat een bedrijf als Apple miljarden spendeert aan de veiligheid van de iPhone

Is dat zo? Hoe kom je daar zo bij? als iOS 12 en 13 enige indicatie zijn geweest is security en testen niet meer zo heel belangrijk voor Apple geweest en by design is de integratie van iMessage en Safari in iOS ook gevaarlijk. Ik zie ze daar weinig aan doen. Als ze echt miljarden spenderen aan die veiligheid, dan ben ik benieuwd wat ze voor dat geld doen, want veel resultaat is er de laatste tijd niet.

[hiostu]

Dat ligt er heel erg aan. iOS14 voor 2 specifieke processoren was binnen 5 dagen beschikbaar (Checkra1n). Geen enkele jailbreak heeft jaren geduurt overigens. Maar de gemiddelde tijd nam zeker in het begin sterk toe.

[HollowGamer]

Waarom doen bedrijven als MS altijd zo moeilijk als onderzoekers lekken melden? Je bent toch blij dat ze deze lekken melden en je daarmee schade/rechtszaken voorkomt?

Verder zijn de vergoedingen voor dit lekken nog altijd veel te laag, als je een exploit verkoopt krijg je veelal het tienvoudige ervan. Een CEO krijgt miljoenen op zijn rekening gestort per maand, maar een vergoeding van 10k-15k is schijnbaar een te hoog bedrag voor dit soort ernstige lekken?

Voor mij mogen dit soort bedrijven (FB bijvoorbeeld ook) harder worden aangepakt. Je kunt niet doen alsof dingen niet in je scope vallen en je dus niets kan doen aan hacks/lekken van (gebruikers)data - terwijl onderzoekers dit juist wel melden. Het kromme is dat zij wel schuldig worden bevonden als ze hun exploits dan openbaar delen.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 06:37]

[Osiummaster]

Haha idd. 70K voor een gigantische bug, dit is bijna oplichting van Microsoft. Misschien willen ze bug-reporters afschrikken zodat ze op papier minder bugs hebben.

[HollowGamer]

Is het 70K? Dat vind ik nog vrij hoog, normaal liggen die vergoedingen lager dan dit, zelfs voor een serieus lek als deze.

Ik denk dat het vooral een soort damage control is, doen alsof het niet ernstig is zoals de politiek vrijwel dagelijks doet en verantwoording afschuiven (persoonlijke mening). Als ze lekken downplayen dan voorkomen ze natuurlijk ook weer problemen voor hunzelf, maar tegenwoordig zitten er zoveel persoonlijke data in de cloud dat ik vind dat ze er niet zo eenvoudig mee moeten wegkomen.

[nehal3m]

Omdat de security researchers bij Microsoft anders vertrekken en zelfstandig voor de bug bounty gaan werken. Waarom zou je voor 100k per jaar bij MS blijven werken als je met 2 van deze bugs 40% meer verdient?

De realiteit zal iets genuanceerder zijn dan dat (want wie zegt dat je die 2 bugs vindt, keert MS dan ook uit, en op tijd, etc), maar er zit een bovengrens aan wat je kunt uitkeren voor een bug bounty omdat je jezelf anders in de vingers gaat snijden.

[EagleTitan]

Het is de tweede keer in relatief korte tijd dat er een kwetsbaarheid wordt gedicht in Azure.

Derde keer zelfs: https://unit42.paloaltone...zure-container-instances/

[Darth TNT]

Niemand anders hierzo die leest dat de firewall uit moet staan voor deze hack om echt gevaarlijk te zijn?

[CivLord]

Ja. Dat vond ik ook al vreemd.

Dit is meer zo'n lek als: Wanneer je je voordeur openzet kan je met een nagelvijltje zo de keuken binnen komen.

[mutley69]

De druiven waren bij ons ook zuur dit jaar - letterlijk. Maar dit smaakt zoet! geen idee waarom? (misschien tip: meervoudig veroordeeld monopolist?)

[hiostu]

Heb je ook een bron voor je claim?

[Qws]

Er was een mooie Reddit post hierover, maar dit is het enige wat ik nu kon vinden: https://en.wikipedia.org/wiki/List_of_data_breaches

Microsoft staat behoorlijk hoog met het aantal data-breaches. Zowat elke jaar wordt er een tak van Microsoft gehackt.

Google and Amazon worden amper gehackt.

[Reactie gewijzigd door Qws op 23 juli 2024 06:37]

[hiostu]

Microsoft staat 1x in de lijst en Amazon en Google ook. Nog steeds geen overtuigend bewijs voor het statement dat je maakt

[Qws]

Ja Amazon Japan en Google Plus jaren geleden...

Dat is toch niet te vergelijken met Microsoft's 250 miljoen klanten gegevens exposure. Ook vorige maand weer 35 miljoen klanten gegevens van Microsoft op straat .

En nu vandaag weer mega groot lek in Microsoft Azure. De beveiliging is echt niet in orde bij Microsoft...

[hiostu]

Hou toch op joh, mega groot lek... Er was een vulnerability en die is gefixed. Er is hier niet eens sprake van een lek.

En die 38 miljoen was helemaal geen datalek. Dat waren organisaties die gebruik maken van PowerApps, maar zelf niet goed hebben gekeken naar de configuratie settings. Standaard worden datasets benaderbaar gemaakt en dat moet je als gebruiker die een powerapp zelf instellen of je dat wil op niet. Daarvan kun je zeggen dat het wel of niet handig is. Maar feit blijft dat het gewoon een gedocumenteerde feature is, waar andere bedrijven niet goed naar hebben gekeken. Dat valt absoluut niet onder een data lek of vulnerability. Dat is meer alsof ze een slot leveren op je voordeur wat standaard open staat en jij als bewoner zelf dicht moet doen. Als je dat niet doet, dan kunnen mensen zo naar binnen lopen.

[D11]

Heb je hier een bron van? Kan het zelf zo snel niet vinden.

[xehexehex]

Als er een (in-VM) firewall actief staat tussen de machines, waarbij je er vanuit mag gaan dat de OMI (remote) poort dicht staat, zal het overnemen vanuit een single machine naar de rest van het interne netwerk (c.q. VM's) volgens mij niet mogelijk zijn. Als het om een socket gaat, kan dit wel (maar tot op een bepaald user-niveau). Azure FW staat sowieso wel aan (by default).

[Reactie gewijzigd door xehexehex op 23 juli 2024 06:37]