De beste stuurlui staan aan wal.

Neem vooral zelf eens de moeite om goed in Assembly of C/C++ te leren programmeren.

karma4 heeft het posten als anoniem ontdekt? Bovendien is er al een topic van redactie hierover (hieronder als klikbare link):

https://www.security.nl/posting/634385/Vpn%27s+op+Linux%2C+macOS%2C+iOS+en+Android+kwetsbaar+voor+aanvallers

Precies, daanom hebben we in de wereld ook zo weinig problemen met ransomware en zo.

Verder stel ik voor om inhoudelijk te reageren onder het redactionele topic hierover:
https://www.security.nl/posting/634385/Vpn%27s+op+Linux%2C+macOS%2C+iOS+en+Android+kwetsbaar+voor+aanvallers

Psst... Check even de tijden van de posts. Deze post kwam eerder.

L.S.,

Zie een eerdere gelijkaardige kwetsbaarheid met mogelijke oplossing als patchvoorbeeld uit 2017.
Dit omdat steeds bepaalde eerder gebruikte patronen zich voortdurend dreigen te herhalen:

Dit is mogelijk een eerdere work-around ook voor een dergelijk probleem
met gebruikmaking van de "range-filter.module".

info credits gaan naar nginx dot org.

waarvan akte,

luntrus

Het probleem is ontstaan na 28 Nov 2018, dus ong. een jaar geleden. Juist doordat de code inzichtelijk was voor de onderzoekers is het lek ontdekt dus precies wat jij als verwijt gebruikt heeft er voor gezorgd dat het gevonden is.

In de gesloten OS'en zullen we nooit zien welke bugs daarin zitten.

Kost alleen wel een jaar, waarbij het probleem in meerdere OS'sen zit. Dus vele ontwikkelaars hebben dik een jaar zitten slapen.
Al zullen sommige personen dit al lang gevonden hebben, en waarschijnlijk misbruikt hebben.

Niet zo achterdochtig. Ik heb de herleidbaarheid hoog en hoe niet zo van anoniem afgeven.
Volgens mij zie je overal gevaar en bedreigingen, echter alleen degene die open en bloot zichtbaar zijn ontgaan je volledig.
Er zijn er kennelijk meer die het os-bashing met een os evangelisme, zoals je dat toont niet goed vinden.

Wat ik eerder opvallend vind is: https://www.ru.nl/ict/@1177614/twee-keer-ddos-aanval-week/
Niet omdat ze met een DDos te maken hebben via het externe deel, echter:
https://www.ad.nl/tech/universiteit-vijf-keer-doelwit-ddos-aanval-tentamen-afgelast~a6853703/
Het afgelasten van tentamens examens waarvan je verwacht dat het op een geïsoleerd interen netwerk zou draaien.

Als dat soort netwerksegmentatie met risicoanalyse ontbreekt is het slecht met de informaticakennis. Alsof het zo moet zijn het uitgevallen tentamen is die van informatica.
https://www.ru.nl/opleidingen/master/cyber-security/ Wonderlijk het ontbreekt zefs als onderwerp.
"The Master’s specialisation in Cyber Security will teach you how to contribute in the design of new security systems. You’ll be able to draw up the security requirements of an application and discover where possible weaknesses lie. Main focus lies on topics as cryptographic codes, operating systems and protocol verification. But you will also get a broad scope of cyber security to include mathematical, organisational, legal and ethical aspects, with particular attention for privacy issues." Zo wordt het nooit wat met security.

Ach, een paar jaar terug vonden ze een 33 jaar oud defect in open source code. Ik praat het niet goed, maar het gebeurt.

Om over heartbleed nog maar te zwijgen. Bij zoiets zul je ook nooit weten of het echt "oeps foutje" was of dat het "sommige personen" doelbewust het naarbinnengemanipuleert hebben.

Dat zal best. En als je dan bedenkt dat "sommige personen" wel toegang hebben tot allerleu gesloten software maar jij en ik niet...

Als programmeur en systeembeheerder en knutselaar zeg ik dan toch, geef mij maar iets dat open is, dan kan ik er veel meer en veel gemakkelijker meer mee dan als het gesloten is.

Mischien dat meer mensen zich bezig zouden moeten houden met code review, gewoon als een soortement van tijdverdrijf. Niet meer "google summer of code" maar "google summer of code review". Dat je als nieuweling niet alleen maar code schrijft maar vooral ook andermans code leest, om te leren van hoe het wel moet, en ook hoe het niet moet, en dus ook om foutjes op te sporen. Want het is nog best een probleem, dat met de bugs enzo.

Dat is de datum dat de defaultwaarde voor een kernel-parameter die door systemd wordt ingesteld in de systemd-configuratie is veranderd. Dit gaat ook over OpenBSD, FreeBSD, MacOS, iOS en Android, en daar wordt systemd helemaal niet in gebruikt, en bij vier van die besturingssystemen zijn Linux-kernelparameters niet van toepassing omdat ze geen Linux-kernel gebruiken. Daar komt nog bij dat de genoemde instelling voor IPv4 is terwijl de kwetsbaarheid ook voor IPv6 geldt.

Ik denk dus niet dat je het hele probleem aan die datum kan koppelen.
Als ik lees hoe de onderzoekers het beschrijven krijg ik de indruk dat men druk met netwerkverkeer heeft zitten experimenteren en manipuleren en dat men het zo gevonden heeft. Zo'n benadering is onafhankelijk van broncode, en er worden ook zat problemen gevonden in software waarvan de broncode niet openbaar is.

De uitspraak "many eyes make bugs shallow" is een observatie over het Linux-kernelproject, een project waar vele (1000+) veelal zeer professionele mensen aan meeontwikkelen. Door de open manier van communiceren, het feit dat de broncode voor al die mensen beschikbaar is en ongetwijfeld ook het feit dat er geen management rondloopt dat tegenwerkt dat mensen verder kijken dan het werk waarvoor ze zijn ingepland, krijg je het verschijnsel dat als een bug, als die eenmaal onderkend wordt, vaak snel en goed wordt opgelost. Dat komt omdat de kans groot is dat er onder al die betrokkenen iemand is die er op net een inzichtelijke manier tegenaan kijkt die maakt dat het probleem makkelijk te begrijpen en vervolgens makkelijk op te lossen is. Het is een manier van werken die bevordert dat de juiste inzichten makkelijk aan problemen gekoppeld worden. Maar dan moet men zo'n probleem wel eerst onderkend hebben.

Wat het uitdrukkelijk niet is, en zo is het ook nooit bedoeld, is een claim dat als je broncode maar openbaar maakt dat alle bugs die erin zitten vanzelf wel worden herkend. Helaas zie je maar al te veel mensen, zowel mensen die open source verdedigen als mensen die het aanvallen, die het desondanks toch zo framen.

Iedereen die programmeert weet dat je fouten maakt, dat je ze vaak zelf niet ziet, en dat het echt niet zo is dat bugs in code die je onder ogen krijgt van een zwaailicht en sirene zijn voorzien. Vaak herken je pas dat er iets niet klopt als je er op de juiste manier naar kijkt, en die juiste manier wordt gekleurd door je achtergrond en het onderwerp waar je op dat moment mee bezig bent.

Bij een bug als deze is het een complexe wisselwerking van gebruiksfactoren die maakt dat code die vermoedelijk keurig in elkaar zit, grondig getest is, vaak bekeken is, toch nog een zwakte blijkt te hebben door de manier waarop dingen in dit specifieke scenario bij elkaar komen. De pest is dan dat je de zwakheid in de code pas herkent als je hem met dit scenario in gedachten bekijkt. En niemand is zich bewust van dat scenario totdat iemand het bedacht heeft. De pest is dat je niet alles kan bedenken. Probeer maar eens om op te sommen waar je allemaal niet aan denkt. Dat is onmogelijk.

Dit is niet iets waar open source een wondermiddel voor is, en het is evenmin zo dat dergelijke fouten in een gesloten OS per se moeilijker te vinden zijn. En het is, of je open source nou een warm hart toedraagt of niet, onzin om je "discussies" te baseren op iets dat eigenlijk niet meer dan magisch denken is.

Volgens mij zie jij alleen de spoken die zich - alleen - tussen jouw oren bevinden en geef je ze naar willekeur namen als 'evangelisme', 'os-bashing', etc.

Ik zeg maar weer eens touché. Je last je weer keen wat je dwars zit. Jou os daar kan niets mis mee. Een ieder die daar het niet mee eens .... ik zie geen spoken.
Jij wel als je bij elke kritiek denkt dat het van mij moet zijn.

Je belabberde taalgebruik en warrige denkwijze hebben je verraden.

Je hebt het wel vaak en met veel verschillende mensen aan de stok, zou het aan die mensen liggen dat er met jou niet fatsoenlijk gediscussieerd kan worden en dat het vaak op ruziën uitdraait?

Enfin, ik ben er klaar mee, saluut Karma4.

Kwitny.

Ik ook! Saluut karma4!

Als je ziet hoe lastig het is om fatsoenlijke url's te plaatsen (je had ulr ipv url staan) dan mogen ze wat mij betreft gerust deze bug maken, zolang deze wel gepatcht wordt.

Maar C heeft zoveel problemen en die komen hoofdzakelijk uit een x aantal feiten:

1. Dat het zoveel gebruikt wordt.
2. Dat de standaard nog altijd backwards compatible is terwijl een backwards-incompatible versie echt nodig is zodat er noodzakelijke dingen kunnen worden veranderd.
3) Manuele geheugengebruik is natuurlijk iets wat je zowel goed moet kunnen doen maar ook een bron van ultieme frustraties en bugs.

De liberale aanpak van C leidt tot heel veel problemen simpelweg omdat de taal voor velen te lastig blijkt te zijn. Er zijn ook alternatieven voor C maar dan kom je ofwel in een GC taal uit ofwel in een taal als Pascal (goed), Rust (bad) of Ugly (Ada / C++). Er zijn ook alternatieven zoals V, maar daar zeg ik bij dat die taal nog serieus in de ontwikkeling is. Hier, als de wereld op Pascal (of de opvolger Oberon) zou zijn overgegaan dan zouden we een heleboel minder bugs hebben en zowel een goede programmeeromgeving hebben als ook een supersnelle codebase. Maar goed, we zijn allemaal geobsedeerd door C en dat geeft een problematiek die super lastig is.

Je bevestigd enkel dat het OSS / Linux evanelisme een groot probleem is. Elke kritische noot wordt als een persoonlijke aanval ervaren en de boodschapper moet zowat gelynched worden. Noem jij dat discussiëren en met argumenten bezig zijn.

Geef die bevestiging maar vaker.
Het help hopelijk tegen die cultuur en daarmee de ellende die het veroorzaakt.

@ Reactanten in deze draad,

Niemand die hierop inhoudelijk reageerde: nl. de bovenstaande reactie van 06-12-2019, 22:43 door Anoniem,
ondergetekende dus.

Het gaat toch om een kwetsbaarheid, ongeacht het OS, waar een oplossing voor dient te komen?
Al het andere is in mijn nederige beleving "luchtfietserij" van zich steeds in stellingen vastbijtende evangelisten.

Zo voorspelbaar overigens en tevens vaak zo nutteloos. De argumenten zijn al "tig" keren onderling gewisselend,
en een "common ground", iets wat ik zo graag zou zien, is niet of nog steeds niet beschikbaar.

Code blijft code, C++ blijft verduveld moeilijk te de-buggen en geeft dat dan eens toe.
Javascript blijft een code-moeras met krokodillen met wijdopengesperde bekken,
liggend te midden van de onstuimige code-poel, waar menig coderende aap in dreigt te vallen.

De "knipper en plakkers" en andere leentje-buur spelers komen het eerst tussen de vermalende kaken
en niemand denkt erom de bek dicht te binden, want het dichtklappen gaat met veel grotere kracht,
dan de mogelijkheid tot opensperren. Wie brengt dat stukje patchend duct-tape?

Gaan we weer echt aan de slag of zijn we alleen maar IT-pretendenten?

luntrus

luntrus, leg eens uit, wat staat hier? En hoe is het relevant voor deze draad?

Een kwetsbaarheid die in verschillende besturingssystemen voorkomt moet in elk van die besturingssystemen worden opgelost. Het is geen oplossing ongeacht het OS, het is een oplossing die op maat gemaakt moet worden voor elk OS. Zelfs als zou blijken dat de OS'en in het relevante onderdeel dezelfde code delen dan nog is dat in een context waar verschillen in kunnen zitten die per OS, door de makers van elk OS, nauwgezet beoordeeld moeten worden en mogelijk tot verschillen in de uiteindelijke implementatie leiden.

De Linux-kernel is in C geschreven, niet in C++. Voor zover ik weet geldt dat ook voor FreeBSD en OpenBSD. Wat Apple allemaal aan talen heeft toegepast overzie ik niet, maar aangezien zij zich op Unix-code gebaseerd hebben en Unix ouder is dan C++ en oorspronkelijk in C is geschreven, is de kans ook daar aanwezig dat de betreffende code in C geschreven is. Het codefragment dat je zelf plakte is trouwens ook in C geschreven, niet in C++.

Kan zijn, maar JavaScript heeft geen enkele relatie met dit probleem.

Waarom plakte je zelf een stukje code uit een webserver, totaal ongerelateerd dus aan de code in de code in de betrokken besturingssystemen, als je geen leentje-buur-speler bent? Je introduceerde het met:
De code die je plakte is een bugfix voor de afhandeling in een webserver van een HTTP-header die, bij HTTP-responses die een gedeelte van de totale response overbrengen, aangeeft welk deel van de response in dit bericht zit. Dat is wel heel anders dan code in de netwerkstack van een besturingssysteem die gevoelig is voor het injecteren van pakketten die mogelijk over de verkeerde netwerkinterface binnenkomen voor de betreffende verbinden. Het is geen gelijkaardige kwetsbaarheid en het zit in andersoortige software; de overeenkomst gaat niet verder dan dat het allebei met netwerkverkeer te maken heeft en allebei in programmacode zit, maar niet in dezelfde code. Dat is een veel te vage overeenkomst nog iets op te leveren waar een programmeur praktisch iets mee kan.

Ik vind dat eigenlijk een behoorlijk pretentieuze vraag voor iemand die programmeertalen op een hoop gooit, besturingssystem en webservers op een hoop gooit en verschillende OSI-lagen op een hoop gooit. De reden dat ik geen aanleiding zag om op je post te antwoorden was dat ik vond dat hij de plank op wel erg veel niveau's tegelijk missloeg, wat hem in mijn ogen irrelevant maakte voor het onderwerp van deze pagina.

My two cents:

Zowel de Linux community heeft haar evangelisten, maar dit geldt evengoed voor de Windows adepten en de Mac fetisjisten. Maar helaas, er bestaat geen beste OS. Er bestaan alleen OS die voor jou het beste is. Voor mij is dat Linux, Ubuntu om precies te zijn en er zullen veel mensen zijn die daar helemaal niets van begrijpen.

Kwetsbaarheden vind je in alle OS, sterker met een aan zekerheid grenzende waarschijnlijkheid vind je kwetsbaarheden in alle software.

Ik prefereer om meerdere redenen open source software en gebruik alleen gesloten source software als er geen open oplossing is.

Ik vind het prettig dat in geval van open source een ieder de mogelijkheid heeft om de code door te pluizen of kwetsbaarheden en eventueel ook op te lossen. Een ding is zeker, bij gesloten source software is dit beduidend lastiger.

Zie deze link voor de ranking van software met de meeste kwetsbaarheden: https://www.cvedetails.com/top-50-vendor-cvssscore-distribution.php

Microsoft al jaren on lonely top, maar Linux zeker niet ver weg.

Wat ik wel heel opvallend vind is dat 2 grote gesloten source partijen zoals Windows en Adobe bizar hoog scoren als het gat om kwetsbaarheden met een 9+ rating, zeker als je dit vergelijkt met 2 bepalende open source pakketten als Mozilla en Wireshark.

En laten we wel wezen, het is onredelijk om software van Microsoft en Adobe als 'slecht' of onveilig te bestempelen. Het is ook evident dat zulke grote partijen grotere targets zijn en daardoor meer kwetsbaarheden opleveren.

Het is niet altijd zwart/wit, maar heel vaak grijs.

Bedoel je hier niet MICROSOFT ipv Windows?

Microsoft maakt ook heel veel producten zelf, dus zullen ze zeker ook hoog staan..

Klopt helemaal.

Ik ervaar kinderlijk trol gedrag als een vele male groter probleem dat in de weg staat van een fatsoenlijke draad.

Tot mijn (en vele anderen) ergenis ben jij vaak betrokken in dat soort trol draaden en weet jij dat gedrag enkel en alleen maar te katalyseren.

Ik zal daarom jouw eigen reactie eens CORRECT(er) maken:

"Je demonstreerd dat evanelisme een groot probleem kan zijn. Vaak wordt een kritische noot als een persoonlijke aanval ervaren en de boodschapper moet zowat gelynched worden."

Waarvan akte!

Scherp. Aangepast.