‘Lek Ruby on Rails snel dicht door open source’
Dat het recent gevonden lek in webapplicatieframework Ruby on Rails zo snel gedicht kon worden komt vooral doordat het om open source software gaat. Het dichten van een lek bij proprietary software zou een stuk langzamer zijn gegaan. Dit menen de Computable-experts Maurice Verheesen en Marc Vloemans. Zij roemen de snelheid waarmee het Ruby on Rails-lek gedicht werd, maar zij raden organisaties wel aan verder onder de motorkap te kijken of er van de software gebruik wordt gemaakt.
Bugs in software libraries die misbruikt worden door een exploit zijn theoretisch gezien gevaarlijk voor iedereen die de library gebruikt. Daarbij maakt het niet uit of het gaat om free/libre open source software of om proprietary software. Dat geldt voor alle software libraries.
Stuxnet op Windows-platform
‘Het is goed om te zien dat de bug in Ruby on Rails zo gruwelijk snel opgelost is’, zegt Maurice Verheesen, coördinator Nederland fellowship bij Free Software Foundation Europe. ‘Bij proprietary software zijn gebruikers volkomen afhankelijk van een leverancier. Deze moet dan vriendelijk verzocht worden de bug te fixen. In de praktijk zie je dat dit vaak erg lang duurt. Kijk bijvoorbeeld naar één van de bugs die Stuxnet misbruikt op het Windows-platform. Die was een halfjaar voordat Stuxnet bekend werd al gemeld bij Microsoft. Vervolgens werd vrijwel niets met de melding gedaan.’
Verheesen vermoedt dat de bug in Ruby on Rails door de community meteen is opgelost of dat Logius zelf een patch heeft geschreven. ‘Dat laatste was bij proprietary software niet mogelijk, dan wel bijzonder lastig geweest. Als DigiD/Logius deze patch aan de Ruby-community geeft, en de Ruby-community accepteert deze patch, dan kunnen alle programma’s die gebruikmaken van Ruby direct beschermd worden. Dus veel liever kijk ik niet naar wat allemaal Ruby on Rails gebruikt, maar het is veel belangrijker om te kijken of de patch al in de Ruby-community bekend is.’
Kwaliteit en veiligheid
Expert Marc Vloemans, directeur van B3Partners, vraagt zich af of het lek een inschattingsfout betrof ten aanzien van de toepasbaarheid van het webapplicatieframework Ruby on Rails of dat het de specifiek DigiD betrof. ‘In elk geval lijkt mij dit een typisch geval waarin de Ruby on Rails-community kan aantonen dat bij open source software inderdaad sneller veiligheidslekken kunnen worden gedicht. Er ligt immers de claim bij open source dat de kwaliteit en daarmee de veiligheid sneller kan worden gecontroleerd en verbeterd, door openbaarheid van de code.’
Volgens hem is het niet voor niets dat vele veiligheidsgevoelige organisaties zoals Defensie, overheden en banken, gebruikmaken van deze wijdverbreide software. ‘Het lijkt me daarom raadzaam voor deze organisaties om snel ‘onder de motorkap’ te duiken om te kijken of zij van Ruby on Rails gebruikmaken.’Eerst stellen ze:
Het dichten van een lek bij proprietary software zou een stuk langzamer zijn gegaan. Dit MENEN de Computable-experts Maurice Verheesen en Marc Vloemans. Zij roemen de snelheid waarmee het Ruby on Rails-lek gedicht werd
Vervolgens lees ik "Verheesen VERMOEDT dat de bug in Ruby on Rails door de community meteen is opgelost of dat Logius zelf een patch heeft geschreven."
en bij het vervolg door de andere expert die o.a. zegt: "VRAAGT ZIT AF"; "LIJKT"
Op basis van zoveel vaagheden vindt ik het een zeer zwak artikel, waarin vooral gepoogd wordt de open source community te roemen.
Laat me dan even een wedervraag stellen aan deze experts: als de open source community zo groot en zo goed is, hoe kan het dan dat geen van allen deze vulnerability in de code ontdekt heeft?
Wel heb ik de laatste decennia gezien dat de kans op het snel dichten van lekken groot is bij actieve OSS communities. Bij hen gaat het vaak een stuk sneller dan bij veel grote CS bedrijven. Die zijn meer gericht op het oplossen van problemen via de volgende grote release en op periodieke patchrondes. Daardoor duurt het oplossen bij de klant langer dan nodig. Kleine CS bedrijven doen het overigen meestal veel beter omdat ze gemakkelijker te vervangen zijn. Een arrogante houding kan ze snel de kop kosten
De kracht van de open source community is dat het gedreven vakmensen zijn, met liefde voor het vak die graag een goed product neer willen zetten. In het bedrijfsleven zijn die mensen er ook, maar moet er geld verdiend worden.
Wordt in open source software een issue gevonden, kan zo'n ontwikkelaar zich er meteen met hart en ziel op storten
In het bedrijfsleven moeten er eerst allerlei mensen een beslissing nemen of ze het betreffende probleem op willen lossen, en of het dan niet meer kost wat het oplevert enz enz enz.
Door deze houding van het bedrijfsleven wordt het vakmanschap van veel goede ict-ers gefrustreerd helaas.
Dat is enerzijds de kracht. Echter wordt er door veel van deze vakmensen niet full-time er aan gewerkt. Vaak is het een uit de hand gelopen hobby.
Het grote nadeel en voordeel van open source blijft hoe je het went of keert dat (bijna) iedereen de sourcecodes kan opvragen en aan mee kan ontwikkelen. En soms wil je juist niet dat bepaalde mensen je sourcecodes hebben.
Soms wil je uit veiligheids overwegingen niet dat de 'vijand' over de broncode beschikt (alsof dat voor een echte cracker wat uitmaakt)
Echt soms wil je ook niet dat de concurent ziet wat voor ongeloofelijke bagger met nog heel veel onontgonnen issues je bedrijf produceert.
OpenSource of ClosedSource is primarily een zakenlijk model.
Ik lees in dit soort discussies nooit over het aanpassen van software aan je eigen wensen.
Bij ClosedSource spul kan dat niet omdat je geen broncode hebt.
Bij OpenSource spul gebeurd het niet omdat we eigenlijk allemaal gewoon 'domme' gebruikers zijn.
Bij een ClosedSource omgeving is er een management decision die bepaald of een feature moet worden toegevoegd, aangepast, verwijderd.
Bij een OpenSource Community heb je te maken met lieden die zich moeten profileren.
Dan heb je vervolgens nog een combinatie van beiden wat dan weer leidt tot allerlij afsplitsingen (hoeveel welliswaar minder bekende varianten van MySQL en OpenOffice zijn er inmiddels ?)
Dat is toch wel gebeurd? En de bug is allang gefixed. Het is net als wat @MikeN zegt. Dit is de normale gang van zaken. Er worden *elke dag* honderdduizenden bugs gefixed in open source software. Continue. Alleen lees je daar bijna nooit wat van. Dat is heel wat anders dan wat je gewend bent bij proprietary leveranciers. Daar gaat vaak iemand pas wat doen als het in de krant staat.
@MikeN: "Verheesen had zelf ook even de gang van zaken op kunnen zoeken" Nee dat kon helaas niet. Ik was op die dag bij het https://www.ictu.nl/actueel/nieuws/nieuwsitem/artikel/begin-januari-symposium-in-groningen-over-open-ioverheid/ in Groningen. Natuurlijk werd het nieuws wel op de voet gevolgd, maar ook ik moet het hebben van officiële berichtgeving...
@Ruud Mulder "Vaak is het een uit de hand gelopen hobby." Kunnen svp van deze onzin nu eens afstappen? Google, Facebook, Spotify, Twitter geen enkele van deze start-ups zijn mogelijk zonder open source software. Zelfs Apple gebruikt het in hun producten. En ja praktisch alle techneuten van die organisaties zijn open source software contributeurs. En dat zijn echt geen hobbyisten! Voorbeeld: http://en.wikipedia.org/wiki/Guido_van_Rossum
@Pascal "Soms wil je uit veiligheids overwegingen niet dat de 'vijand' over de broncode beschikt"
Lees dit even http://www.schneier.com/crypto-gram-0205.html#1
en daarna dit http://tue.academia.edu/MauriceVerheesen je kan me ook altijd emailen als je vragen hebt.
18-06 Vrouw kiest bewust voor ICT-werkveld
18-06 SIG en TÜViT belonen Selektvracht met 5 sterren
18-06 Rechtbank verklaart Apple-huis iCentre failliet
18-06 Lager tarief drukt omzet Imtech ICT
18-06 BMP Datapartners en Gemini bieden ICT-leaseplan
18-06 Progress stoot Apama af aan Software AG
18-06 Mitel neemt toeleverancier prairieFyre over
18-06 KPN versnelt 4G-uitrol in Nederland
18-06 Acer structureert zakelijke divisie
17-06 Tegenstribbelende fusiepartner verbaast DPA
13-06 Deciso Netboard A10 krijgt AMD-CPU mee
13-06 Vasco vindt in AET alternatief voor Diginotar
12-06 id-me komt met vingerafdrukidentificatie voor...
06-06 Tips om veilig mobiel te werken
05-06 MKB ondervindt problemen bij back-up en herstel
05-06 Kaspersky stuit op cyberspionage NetTraveler
04-06 Cybersecurity: aanval is beste verdediging
04-06 McAfee pakt beveiliging compleet en geïntegreerd...
04-06 GFI Software lanceert FixIT Scripts
03-06 Reclassering introduceert thuiswerken in één dag
|
|
24-01-13 ‘Maatwerksoftware deed DigiD de das om’
17-01-13 ‘Ruby on Rails blijft zonder update risicovol’
17-01-13 Onverklaarbare platformkeuzes bij de overheid?
15-01-13 ‘Lek in Ruby on Rails heeft beperkte impact’
14-01-13 Ontwikkelen veilige software is complex
09-01-13 Lek in Ruby on Rails is griezelig
11-01-13 De voor- en nadelen van Ruby on Rails
15-01-13 Behandelen van parameters is complex
11-01-13 Top 3 gedupeerden door Ruby on Rails-lek
10-01-13 Lek in Ruby on Rails heeft veel kanten
14-01-13 Na Ruby on Rails volgt weer een ander systeem
10-01-13 Ruby on Rails-patch kan problemen opleveren
09-01-13 De gevaren door het Ruby on Rails-lek
11-01-13 ‘Dienst gebouwd op Ruby on Rails moet offline’
09-01-13 Logius haalt DigiD offline na lek in Ruby on Rails
DoS-aanvallen: strategieen om de schade te beperken
![]() |
De kans dat organisaties getroffen worden door een DoS-aanval is helaas reëel. Omdat er allerlei soorten......



Beetje een open deur. Verheesen had zelf ook even de gang van zaken op kunnen zoeken (zou wel mogen voor een 'expert'), dan was duidelijk geworden dat de problemen op dinsdagavond al bekend waren, maar er pas op woensdag iemand wakker werd bij Logius.
Inmiddels is het RoR verhaal ook wel een beetje uitgekauwd. Er zijn nu 15 artikelen over het lek verschenen, denken we niet dat inmiddels iedereen z'n zegje wel gedaan heeft? Het was een serieus lek, maar het is niet alsof dit soort lekken niet vaker voorkomen.