Bash-bug was waarschijnlijk al sinds 1992 aanwezig

De kwetsbaarheid in Bash die aanvallers een systeem laat overnemen, is waarschijnlijk al sinds 1992 aanwezig. Dat zegt de ontwikkelaar die verantwoordelijk is voor de shell. Al die tijd is de bug voor zover bekend onopgemerkt gebleven.

Chet Ramey, de vrijwilliger die verantwoordelijk is voor Bash, zegt tegenover The New York Times dat hij de bug waarschijnlijk in 1992 per ongeluk heeft geïntroduceerd. Ramey tekent daarbij aan dat hij dat niet zeker weet, omdat hij destijds nog geen gedetailleerde logs bijhield. Tot 12 september bleef de bug in ieder geval voor Ramey zelf onopgemerkt: toen werd hij getipt over het bestaan van het beveiligingsprobleem.

De bug is eenvoudig te misbruiken maar biedt vergaande toegang tot een systeem: een aanvaller kan eigen code uitvoeren op een systeem. Het is niet uit te sluiten dat het beveiligingsprobleem in de afgelopen 22 jaar al eerder is opgemerkt door onderzoekers die ervoor hebben gekozen om het lek onder de pet te houden en bijvoorbeeld te verkopen. Bedrijven als het Franse Vupen zijn gespecialiseerd in het vinden en verkopen van zogenoemde zero day-beveiligingsproblemen.

Inmiddels is de bug grotendeels geplet, al blijkt het in bepaalde gevallen nog steeds mogelijk om eigen code uit te voeren. Een systeem kan bovendien alleen worden beschermd als er een patch beschikbaar is. Het probleem is dat gebruikers apparaten als routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver vaak minder snel patchen dan een desktop-besturingssysteem, en daardoor nog jarenlang kwetsbaar kunnen zijn.

Volgens beveiligingsonderzoeker Robert Graham is de onderliggende code van Bash ernstig verouderd. De Bash-bug, die ook wel Shellshock wordt genoemd, is volgens hem niet meer dan een waarschuwing dat er meer bugs zullen volgen. "De oorzaak is niet een programmeur die een fout heeft gemaakt, maar een systematisch falen in de code", schrijft Graham, die aantekent dat er al drie vergelijkbare bugs zijn gevonden. "De code is verouderd en geschreven naar de standaarden van 1984 in plaats van 2014."

De kwetsbaarheid kan worden misbruikt door een aantal tekens, gevolgd door code, toe te voegen aan een environment-variabele. Zodra vervolgens een bash-sessie wordt geopend, blijkt die code te worden uitgevoerd. Elke applicatie die leunt op de Bash-shell is in potentie kwetsbaar. Daarbij gaat het onder meer om webservers, die om de tuin kunnen worden geleid met http-requests. Ook zijn dhcp-clients in potentie kwetsbaar: een dhcp-server zou eigen code op een pc kunnen uitvoeren. Dat is bijvoorbeeld een probleem op openbare wifi-hotspots.

Reacties (282)

[toonp]

Ik begrijp niet goed waarom de discussie zich zo toespitst op de bug, open versus closed source, en de kwaliteit van de code van bash. Mensen, bash is een zeer groot en complex programma. De kans dat er fouten in zitten is zeer groot, net als bij elk ander programma van die omvang en complexiteit.

Waar men zich wèl druk over moet maken is het feit dat onze bejubelde commerciële leveranciers slechts anderhalf à twee jaar updates uitbrengen voor hun producten. Zo zit de hele wereld nu opgescheept met miljoenen appliances (NASsen, telefoons, routers...) waarvan het simpelweg ONMOGELIJK is om de bekende kwetsbaarheden te fixen. Er komen namelijk geen updates meer voor uit.

[ReneX]

Veel van de fabrikanten zien hun producten nog steeds als een stuk hardware dat je ontwerpt, maakt en verkoopt. Om vervolgens verder te gaan met de volgende generatie. Support voor de vorige generatie is minimaal om van oudere generaties maar te zwijgen. Helaas zijn er geen tot weinig uitzonderingen hierop.

Overigens is bash mss wel groot en complex; maar het is dan voor groot en complex gemaakt door gebrek en goede architectuur en bagger code (het ziet er echt verschrikkelijk uit). Op zich is iets als een shell namelijk helemaal geen complex iets.

[Bonez0r]

"De oorzaak is niet een programmeur die een fout heeft gemaakt, maar een systematisch falen in de code", schrijft Graham, die aantekent dat er al drie vergelijkbare bugs zijn gevonden. "De code is verouderd en geschreven naar de standaarden van 1984 in plaats van 2014."

Ik weet niet om hoeveel regels code het gaat, maar is het geen idee om het gewoon helemaal opnieuw te schrijven? Al is de grootte waarschijnlijk niet het probleem, ik las in het vorige artikel iets over compatibiliteit.

[ReneX]

Op zich is opnieuw schrijven een optie, maar het probleem is dat er vaak veel verborgen functionaliteit in zit, en dat mis je bij het opnieuw schrijven (en dus problemen met bestaande scripts). Een andere mogelijkheid is constructie voor constructie verbeteren (bv de K&R stijl parameter passing omzetten) gebruik van standaard library functies verbeteren etc. Ik zelf zou er denk ik een combinatie van maken, stukken code opschonen en op basis daarvan stukken herschrijven. Zou het best willen doen, nu nog een sponsor

[mrtnvnl]

Op de site StackExchange staan een paar verbazingwekkende voorbeelden hoe simpel deze bug te misbruiken is. [link]

Echt erg simpel. Ik ga vandaag maar snel een aantal systemen onder mijn beheer testen op deze kwetsbaarheid!

Edit: typo.

[Reactie gewijzigd door mrtnvnl op 23 juli 2024 00:10]

[z1rconium]

Voor die voorbeelden heb je wel eerst access op het systeem nodig om de boel voor te bereiden voor de exploit, oftewel, een proof of concept, wat iets anders is dan daadwerkelijk in de praktijk toegepast succesvolle attack.

Desalniettemin is het een zeer enge bug.

[kdekker]

Voor degenen die denken dat een manager
a. slimmer is dan zijn programmeurs
b. de fout had kunnen voorkomen
kan ik simpel zeggen dat je verder moet dromen.

In de praktijk werken - zoals hierboven ook al ergens genoemd - programmeurs aan cruciale onderdelen in relatief kleine teams (max. 10 personen). Door de jaren heen zijn er vaak miljoenen regels code. Er is geen tijd, nog geld in open of closed source, om zomaar een security scan door je code te doen. In het ergste geval wordt 'buggy' gedrag geprefereerd boven een compatibiliteitsbreuk. M.a.w. al zou je precies de onveilige plekken weten, dan nog is je speelruimte beperkt om het op te lossen als de oplossing een incompatibiliteit introduceert.

Waar gehakt wordt, vallen spaanders. Ik hoop dat de hardste 'schreeuwers' hier zelf een A4-tje zonder spelfouten kunnen schrijven :-). Serieus: de spullen waar je over praat is vaak in C/C++ geschreven. Dat ga je niet zomaar omzetten in een andere taal. En dan nog: een Java VM is ook in C/C++ geschreven, net zoals de meeste interpretatie engines. Wat je ook aan tests hebt, er zullen bugs in de code blijven zitten (als je codebase een fors aantal regels telt = meer dan 1 miljoen). Ik ken geen andere programmeertaal, nog code generator die bug vrij is of 100% veilig is. Vroeger stond al in onze dictaten (=tekst van max 100 a 200 blz) van de HTS dat er gegarandeerd minstens 1 fout in het document stond + de garantie dat met het vinden van 1 fout, er altijd nog 1 in zou zitten.

Aangezien iedere opdracht binnen een vaste prijs/kwaliteit/mankracht verhouding opgeleverd moet worden en de prijs om de kwaliteit op 100% te krijgen oneindig hoog is, weet je het antwoord. Discussies krijgen dan vaak wel of een hoog Telegraaf gehalte (=hype) of een hoog 'beste stuurlui staan aan wal' gehalte.

Deze bug raakt alleen bash en alleen als dat remote aanspreekbaar is. Daarmee is/was de heartbleed bug van grotere impact dan deze bug. Als je al hard zou nadenken over wat je aan internet hangt, dan heb je de risico's al een stuk ingeperkt. Bewustwording op dit gebied is belangrijk, maar w.s. lastig te realiseren.

P.s. C/C++ code van 20 jaar geleden kan nog prima van deze tijd zijn. Met de kennis van nu, zou je best eens respect kunnen hebben voor de knappe koppen van toen. Niet alles evolueert ten goede :-).

[Reactie gewijzigd door kdekker op 23 juli 2024 00:10]

[Anoniem: 471038]

P.s. C/C++ code van 20 jaar geleden kan nog prima van deze tijd zijn. Met de kennis van nu, zou je best eens respect kunnen hebben voor de knappe koppen van toen. Niet alles evolueert ten goede :-).

Dat kan inderdaad. Maar dan heb je het over code die 20 jaar geleden was geschreven volgens de 'state of the art'. Ik doe zelf aan retro-programming, en ik gebruik dan ook nog steeds tools uit begin jaren 90, zoals Borland Turbo C++ en SAS/C op Amiga. De voorbeeld-code die daarbij zit is best nog wel 'modern'. Ook de code die ik zelf schrijf is op zich 'modern', maar wel binnen de mogelijkheden van die oudere tools natuurlijk.

Maar zoals de security-expert al opmerkt: De bash-code is zelfs voor 20 jaar geleden al enorm verouderd. Er wordt nog gewerkt volgens de K&R-standaard van C, niet de ANSI C-standaard.
Er zitten ook veel dubieuze dingen in, waardoor de code lastiger te lezen is (zoals het voorbeeld om een lus-variabele te updaten in de exit-conditie, ipv het derde veld van de for-loop, zoals gebruikelijk).
Zoals hij ook terecht aanstipt: door deze verouderde code-standaard kunnen ook statische analyse-tools weinig met deze code.

[kdekker]

Ik loop al even mee als programmeur, en moet constateren dat de C99 standaard er toch wel bijna 10 jaar over gedaan heeft om breed geadopteerd te zijn. En dan nog: K&R code herschrijf niet zomaar op een regenachtige vrijdagmiddag. Als code werkt, gaat men niet pro-actief de spullen aanpassen.

Wij hebben zelf ook nog een bak K&R code. De aanpassingen die de afgelopen jaren gedaan zijn hadden te maken met porten naar 64-bit. Om fatsoenlijke warnings te krijgen is/was ANSI proto-typing een must. Het porten naar 64-bit begon dus met het ANSI prototypen en een bak warnings oplossen.

Je reactie is zeer terecht, maar er blijven praktische redenen te over om geen code-refactoring te doen. Juist het ingewikkelde gebruik van impliciet toekennen/wijzigen van variabelen maakt overstap op nettere code een tijdrovende klus. Ook bij een open-source engineer moet de pijp roken en zal hier geen tijd voor zijn, als er geen inkomsten tegenover staan.

Wat dat betreft is een security lek een prima reden om geld te beuren voor een code-revisie. En voor bedrijven die denken dat open-source gratis is een correctie om weer met 2 benen op de grond te komen. Van closed-source weet je niet hoeveel soortgelijke bugs in hun code zitten. Ik denk dat het fenomeen open-source op zich wel een redelijke (of betere) garantie biedt dat dit soort fouten ontdekt kunnen worden dan closed-source.

[Anoniem: 471038]

Ik denk dat het fenomeen open-source op zich wel een redelijke (of betere) garantie biedt dat dit soort fouten ontdekt kunnen worden dan closed-source.

Ik niet. Ik gebruik zelf ook al jaren bash op een aantal systemen. Het is nooit in me opgekomen om de code te bekijken. Ik heb die code nu dus gezien, en het is inderdaad niet om aan te gluren. Had ik er eerder naar gekeken, dan was ik misschien al lang overgestapt op een andere shell.
Maarja, ik zou inderdaad niet zelf aan een code-refactor begonnen zijn.

En ik denk dat dat voor de meesten geldt: ze gebruiken wel open source, maar kijken eigenlijk de code nooit in. En zelfs al doen ze dat af en toe, en vinden ze dingen, dan zullen ze er nog weinig of geen tijd in steken, omdat je nu eenmaal andere dingen op je to-do lijst hebt staan.

[kdekker]

Je hebt in ieder geval de mogelijkheid om de code te bekijken. Die mogelijkheid heb je niet eens voor closed source. Ik zei ook 'kunnen worden'.

Wij gebruiken ook van alles aan open source. Je gaat pas in de code kijken als daar een reden voor is. Ieder open source product dat meer dan 10 (arbitrair getal) regels code bevat, bekijk je doorgaans niet.

[Anoniem: 471038]

Je hebt in ieder geval de mogelijkheid om de code te bekijken. Die mogelijkheid heb je niet eens voor closed source.

Ik wel, zoals ik elders al zei: reverse-engineering.

[kdekker]

Dan moet de nood echt hoog zijn, want dat kost echt veel tijd

[cdwave]

Ach,
...routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver...
hoe groot acht je de kans dat deze >1 MB van hun flash gaan spenderen aan de "bash" shell?

Deze draaien steevast busybox, en busybox' ingebouwde "ash" shell heeft deze kwetsbaarheid helemaal niet (geverifieerd met diverse versies op diverse systemen).

[Anoniem: 118226]

Ik hoop nu dat voor iedereen eindelijk duidelijk is dat open source alleen iets zegt over het licentiemodel en niets over kwaliteit of hoeveel mensen er daadwerkelijk naar kijken om er fouten uit te halen.

[gekkie]

Het zegt iets over hoeveel mensen (inclusief jezelf) er naar kunnen kijken. Inderdaad niet naar hoeveel mensen er werkelijk naar kijken, noch naar welk deel van de code ze kijken.

Vaak wordt alleen naar de wijzigingen gekeken, vaak ook nog vrij geisoleerd en komen de bugs uit interacties met andere delen van de code die niet gewijzigd waren. In dit geval is het ook weer een lastige afweging tussen code wel of niet refactoren. Refactoren kan er voor zorgen dat je betere code krijgt, maar kan opzich zelf ook weer nieuwe problemen en bugs introduceren. (de afdeling if it ain't (severly) broken don't fix it)

(overigens kun je met closed source er ook naar kijken, alleen niet in de hogere programmeertaal waarin het geschreven wordt, maar in assembly (waarbijvb software cracks vandaan komen)).

[Anoniem: 118226]

Bij de closed source software die ik voor mijn werk maak weet ik zeker hoeveel mensen er naar kijken en met welk oogpunt (daar hebben we namelijk procedures voor). Bij open source wordt door de fans altijd geroemd dat er veel meer mensen naar kunnen kijken, maar heel vaak blijft het bij kunnen.

Open source heeft beslist voordelen, maar het is niet per definitie veiliger of van betere kwaliteit. Open source zegt iets over het licentiemodel. Procedures en controle zegt iets over de kwaliteit.

[Blokker_1999]

We krijgen nu te maken met bugs die er door de jaren heen zijn ingeslopen, vermoedelijk in een tijd dat de kernprojecten van een Linux nog niet zo geprofessionaliseerd waren als vandaag. Vandaag word enorm veel code bijgedragen en nagekeken door grote bedrijven zoals RH, Novell, Canonical, ... waar ook procedures en controles zijn die er 20 jaar terug nog niet waren.

Het is inderdaad niet beslist veiliger of van betere kwaliteit. Maar ik heb liever dat iedereen kan zien wat er exact misloopt en dat er snel een oplossing komt dan wanneer er op een closed source project een kritieke bug komt en het bedrijf erachter nog weken nodig heeft om met een patch te komen of het probleem negeerd zolang het geen media aandacht krijgt.

[Anoniem: 118226]

Deze bug heeft niets met Linux te maken, maar zit in bash, die oorspronkelijk bij GNU vandaan komt.

Ik heb liever dat een bug snel opgelost wordt nadat deze bekend is geworden. Punt.

Ik denk dat Microsoft zijn zaakjes redelijk voor elkaar heeft. Apple heb ik af en toe mijn twijfels bij (alhoewel je mij wel als fanboy mag bestempelen). Oracle kan ook beter (en als java programmeur heb ik daar veel mee te maken).

Open source? Ik gebruik joomla voor mijn verenigingswebsite. Een drama. Heartbleed? De opensource community rolt nu nog over elkaar met forks links en rechts. Bash? Twee patches later is het nog niet voor elkaar.

Kortom, er kan nog wel flink wat verbeterd worden in software land (open of closed source)

[dtech]

Bash? Twee patches later is het nog niet voor elkaar.

Maar die patches waren er binnen enkele dagen. Bij microsoft zou je (gemiddeld) 2 weken wachten tot de volgende patch tuesday.

De opensource community rolt nu nog over elkaar met forks links en rechts.

Dit is een zeer foute weergave van de situatie. Er zijn nu 2 forks: LibreSSL (OpenBSD) en BoringSSL (Google). Die van Google stond al langer in de steigers (en was de reden hearthbleed was ontdekt).

Beide hebben een stevige supportbasis en 2 verschillende doeleinden en beconcurreren elkaar ook niet. Google sponsort zelfs LibreSSL en beide wisselen ideeën en patches en bugs uit. Er is dus geen ruzie of choas zoals jij pretendeert.

[Reactie gewijzigd door dtech op 23 juli 2024 00:10]

[Anoniem: 471038]

Maar die patches waren er binnen enkele dagen. Bij microsoft zou je (gemiddeld) 2 weken wachten tot de volgende patch tuesday.

Dit is een zeer foute weergave van de situatie. Het is afhankelijk van de ernst van de bug. Kritische patches worden zo snel mogelijk gereleased. Niet alles gaat via patch Tuesday.

[NLKornolio]

Das een patch ja geen hotfix. Een hotfix is goed al helpt het 1% van de betrokken systemen.

http://technet.microsoft....x#XSLTsection129121120120
Misschien dat het anders werkt voor linux?

[gekkie]

Dat het niets zegt over de veiligheid en kwaliteit ben ik met je eens.

Overigens zijn die "procedures en controle" er ook bij grotere opensource projecten wel. Echter net als bij closedsource software is er nogal een breedspectrum, de ene ontwikkelaar is de andere niet en er stamt een hoop code uit een ver verleden (waar er anders naar gekeken werd omdat de risico's ook kleiner waren).

Toch gok ik dat bijvb een Adobe ook procedures zal hebben waarbij ook zeker zal zijn hoeveel mensen er naar kijken, toch is er bijna wekelijks een update voor flash en pdf ... terwijl dit closed source is en mensen dus niet heel eenvoudig met (statische) codeanalyse naar de bugs hebben kunnen lopen zoeken.

Code wordt steeds complexer, het aantal en de grote van frameworks extensies en geimporteerde code is dermate toegenomen dat het ondoenlijk is om alle code zelf te screenen al zou je het willen en kunnen.

[Anoniem: 471038]

(overigens kun je met closed source er ook naar kijken, alleen niet in de hogere programmeertaal waarin het geschreven wordt, maar in assembly (waarbijvb software cracks vandaan komen)).

Je kunt ook tot op zekere hoogte decompilen naar een hogere programmeertaal. Met talen als Java, VB of .NET (C# etc) is dat doorgaans vrij goed te doen. Decompilen naar C/C++ is wat lastiger, maar ook daar bestaan wel tools voor.

[BenVenNL]

Bij open source heb ik altijd het gevoel dat er zoveel mensen aan werken dat de kop niet weet wat de staart aan het doen is, en andersom.

[GamesBond]

Jij denkt zeker dat bij Apple of Microsoft de OS'en door een groepje van 4 man worden gecode?

[Alfa1970]

OS'en, of beter gezegd kernels worden inderdaad door een beperkt klein team gemaakt, veel meer dan 5 man zit er niet in het kernel team.

Je vergeet dat er een enorme code basis is bij die bedrijven, er hoeft niet zo heel veel verandert te worden.

Daarom zie je ook dat de kernel zelf steeds sterker wordt en steeds minder makkelijk te hacken, zodat nu de aandacht van malware schrijvers meer en meer is verlegd naar social engineering en applicaties met kwetsbaarheden, zoals ook hier weer het issue is. De shell applicatie is kwetsbaar.

[Mont2uk]

Het gaat er natuurlijk lang niet altijd om dat er een programmeerfout is gemaakt; zoals ook blijkbaar in dit geval is er sprake van een op een verouderde manier van hoe de code is geschreven (wat voor functies zijn gebruikt bijvoorbeeld).
Programmeertalen evolueren ook, om verschillende redenen. Er blijft in verreweg de meeste gevallen backwards compatibility, juist om code op een "oude" manier geschreven nog te laten werken.
Als je hoort dat Chet Ramey de code waarschijnlijk al in 1992 geschreven heeft, waardoor de mogelijkheid is ontstaan voor deze exploit, dan vind ik het helemaal niet gek dat hierdoor deze exploits naar boven komen nu.

Het probleem zit hem in het feit dat je de afweging moet maken in het blijven ondersteunen van code met oude functies, en het risico lopen in het onstaan van exploits als dit. Of het herschrijven van de code (of niet meer ondersteunen van oude functies, waardoor men gedwongen wordt de code te herschrijven), wat als gevolg heeft dat je veel werk hebt om de code te herschrijven.

In dit geval heeft het dus denk ik niet zo veel te maken met dat de samenwerking in opensource projecten niet zo optimaal zou zijn. Ik denk zelfs dat de mogelijkheid in opensource projecten tot het ontstaan van dit soort problemen alleen maar geringer is ten opzichte van programmeer projecten binnen een (commercieel) bedrijf. Vanwege het simpele feit dat mensen vanuit verschillende standpunten de code benaderen, en niet vanuit de filosofie van een bedrijf om het zo maar even simpel te noemen. Om nog maar de zwijgen over de tijdsdruk door geld en het feit dat met in het algemeen denkt dat men ingesloten code minder snel bugs of exploits zal ontdekken (luiheid is een zonde ).

ps. Zie nu pas dat ik op de verkeerde persoon gereplied heb. Excuses!

[Reactie gewijzigd door Mont2uk op 23 juli 2024 00:10]

[Alfa1970]

Het probleem is nu juist wél samenwerking bij precies deze bug.
1 persoon heeft de code geschreven.
Niemand heeft die code gecontroleerd en/of geëvalueerd.
Er is 24 jaar lang maar vanuit één oogpunt naar die code gekeken, en dat is het oogpunt van de auteur.

En die heeft blijkbaar een beetje last gehad van bedrijfsblindheid.
Hij wist wat er hoorde te staan, en las dat, terwijl er eigenlijk dus iets anders stond.

Als iemand, vanuit een ander oogpunt ernaar gekeken had dan was dit veel eerder ontdekt.

[Reactie gewijzigd door Alfa1970 op 23 juli 2024 00:10]

[Mont2uk]

Dat is wat ik ook geformuleerd heb toch: de code is op een manier geschreven, die om het zo maar te zeggen, niet meer van deze tijd is.
Of het probleem dan is dat er niet meer mensen naar gekeken hebben toendertijd is denk ik niet het probleem.
Er lijkt geen fout te zitten in de programmering, meer in de manier. Maar die manier van programmeren was voor die tijd gewoon. Als er toendertijd dus meerdere mensen naar gekenen hebben (wat waarschijnlijk wel het geval moet zijn geweest, aangezien de code geacepteerd en gecontrollerd moet worden voor het toegevoegd wordt aan de kernel code).
Wat ik al aan gaf, is dat het nu wel een probleem is, aangezien programeertalen, en manier van programmeren wel evolueren.

Ik ben het dus wel met je eens, maar ik maak een nuance.
Geschreven code evolueert niet, hoogstens de interpretatie. Maar programmeertalen wel, en de stijl van programmeren. Het toevoegen van meer functionaliteit in een programmeertaal introduceert niet alleen meer mogelijkheden (vergroot het vocubulair), maar introduceert ook praktisch niet te voorkomen problemen, zoals de exploits met het parsen van omgevings variabelen in BASH.

Misschien is het tijd voor een RBASH (ReBourne-Again Shell)

[sentiao]

Dus, het introduceren van nieuwe functionaliteiten in een programmeertaal introduceerd niet-te-voorkomen bugs zoals de bash-bug?

Hoeveel code heb je geschreven? En waar draait jouw code momenteel?

Deze jongeman heeft bash zo gemaakt dat code kan runnen uit een publiek stukje geheugen, dat was in 1992 al not-done. Fout is fout, simpel. En wij hebben het zonder controle over genomen, ook heel fout.

[Nas T]

Fout is fout, simpel. En wij hebben het zonder controle over genomen, ook heel fout.

En met dat stukje wijsheid zal het nooit meer voorkomen
Zonder gein, er is gewoon (onbewust) een fout gemaakt die nu pas ontdekt wordt. Dit is gewoon een teken dat niks heilig is (zelfs niet na ruim 20 jaar). Open source of closed source doet daar niks aan af
Voordeel van open source is dat het niet ontwikkeld wordt door mensen uit winstbejag, maar uit een stuk eigenbelang. Je maakt het als ontwikkelaar voor jezelf en daar kunnen anderen van profiteren.
Wordt het uit winstbejag gemaakt, krijg je een complex geheel aan management die keuzes maakt om meer winst te creëren.
Zo ontstaan farces zoals dat iPhones geen micro-sd slikt.

[Wim-Bart]

Ik snap je punt niet:

Ontwikkelen uit winstbelang = Omwikkelen uit eigenbelang.

Goede code is in eerste geval goed vertrouwen is goede sales is goede toekomst = rijkdom.

Me dunkt dat dat eigenbelang is :-)

[Montaner]

Zonder gein, er is gewoon (onbewust) een fout gemaakt die nu pas ontdekt wordt.

Dat is dus een gevaarlijke aanname. Je weet in dit geval niet of die bug al misschien 10 jaar wordt misbruikt Door een specifiek stukje malware. Het misbruik hoeft niet heel groot te zijn, maar de kans dat een bug zo lang bestaat en niet is misbruikt is erg klein.

[TweakerCarlo]

Als het bijvoorbeeld 20 jaar lang heeft stand gehouden, zie ik alleen een code die het goed heeft gedaan. Het heeft 20 jaar gewerkt voor dat het begrepen werd. Das best een eindje in mijn optiek.

[Mont2uk]

Ja, in principe wel. Dat is tenminste mijn mening.
Maar dat is niet alleen de grondslag van de mogelijk de exploits te gebruiken zoals ze nu aan het daglicht zijn gekomen.

De code is, grotendeels, 20 jaar geleden geschreven. In de tussenliggende periode is er klaarblijkelijk niet veel aan veranderd.

Programmeerafspraken zijn in die 20 jaar wel degelijk veranderd. Dus ik vind het simpel om te zeggen fout is fout. Je moet je wel enigszins verplaatsen in de situatie 20 jaar geleden (zie mijn reply op SuperDre ook).

Natuurlijk is het niet verstandig een waslijst met global variables te gebruiken, en ja, er wordt gebruik gemaakt van oude function headers, waarvoor, inderdaad nieuwe varianten zijn geïntroduceerd in te tussentijd.

Het feit dat er in de tussenliggende tijd waarschijnlijk niet goed naar de code is gekeken, is inderdaad niet goed. Dat ben ik compleet met je eens.
Zoals ik in een andere post al heb gezegd: het zou de kracht van open-source projecten moeten zijn dat, op zijn minst regelmatig, naar de al geschreven code moet worden gekeken, vooral ook door verschillende mensen (vanuit verschillende perspectieven daardoor hopelijk ook).

Op jouw flauwe vraag ga ik inhoudelijk niet in. We zijn hier om elkaar te helpen, niet? Niet om ego's te strelen.
Tenminste, als jouw vraag tot doel had op de persoon te spelen.

[SuperDre]

de code is op een manier geschreven, die om het zo maar te zeggen, niet meer van deze tijd is.

Onzin, de manier waarop code geschreven wordt verschilt helemaal niet zoveel, alleen sommige mensen denken dat het wel zo is omdat de 'methode' een ander naampje heeft gekregen..

[Mont2uk]

Dat is ook precies wat ik zeg; geschreven code veranderd niet, maar de taal zelf wel.
Code geschreven voor (en op) hardware van 20 jaar geleden zal met een andere insteek gschreven zijn. Het gaat natuurlijk niet om "een regeltje code", maar op wat voor manier is bijvoobeeld een heel programma, of OS geschreven, geënt op de hardware van toen?

Natuurlijk kan je afspraken, of "methodes" niet zomaar veranderen, aangezien dat de basis is waarop je kan voortbouwen. Maar er zou wel rekening gehouden moeten worden met veranderende hardware en evolutie in een programmeertaal imho.

En dat is volgens mij wat Robert Graham bedoeld wanneer hij zegt dat de code geschreven is naar de standaarden van 20 jaar geleden (gebruik van oude function headers, hoe de code opgemaakt is).
Je zou van bepaalde aspecten in de BASH code kunnen zeggen dat dat nooit zo op papier had mogen staan, zelfs niet in 1984. Maar we hebben het wel over 1984(!), en inderdaad stonden veel dingen nog in de kinderschoenen als je het vergelijkt met vandaag de dag. Tenminste, hoeveel mensen konden zeggen dat ze heel goed konden programmeren in C? Pas in 1978 is er een min of meer officiële specificatie uitgebracht van de programmeertaal (Kernighan & Ritchie).

[bbob]

De conclusie is we zijn mens maken fouten, evolueren leren van de fouten en maken nieuwe fouten die 10 jaar later weer boven water komen.

[Gomez12]

Voor verouderde programmeerregels die niet meer voldoen aan hedendaagse standaarden heb je allerlei code-quality tests die dit zouden moeten aantonen, daarnaast heb je nog mensen die het periodiek na moeten lopen of het niet opnieuw aangepakt moet worden, maar tja, wil je dat in actie hebben dan heb je wel formele regels nodig en dat mist er hier blijkbaar op vele fronten.

[280562]

Voor verouderde programmeerregels die niet meer voldoen aan hedendaagse standaarden heb je allerlei code-quality tests die dit zouden moeten aantonen ...

En welke programmeerregel is het nu precies, die niet meer voldoet ?

Ik heb het idee dat velen hier lekker aan het ouwehoeren zijn, zonder het probleem precies te kennen. Ik heb net dit gelezen:
https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

Ik heb zo m'n eigen ideeen over dit probleem. Maar als ik het meeste commentaar hier lees, dan lijkt het wel of ik er helemaal niks van snap. Dat kan natuurlijk niet.

Kan iemand me uitleggen welke "hedendaagse programmeerregel" deze bug vandaag de dag zou voorkomen ?

[postbus51]

Mss vanwege de ouderdom was dit een eerder toegevoegde methode om
tijdens lockups van een terminal deze te resetten

[Anoniem: 471038]

Dat bedoelt hij niet. Hij bedoelt dat er in een bedrijf betere organisatie, taakverdeling, planning etc is, zodat iedereen weet waar ze mee bezig zijn.
Het komt er inderdaad op neer dat, ongeacht de grootte van de organisatie als geheel, er per onderdeel kleine groepjes mensen aan werken.

[H!GHGuY]

Open-source heeft zoiets niet nodig. Managers (of team leaders) zijn een non-sense job. Die heb je enkel en alleen nodig omdàt je in een bedrijfsstructuur zit. Het laatste stuk van http://www.catb.org/esr/writings/cathedral-bazaar/ legt dit mooi uit.

[Anoniem: 471038]

Open-source heeft zoiets niet nodig. Managers (of team leaders) zijn een non-sense job. Die heb je enkel en alleen nodig omdàt je in een bedrijfsstructuur zit.

Nee hoor. Je hebt hele grote verschillen in kennisniveau en inzicht bij software-ontwikkelaars.
Er is dus een soort vrij natuurlijke hierarchie dat de betere ontwikkelaars de mindere goden aansturen, en dus het team leiden.
In mijn vrije tijd ben ik demoscener, en de projecten die we daar doen, werken op dezelfde manier, ook al is er absoluut geen sprake van een bedrijfsstructuur.

Het laatste stuk van http://www.catb.org/esr/writings/cathedral-bazaar/ legt dit mooi uit.

Uhhh, wat Eric S. Raymond schrijft is allemaal niet zonder meer waar.
Er zijn genoeg voorbeelden uit de praktijk te noemen die de woorden van ESR tegenspreken. Hij schetst een leuk ideaalbeeld van open source, maar meer dan dat is het ook niet. Je moet dit zeker niet zien als de bijbel voor goede software development.
Sowieso, wat weet ESR van werken in een bedrijf? Hij heeft alleen tussen 1980 en 1985 voor een bedrijf gewerkt. Dat is absoluut niet te vergelijken met hoe software hedendaags ontwikkeld wordt.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Anoniem: 387522]

Dat een bedrijf iets organiseert is helemaal geen garantie voor kwaliteit, hoe kom je daarbij? En open source (dat net zo goed door bedrijven wordt gemaakt en ook gebruikt) geeft iedereen in ieder geval de mogelijkheid voor controle.

[Anoniem: 471038]

Dat een bedrijf iets organiseert is helemaal geen garantie voor kwaliteit, hoe kom je daarbij?

Ik heb nergens het woord 'garantie' genoemd, hoe kom je daarbij?

[Blokker_1999]

Maar zoiets is ook perfect mogelijk bij open source software. Er zijn voldoende projecten te vinden waar een goede structuur en taakverdeling achter zit.

[kritischelezer]

Apple, OS X is ook getroffen door deze bash problematiek...

[pe1dnn]

Ik heb nog een OSX 10.5 op een Power PC iBook en die had die bug ook.

De ontwikkelaar van TenFourFox heeft een nieuwe versie van bash gemaakt en beschikbaar gesteld voor OSX voor zowel Power PC als eerste Intel versies.

Dat kan alleen omdat deze code open source is, want Apple heeft Power PC versies en ook OSX 10.6 allang de rug toegekeerd.

[Enai]

Een kernel is op zich niet zo ingewikkeld. Een OS is véél meer dan een kernel, en daarom komt er zoveel mankracht bij kijken.

Overigens is de kernel van Linux door Linus gemaakt. De daarop volgende wildgroei aan distro's en de gebrekkige interesse van de open source-community voor saaie taken als printerdrivers is dan weer wel een probleem met open source.

[Blokker_1999]

Waarom is het gebrek aan drivers een probleem van open source? Schrijft MS misschien printerdrivers voor de fabrikanten? Neen, het is in feite de fabrikant die een driver hoort te schrijven voor zijn product, alleen vertikken vele fabrikanten dat. Als er drivers zijn in linux is het net omdat mensen vaak, met veel moeite, zijn gaan uitzoeken wat voor commandos een printer nodig heeft om te kunnen werken.

[MadIceXIII]

Het zal je verbazen hoe dat bij MS gaat.

Gezien de complexiteit van de drivers en de hardware en de uiteenlopende specialismes daarin helpt MS de fabrikanten met hun drivers. Die fabrikanten kunnen natuurlijk dat ook volledig zelf doen (en er is niets wat ze in de weg ligt), maar die doen dat veelal om die reden niet.

Who Writes Windows Printer Drivers?

Windows printer drivers are developed through the cooperation between Microsoft and the independent hardware vendor (IHV) that manufactures the print device. Microsoft's role is to assist IHVs with programming and testing of the printer driver's interaction with Windows. The role of the IHV is to assist Microsoft in addressing either the general features or the entire feature set of the print device.

Bron: Windows Printer Driver Support.

[engelbertus]

een gebrek aan drivers onder Linux heeft misschien te maken met een gebrekkig systeem om die drivers vervolgens efficiënt te gebruiken.
de printer kan de hardwarematige fucties gemakklijk onder windows gebruiken omdat daar een mooi framework voor is gemaakt, dat ook goed gedocumenteerd is, zodat fabrikanten weten hoe ze een gecertificeerde driver kunnen indienen bij Microsoft.

Wanneer dat systeem onder Linux fundamenteel anders werkt, is het maken van een bijpassende driver ook een stuk moeilijker dan wanneer je dat voor een windows systeem zou doen.

ik kan me voorstellen dat een driver voor een windows en of apple nog te doen is, maar moeten voldoen aan specificaties voor Linux, verschillende manieren / frameworks om de drivers te kunnen gebruiken en dan nog een handje vol distros en andere OS'en moeten ondersteunen dat doe je uiteindelijk voor een aantal mensen die ook nog vinden dat de driver gratis meegeleverd moet worden, en open source moet zijn.

[Heidistein]

Je schrijft dat het aan zeer bijzondere specificaties moet voldoen voor linux, en tegelijk dat het makkelijk is voor Apple een driver te maken.
De bekende distro's gebruiken CUPS (Common Unix Printing System) om te printen. Dit is een stuk software dat door Apple gemaakt is, werkt 'gewoon' met PPD files, die men ook onder OSX gebruikt.

[engelbertus]

zou dat dan ook reden zijn dat printers soms minder goede of geen officiele apple drivers had? ik neem verder aan dat apple dat systeem verder ontwikkeld, of dat er meer nodig is dan cups alleen om e.e.a. onder apple's netjes te laten werken.
is CUPS onder Linux dan op het zelfde niveau als bij apple?

[Alfa1970]

Eh, ja, Microsoft schrijft drivers en niet alleen voor printers.
Een paar duizend worden er met Windows meegeleverd voor allerhande apparatuur.

[Anoniem: 471038]

Dat er drivers met Windows worden meegeleverd betekent nog niet dat Microsoft die geschreven heeft.
De meeste drivers zijn gewoon door de fabrikant zelf geschreven, en worden met Windows gebundeld. Ook veel drivers die via Windows Update worden aangeboden, zijn gewoon door de fabrikant aangeleverd.

[Anoniem: 471038]

Een kernel is op zich niet zo ingewikkeld.

Precies. Het woord 'kernel' lijkt een magische betekenis te hebben voor veel mensen, en ze denken dat dat het eigenlijke OS is.
Maar kijk eens naar wat 'kernel' letterlijk betekent: De kern.
En dat is het: het is alleen de kernfunctionaliteit voor het OS. En die wil men tot het minimum beperken (zeker bij microkernels), om te zorgen dat alles compact, efficient, betrouwbaar en overzichtelijk is.

[MadEgg]

De daarop volgende wildgroei aan distro's en de gebrekkige interesse van de open source-community voor saaie taken als printerdrivers is dan weer wel een probleem met open source.

Een ruime keuze aan distributies is een goed ding: het maakt je niet afhankelijk van een partij en mocht een bepaalde interface / wijziging je niet aanstaan heb je de mogelijkheid om een ander te gebruiken. Hier heb ik dan ook al regelmatig gebruik van gemaakt.

Drivers is verantwoordelijkheid van de hardware-bouwers, niet van de open source community. Omdat veel hardware-bouwers laks zijn met ondersteuning bieden voor een besturingssysteem met een niet verwaarloosbaar marktaandeel is het fantastisch dat er voor vrijwel elke printer alsnog een printerdriver beschikbaar is. Voor één printer (mijn Canon PiXMA iP4600) was er toen ik hem kocht geen driver voor, maar er was wel een bedrijf (Turboprint) die tegen kleine vergoeding een perfect werkende printerdriver aanbood. Daar heb ik natuurlijk graag gebruik van gemaakt. Alles hoeft niet gratis te zijn.

[Anoniem: 471038]

Dat is de GUI. Niet het OS.

Daar ben ik het als technicus toch niet mee eens.
OS staat voor Operating System. Een systeem om de computer te kunnen besturen ('to operate').
De user-interface hoort hier ook bij, of dat nu een shell is of een GUI.
Ook Wikipedia definieert het op die manier: http://nl.wikipedia.org/wiki/Besturingssysteem

Daarnaast denk ik dat je toch iets te simpel denkt over kernel -> OS -> GUI.
Zoals je zegt: "OS is voornamelijk de kernel"... Nee, het is veel meer dan dat, zelfs als je de GUI niet meerekent.
In je lijstje 'kernel, drivers, hoop tools, daemons, shell, UI' ontbreekt dan ook een hele laag: de laag van APIs/libraries.
Applicaties praten niet direct met de kernel/drivers, maar praten tegen libraries aan voor ANSI C, BSD sockets, OpenGL etc.
Die hele laag hoort ook bij het OS (en is veel groter en complexer dan de kernel zelf, zoals hierboven al opgemerkt), en lijk jij compleet over het hoofd te zien.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[martijnvanegdom]

What Operating Systems Do

We begin our discussion by looking at the operating system’s role in the overall computer system. A computer system can be divided roughly into four components: the hardware, the operating system, the application programs, and the users (Figure 1.1).

The hardware—the central processing unit (CPU), the memory, and the input/output (I/O) devices—provides the basic computing resources for the system. The application programs—such as word processors, spreadsheets, compilers, and Web browsers—define the ways in which these resources are used to solve users’ computing problems. The operating system controls the hardware and coordinates its use among the various application programs for the various users.
We can also view a computer system as consisting of hardware, software, and data. The operating system provides the means for proper use of these resources in the operation of the computer system. An operating system is similar to a government. Like a government, it performs no useful function by itself. It simply provides an environment within which other programs can do useful work.

Uit Operating Systems Concepts, 9th Edition (ongeveer het standaardwerk over OSen).

Ik ben het niet met je eens dat een user interface deel uitmaakt van een operating systeem. Er zijn genoeg systemen (computers) die geen directe user input hebben. De lagen die beschrijft; ja daar kun je over discussiëren.. En daar word het ook moeilijker.. OpenGL tja.. dat zit in de driver dus vind ik het wel een onderdeel van het OS. Maar als het gaat om het scheiden van dergelijke lagen.. is het gewoon wat minder zwart-wit..

[Anoniem: 471038]

Ik ben het niet met je eens dat een user interface deel uitmaakt van een operating systeem. Er zijn genoeg systemen (computers) die geen directe user input hebben.

Nee, maar dan zie je het te letterlijk.
Een OS *moet* geen user-interface hebben... maar *als* er een user-interface is, dan maakt deze deel uit van het OS (dan valt het dus onder 'basic computing resources'... input/output. Het OS biedt dan een manier om applicaties die input/output te laten gebruiken).

Ik heb dat boek overigens ook in de kast staan, de mijne is een vijfde editie Ik doe dit al iets langer dan vandaag

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[martijnvanegdom]

Ik heb de 6de in de kast staan.. maar de 9de was sneller online gevonden

Ik denk dat hier gewoon mening en gedachten verschillen..

[Anoniem: 471038]

Ik denk dat hier gewoon mening en gedachten verschillen..

Tsja, ik weet niet precies hoe jij erover denkt... maar bij een commandline-interface is het het OS dat stdin/stdout/stderr aanbiedt, waarmee je een shell kunt bouwen.
Of je de shell zelf als de interface ziet, of alleen sec de stdin/stdout/stderr, daar valt over te twisten, maar je bent het vast met me eens dat stdin/stdout/stderr deel zijn van het OS, en dat applicaties die gebruiken om hun input/output te doen.

En neem je dat een stap verder, met een GUI... dan is het het OS dat de WIMP-omgeving aanbiedt aan de applicaties. Zeker in het geval van bv Windows/OS X is dat vrij duidelijk.
Bij een *nix valt er enigszins over te twisten, omdat je meer lagen hebt... je hebt X11, en daarboven dan weer een windowmanager. X11 an sich is toch wel een keiharde vereiste voor iedere GUI-applicatie op *nix. Alleen de windowmanager kan nog wel eens verschillen... Maar daar ligt het eraan hoe je het bekijkt. Als je een linux-distro pakt, is er 1 default desktop-omgeving waar de applicaties tegen gecompileerd zijn. Simpel voorbeeld: je hebt Ubuntu en Kubuntu. Een andere desktop-omgeving betekent dus een andere distributie. De applicaties zijn dus aangepast (en niet meer zondermeer uitwisselbaar met de normale Ubuntu). Daar zou je kunnen spreken van twee verschillende OSen.

[martijnvanegdom]

Precies.. en om Kubuntu nu een ander OS te noemen dan Ubuntu... Dat vind ik wel erg ver gaan..

stdin/stdout/stderr vind ik inderdaad deel van het OS.. maar de shell daar bovenop eigenlijk niet.. Ik vind dat een systeemapplicatie.. Of X11 onderdeel van het OS is.. dat vind ik lastig te zeggen (weet niet genoeg hoe X1 werkt..) maar een andere windowmanager.. tja vind ik geen onderdeel van het Os..

[Anoniem: 471038]

Precies.. en om Kubuntu nu een ander OS te noemen dan Ubuntu... Dat vind ik wel erg ver gaan..

Nou ja, zoals ik zeg... de applicaties zijn niet uitwisselbaar.
Het is een beetje een grijs gebied. Net als bv Windows XP tegenover Windows Vista of nieuwer.
Het is allebei Windows, maar toch ook weer niet. Vista heeft bv wel DirectX 10 en 11, XP niet. Dus de applicaties zijn niet zondermeer uitwisselbaar.
In enge zin vind ik het dus wel verschillende OSen. In brede zin zijn de OSen wel naaste familie van elkaar. Dus als je het per familie bekijkt, is het wel 1 OS.

stdin/stdout/stderr vind ik inderdaad deel van het OS.. maar de shell daar bovenop eigenlijk niet..

Nee, maar stdin/stdout/stderr vormen in feite de userinterface van de applicaties (die zorgen voor keyboard-input en tekst-output op het scherm).

[280562]

Goed, helemaal mee eens. Libraries en de APIs die worden geimplementeerd in de libraries maken deel uit van het OS.

Kernel, drivers, libraries, tools, daemons, etc. Ik zal vast nog wel iets vergeten zijn. Het is een glijdende schaal. Maken compilers deel uit van het OS ? De c-compiler wel, want die wordt gebruikt bij/door het OS. Iets als Java hoort er dan weer niet bij, imho.

Applicaties vallen er in ieder geval niet onder. SQL databases ook niet. Webservers ook niet.

En mijns inziens hoort de GUI er ook niet echt bij. Vooral als je keuze hebt tussen verschillende GUIs op een OS. Zoals KDE en Gnome op Linux. Voor de meeste mensen is het WYSIWYU. What You See Is What You Understand. Abstracte ideeen over software-architectuur gaan veel te diep voor de meeste phone/tablet/windows/mac-gebruikers.

[12345dan]

Ikzelf ben een actief commynitylid op Wikipedia, bovendien help ik mee aan de vertalingen middels Launchpad. En dat gaat zeer goed, hoogstens een bewerkingsconflict op Wikipedia aangezien een ander ook aan het bewerken is. En met Launchpad heb ik nog nooit problemen ondervonden.

Uiteraard kan met software enkele verwarring optreden, die wordt echter beperkt met een goede organisatie. En de meeste open-source softwarepakketten hebben ook een goede organisatie.

[Reactie gewijzigd door 12345dan op 23 juli 2024 00:10]

[johnkeates]

Dat valt wel mee hoor, er zijn gewoon procedures en regels, het is niet alsof een bak random mensen zomaar wat code bij elkaar gooit.

[Shark.Bait]

Het is is dus vergelijkbaar met aan een groep vragen of iemand iets wil doen; niemand reageert, men gaat er van uit dat een ander de moeite wel neemt, en dan gebeurt er dus niks.

[Anoniem: 125509]

Ik denk dat dat los staat van de licentie. Er zijn genoeg bedrijfsapplicaties, waaraan ik gewerkt heb, waar dat niet anders was. Het is vaak net een spel Mikado, je probeert een stokje je pakken, maar als je niet uitkijkt gaat de hele stapel aan de rol.

Verder houd ik me graag buiten de open vs. closed fan vecht sessie deze keer.

[himlims_]

geld voor propritaire software het zelfde.
groote verschil zit m in transparantie van structuur. vanwege open karakter worden bugs en security verbeteringen snel(ler) doorgevoerd. is breder toepasbaar en collectieve benadering zorgt voor meer flexibiliteit

[Anoniem: 471038]

vanwege open karakter worden bugs en security verbeteringen snel(ler) doorgevoerd.

Het is maar de vraag of die snelheid wenselijk is. Bash is de afgelopen week al twee keer gepatcht, en nog steeds is het eigenlijke probleem niet opgelost.
Dit nieuwsbericht geeft dus ook aan dat het probleem eigenlijk niet te patchen valt, omdat de code te zeer verouderd is, en compleet opnieuw uitgedacht en herschreven moet worden naar de huidige maatstaven qua security.

De vraag is dus vooral: waarom heft het zolang geduurd totdat iemand besefte dat bash inderdaad zo verouderd is, en zo onveilig? De code is toch immers open, transparent etc?
Mijn ervaring als ontwikkelaar van closed-source software is dat bedrijven zich veel meer bewust zijn van de sterke en zwakke punten van hun codebase. Dat heeft vast ook te maken met het 'koffieautomaat'-principe: Als je samen op kantoor zit, spreek je elkaar ook regelmatig informeel... En dan heb je wel eens gesprekken van: "Nou, ik kwam toevallig dit-en-dat tegen in de code, en daar moeten we nog eens goed naar kijken, want dat is niet helemaal tof." En dan gaat die persoon misschien ook even ernaar kijken, erover nadenken, het met anderen bespreken etc... ondanks dat die persoon misschien helemaal niet bezig is met dat stukje code.
Als je alleen samenwerkt via internet, heb je dus veel minder van dit soort informele feedback.

[Blokker_1999]

Maar is dat dan slechter dan pakweg een kritiek lek bij MS waar je weken op een patch moet wachten terwijl er mogelijk al exploits in het wild te vinden zijn? Het lijkt me net positief dat patches zo snel komen zolang de kwaliteit van de patch bewaakt word (wat met zulke kritieke lekken zeker gebeurd).

Het feit dat bash nu onder vuur ligt komt vooral voort uit een ontwerpbeslissing die men +20 jaar geleden genomen heeft, niet veel anders dan die bug die enkele jaren terug in Windows is gevonden en ook kon getraceerd worden tot het Win 3.x tijdperk.

En je koffieautomaat principe word in FOSS ontwikkeling gedaan mbv mailing lists waarin zulke discussies ook voorkomen. Het word net aangemoedigd om vreemde bevindingen in de groep te gooien. En ipv dat het dan een gesprek is tussen 2 personen krijg je ineens een discussie tussen alle mensen die hun mening willen geven waardoor men sneller en dieper kan graven in de materie. Want als jij aan de koffie automaat iets laat vallen aan de verkeerde persoon dan kan het zijn dat er alsnog niets mee gebeurd.

[Anoniem: 471038]

Het lijkt me net positief dat patches zo snel komen zolang de kwaliteit van de patch bewaakt word (wat met zulke kritieke lekken zeker gebeurd).

Zoals ik zei: er zijn al twee patches in een week geweest, en het probleem is nog niet opgelost.
Kwaliteit van de patch wordt dus NIET bewaakt.

En je koffieautomaat principe word in FOSS ontwikkeling gedaan mbv mailing lists waarin zulke discussies ook voorkomen.

Niet dus. De drempel om een mailtje naar zo'n list te sturen ligt veel hoger.
Verder is het karakter van dergelijke discussies al gauw erg naar, want mensen voelen zich veel eerder aangevallen.

Nogmaals, ik heb ervaring als closed-source developer, ook met internationale bedrijven, waarbij we afdelingen in bv Australie, het VK en de VS voornamelijk via mailinglists en Skype spraken, en dat is toch echt een niveau lager qua betrokkenheid en directheid bij het bespreken van code.

Want als jij aan de koffie automaat iets laat vallen aan de verkeerde persoon dan kan het zijn dat er alsnog niets mee gebeurd.

Dat was helemaal mijn punt niet. Het gaat meer om een algemeen bewustzijn van de code en de mogelijkheden en beperkingen daarin. Klinkt alsof je je niet echt kunt inleven in hoe er in een bedrijf gewerkt wordt.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Mont2uk]

Het gaat er niet om dat men de code niet goed bekijkt, danwel oplossingen niet goed toetst voor het uitrollen van een fix. Het gaat er om in dit geval dat zonder aanpassingen die backwards compatibility schenden, de code niet aangepast kan worden (althans zo lijkt het op dit moment).
Het is de afweging: herschrijving van de BASH code, zodat deze exploits compleet opgelost zijn, en hiermee de backwards compatibility behouden? Of backwards compatibility behouden, maar hierdoor niet compleet de exploits op te lossen.

Het is imho een lastige afweging, aangezien het een vrij essentieel onderdeel is in het laten lopen van programma's, vooral ook zoals al genoemd in apparaten als routers, telefoons, switches, embedded apparatuur, etc etc. Daar komt nog bij dat de mogelijk er überhaupt vaak niet is bij wat oudere apparatuur, in de categorieën hierboven genoemd, dit te updaten.

Het lijkt er wel op dat een nog niet officiële patch uit is gekomen die klaarblijkelijk alle op dit moment bekende eploits verhelpt.
Meer info is hier te vinden:
http://www.openwall.com/lists/oss-security/2014/09/25/32

[Anoniem: 471038]

Het gaat er om in dit geval dat zonder aanpassingen die backwards compatibility schenden, de code niet aangepast kan worden (althans zo lijkt het op dit moment).

Dat stipte ik zelf ook al aan, ik denk dat je dat niet goed hebt begrepen.
Het probleem met UNIX/open source is dat veel dingen enorm verouderd zijn en/of de verkeerde mensen eraan werken (mensen die wel een beetje een idee hebben van hoe UNIX werkt, maar niet van WAAROM UNIX zo werkt), en dus de verkeerde beslissingen genomen worden.
Dit werd jaren geleden al aangekaart door het echtpaar Jolitz, ontwikkelaars van 386BSD: http://www.salon.com/2000/05/17/386bsd/

We realized that a lot of what we had thrown away were first cuts. It’s ironic that people have spent so much time and money on stuff developers just threw in.”

The Jolitzes believed that from its origins as a series of quick, if elegant, hacks, Unix had hardened into a series of unquestioned rituals for getting things done. Many of these rituals were fossils — work-arounds for hardware that no longer existed. “It’s amazing how much we were still tied to the past,” Lynne says. “The physical machines had been hauled away, but elements of the operating systems are still being implemented in the same way.” She believes today’s Linux and BSD developers are carrying on that unhelpful tradition.

“It’s like they’re doing incantations,” she says. “They’re repeating what they’ve been taught, and they don’t know what it means.”

“There are all these artifacts of minicomputers still left in,” Bill agrees.

Bash is een typisch voorbeeld hiervan: het bestaat al zo lang, dat hele generaties ermee zijn opgegroeid, en bash zien als een soort 'holy grail' van hoe een shell geschreven zou moeten worden, ipv dat zij kritisch kunnen nadenken over de code en ontwerpbeslissingen.

Het ontbreken van kritiek en interne controle op kwaliteit, kennis en vaardigheden is de grootste vijand van open source.
Het is vooral 'kras maar raak voor een knaak'.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Mont2uk]

Ik denk dat ik je niet helemaal begrepen heb inderdaad; ik ben het helemaal met je eens.
Maar ik denk wel dat het in dit geval te makkelijk is om te zeggen dat de kwaliteit van de patch niet bewaakt wordt. Er speelt natuurlijk meer dan alleen de code eventjes aanpassen, zodat de bekende exploits niet meer werken.
Dat was eigenlijk de reden dat ik getriggert was te reageren op jouw post.

Maar zoals ik al zei ben ik het met je eens. Het zou juist de kracht moeten zijn van open source projecten, dat constant kritisch wordt gekeken naar code. En dan ook zeker(!) naar al bestaande code!
Het ego moet soms opzij worden gezet.. maar dat blijkt lastig te zijn voor de mens in het algemeen.

[H!GHGuY]

Jij begrijpt blijkbaar nog niet zoveel van development.

Waarom iets wat goed functioneert herschrijven?
Er is zoveel tijd gestopt in bugs squashen, de kans dat je daar een groot deel van opnieuw schrijft is groot. En waarom? Omdat iemand vindt dat het allemaal op niets trekt.
Wanneer jij dus met je rewrite begint, dan heb je geen markt aandeel, geen testing, geen features, een ton duplicate bugs en is de kans reëel dat je alle fouten opnieuw maakt. De economie van rewrites is die van zelfdestructie. Tenzij je een fundamenteel probleem oplost en een kritische massa aan developers hebt, raak je gewoon nergens. Systemd, hoewel controversieel, is daar een voorbeeld van.

Daarnaast _zijn_ er alternatieve shells: dash, csh, zsh, ksh, ...

[MadIceXIII]

Bij langer bestaande code kan er in de loop der tijd code worden bijgeschreven om nieuwe features te implementeren, prestaties te verhogen, bugs te fixen, etc. Na verloop van tijd kan dit nadelige bijwerkingen hebben, zoals bijvoorbeeld een beveiligingsprobleem. Het heeft dan zeker zin om die code opnieuw te schrijven.

Juist omdat dit herschrijven ogenschijnlijk geld kost, wordt dit veelal uitgesteld. De andere kant is dat het opnieuw schrijven van die code ook weer geld kan opleveren, want het kan zo gedaan worden dat nieuwe code overzichtelijker wordt en dus beter te onderhouden is. Soms kunnen ook prestatieverbeteringen en een nieuwe feature set worden meegenomen in een nieuw en eenduidig ontwerp dat backward compatible is. Klanten zullen dat ook weer waarderen.

Zie ook: Code refactoring en Code smell.

[Reactie gewijzigd door MadIceXIII op 23 juli 2024 00:10]

[H!GHGuY]

Begrijp me niet verkeerd. Ik ben helemaal pro refactoring; vraag mijn collega's maar (*evil grin*). Alleen denkt management daar niet altijd zo over. En er zullen ongetwijfeld ook voldoende projecten zijn waar dit uitgesteld wordt.
Niet voor niets zegt men: "all good code is written twice".

[Anoniem: 125509]

"all good code is written twice"

Ik zou willen dat ik dit kon tegenspreken. Zelfs al heb je het trucje bij een andere klant al eens gedaan. Zelfs dan loop je soms nog net weer tegen een specifiek gevalletje bij de nieuwe klant aan, waardoor je oplossing sub-optimaal is.

Ik denk dat refactoring een must is. En wel omdat je op een gegeven moment anders code tegenkomt die 'to big to fail' is maar ook totaal niet meer te onderhouden.

[techno-babble]
Ik zelf kom in de praktijk nog steeds RPG/3 code tegen, waar modernere free programmeurs al echt moeite mee hebben. Zeker een cycle in combinatie met hele ritsen kantlijn indicators zijn een ramp voor de leesbaarheid.

En aangezien de taak van de oudere generatie RPG'ers langzaam maar zeker overgenomen wordt door de nieuwe lichting, die niet meer wil werken in het keurslijf van vaste kolommen, gaat dit echt een probleem worden.

En toch staan deze fossielen regelmatig niet op de rol voor een rondje herbouw, omdat niemand er nog aan durft te komen. Waardoor het probleem alleen maar blijft groeien.
[/techno-babble]

[H!GHGuY]

Je interpretatie van die quote volgt een foute nuance:
Ze zegt niet dat je code de 2de maal zeker correct schrijft, ze zegt enkel dat code zelden in 1 keer goed is.

[Anoniem: 125509]

Ik was misschien niet 100% duidelijk, maar zo heb ik je quote ook opgepakt.

[Anoniem: 471038]

Jij begrijpt blijkbaar nog niet zoveel van development.

Haha, dat zal het zijn
Ik heb meer dan 20 jaar ervaring als technisch software engineer/architect, tot aan het runnen van een eigen software-bedrijf toe.
Sorry, maar je mag soms mensen wel IETS minder onderschatten.

De rest van je verhaal slaat nergens op, met alle respect. Je doet allerlei aannames over 'goed functioneren' en 'herschrijven' om vervolgens met een of andere stroman te komen.

Natuurlijk moet niet alle code altijd herschreven worden, maar dat heb ik ook helemaal niet gezegd.

[H!GHGuY]

Maar wat is je punt dan wel?

Als iets rubbish is, wat doe je dan? Stoppen met gebruiken, herschrijven, of refactoren. Maar geen van de 3 zijn economisch rendabel. Zeker niet voor een component als de shell. In dat opzicht kun je dit verhaal zien als de bankencrisis: bash is too-big-to-fail.

Bash is een typisch voorbeeld hiervan: het bestaat al zo lang, dat hele generaties ermee zijn opgegroeid, en bash zien als een soort 'holy grail' van hoe een shell geschreven zou moeten worden, ipv dat zij kritisch kunnen nadenken over de code en ontwerpbeslissingen.

En dit slaat ook helemaal nergens op. Hoeveel maintainers heeft bash? 1 (+3 project members). Hoe kun je dan spreken over generaties, holy grail, kristisch nadenken en ontwerpbeslissingen? En wat met POSIX-specificaties waar de shell ook gewoon aan moet voldoen (hoewel POSIX ook geen onbesproken item is)? Hoeveel manieren zijn er om een shell te schrijven? Je bekijkt de zaak volgens mij veel te simpel en van veel te grote hoogte.

Ik vraag me af of je ook niet met een bedrijfsleven-bril op open-source kijkt. Dat werkt niet, vanuit alle perspectieven. Zowel op vlak van processen als op vlak van licenties, etc.
Lees een dezer maar eens dit stuk http://www.catb.org/esr/writings/cathedral-bazaar/

[Anoniem: 471038]

Maar geen van de 3 zijn economisch rendabel.

Bugs zijn nooit economisch rendabel. Y2K was ook geen feestje, maarja, je moest toch actie ondernemen. Ik snap dus niet echt waar je heen wil.

bash is too-big-to-fail.

Ik denk dat een andere spreuk meer van toepassing is: shit happens.

En dit slaat ook helemaal nergens op. Hoeveel maintainers heeft bash? 1 (+3 project members). Hoe kun je dan spreken over generaties, holy grail, kristisch nadenken en ontwerpbeslissingen? En wat met POSIX-specificaties waar de shell ook gewoon aan moet voldoen (hoewel POSIX ook geen onbesproken item is)? Hoeveel manieren zijn er om een shell te schrijven? Je bekijkt de zaak volgens mij veel te simpel en van veel te grote hoogte.

Nee, jij leest gewoon niet goed.
Ik zeg dit: "het bestaat al zo lang, dat hele generaties ermee zijn opgegroeid"
Dan kom jij met verhalen over het aantal maintainers. Hoe kom je daarbij? Het gaat mij erom dat bash al sinds 1989 bestaat. Daarom zijn dus hele generaties UNIX-gebruikers ermee opgegroeid. Zij 'weten niet beter'.
Zelfde verhaal gaat op voor POSIX: dat bestaat ook al heel lang, en daarom weten een hoop mensen niet beter dan dat POSIX is wat het is, en kijken ze er ook niet kritisch naar.
Sowieso zijn de meeste UNIX-mensen totaal blind voor alternatieven, hebben bv geen flauw benul van hoe Windows in elkaar steekt. Als je maar 1 dingetje kent, helpt dat ook niet bepaald om kritisch ergens over na te denken. Je referentiekader is dan veel te klein.

Ik zeg altijd maar: Je verdiepen in 3 of meer vergelijkbare technieken is ideaal. Als je er maar 1 kent, weet je niet beter, en kun je ook niet echt oordelen. Als je er twee kent, wordt het gauw een zwart-wit verhaal: bij X is alles goed, en bij Y is alles slecht. Zodra je er 3 of meer hebt, begin je grijstinten te zien, en kun je veel genuanceerder en objectiever gaan nadenken over dingen.

Lees een dezer maar eens dit stuk http://www.catb.org/esr/writings/cathedral-bazaar/

Wederom... denk je echt dat ik dat nog nooit gelezen heb? Onderschatting is een kunst.

[H!GHGuY]

Vreemd. Je claimt 20 jaar ervaring en dat je cathedral/bazaar hebt gelezen, maar negeert dat schijnbaar allemaal.

Ik zeg dit: "het bestaat al zo lang, dat hele generaties ermee zijn opgegroeid"

If it ain't broken, don't fix it.
Waarom zou iedereen plots in de shell-code moeten duiken?
Als het ding doet wat het moet, dan gebruikt iedereen het ding zoals het is.

Het gaat mij erom dat bash al sinds 1989 bestaat. Daarom zijn dus hele generaties UNIX-gebruikers ermee opgegroeid. Zij 'weten niet beter'.

Die UNIX gebruikers weten wel beter. Er zijn andere (en recentere) shells. Je doet net alsof de kennis van vandaag gisteren ook al voorhanden was: "we wisten allemaal dat de bash code slecht was. Al sinds 1989 en we hebben er nooit iets aan gedaan. We wisten allemaal dat dit soort problemen gingen volgen. We moesten het echt herschrijven maar hebben het niet gedaan".

Zelfde verhaal gaat op voor POSIX: dat bestaat ook al heel lang, en daarom weten een hoop mensen niet beter dan dat POSIX is wat het is, en kijken ze er ook niet kritisch naar.

Er wordt trouwens _WEL_ kritisch naar POSIX gekeken. De Linux kernel bijvoorbeeld volgt POSIX, tenzij hetgeen erin staat non-sense is en een afwijking beter gedrag vertoont.
Daarom ook dat ik zei dat POSIX veelbesproken is en niet zomaar gevolgd wordt. Waarom denk je dat veel shells een POSIX compatibility mode hebben? Toch niet omdat ze niet beter weten?

Sowieso zijn de meeste UNIX-mensen totaal blind voor alternatieven, hebben bv geen flauw benul van hoe Windows in elkaar steekt. Als je maar 1 dingetje kent, helpt dat ook niet bepaald om kritisch ergens over na te denken. Je referentiekader is dan veel te klein.

Met je eigen commentaar: quod erat demonstrandum. Je blijkt een Windows aanhanger te zijn (althans uit je comment-history komt dit enigzins naar voor) en pleit het "met een bedrijfscultuur was dit nooit gebeurt"-mantra. Ik denk dat veel UNIX developers heel goed weten hoe windows in elkaar zit (althans van wat er publiekelijk beschikbaar is). Je onderschat een community die je zelf blijkbaar niet kent.

Jammer dat je een volledige comment-topic zomaar hijacked met je irrationele meningen en het hoog van de toren blazen.
Je toont geen enkel inzicht in hoe open-source werkt, hoe de structuren in elkaar zitten, etc. Spijtig dat je het dan nodig vindt om zoveel non-sense te spuien.

[Anoniem: 471038]

Vreemd. Je claimt 20 jaar ervaring en dat je cathedral/bazaar hebt gelezen, maar negeert dat schijnbaar allemaal.

Dat ik het heb gelezen, betekent nog niet dat ik het ermee eens ben.

If it ain't broken, don't fix it.
Waarom zou iedereen plots in de shell-code moeten duiken?

Het artikel is al een antwoord op je vraag.
Een mooie spreuk vind ik altijd: Working code is not bugfree code.
Er mag best af en toe kritisch naar bepaalde code gekeken worden.
Sowieso bij belangrijke dingen als de shell van een OS, daar mag wel regelmatig een security-audit gedaan worden.

Je doet net alsof de kennis van vandaag gisteren ook al voorhanden was

Nee, ik zeg dat men deze fouten best eerder had kunnen vinden, als men meer georganiseerd en kritisch naar de code had gekeken.

Je blijkt een Windows aanhanger te zijn (althans uit je comment-history komt dit enigzins naar voor)

Nee, ik ben een Amiga-aanhanger. Verder gebruik ik zowel Windows als FreeBSD dagelijks. Heb niet direct een voorkeur. Het zijn verschillende systemen, die elkaar kunnen aanvullen als je ze op de juiste manier gebruikt.
Ik heb waarschijnlijk meer OSen gebruikt dan waar jij ooit van gehoord hebt.
In de demoscene sta ik er inmiddels ook wel een beetje om bekend dat ik op van alles en nog wat programmeer. C64, Amiga, MS-DOS, Windows, OS X, Java, Android, FreeBSD, Linux, GP2X... Je kunt van mij prods vinden op allerlei platforms.
Wederom, onderschat mij niet.

[Anoniem: 125509]

If it ain't broken, don't fix it.

Ik ben toch vaker een voorstander van het "If it ain't broken, use a bigger hammer." idee. Te vaak kom ik code tegen die zeker niet 'broken' is, maar waarvan de kwaliteit om te huilen is.

Redundante code, code die fouten van code ervoor oplost, code die niet meer gebruikt wordt, variabelen en velden die oneigenlijk gebruikt worden en zelfs code die verschillend functioneert, afhankelijk van in welke fase van de OTAP het zit, waardoor testen zo goed als onmogelijk is.

Code die 'ain't broken' is, is toch regelmatig ernstig toe aan een fix.

Dat het vaak niet gedaan wordt, is helaas wel weer een feit. Je moet keuzes maken als je miljarden regels code te onderhouden hebt. Daardoor wordt het door jouw aangehaalde adagium wel heel aantrekkelijk.

Voor de rest heb ik geen opmerkingen bij je comment.

[Anoniem: 125509]

Bugs zijn nooit economisch rendabel.

Ik verdien er toch al meer dan 20 jaar een boterham mee. Hoezo niet economisch rendabel?

Microsoft bijvoorbeeld bracht elke nieuwe versie steeds weer uit als hun meest veilige versie ooit, waarmee ze een vervangingsmarkt op gang proberen te houden op basis van die 'niet economisch rendabele' bugs.

Mits goed ingezet, zijn bugs een prima economisch smeermiddel.

Sowieso zijn de meeste UNIX-mensen...

Generaliserend kan je stellen dat generalisaties zelden kloppen.

Ik denk dat je stelling geldt voor elk platform. Windows/AS400/OSX-mensen zijn even blind als UNIX/Linux/BSD-mensen. En ik denk dat die blindheid vooral geldt voor de vocale groepen die je vooral op allerlei fora tegen komt, niet voor de zwijgende meerderheid.

[Anoniem: 471038]

Ik verdien er toch al meer dan 20 jaar een boterham mee. Hoezo niet economisch rendabel?

Ja, als je aan de andere kant staat wel, natuurlijk

Ik denk dat je stelling geldt voor elk platform. Windows/AS400/OSX-mensen zijn even blind als UNIX/Linux/BSD-mensen. En ik denk dat die blindheid vooral geldt voor de vocale groepen die je vooral op allerlei fora tegen komt, niet voor de zwijgende meerderheid.

Ik denk dat je dan het punt mist.
Natuurlijk is iedereen die zich profileert als een 'X-mens' waarbij X een willekeurig OS is, blind voor andere dingen.
Maar daarnaast zijn er ook mensen die WEL verstand van meerdere OSen/systemen/etc hebben.
Ik heb alleen eigenlijk nooit iemand meegemaakt die zich als 'Windows-mens' profileerde. Dat is blijkbaar niet interessant om te doen. UNIX daarentegen is de underdog, en hele volksstammen identificeren zich daarmee en zetten zich af tegen alles dat anders is.
Dat gaat heel ver overigens. In mijn tijd op de TU Delft merkte ik ook dat sommige professors gewoon niet met hun tijd waren meegegaan. UNIX was het enige dat ze kenden, en dus gaven ze practica onder linux. Practica die net zo goed onder Windows gedaan hadden kunnen worden, zoals de meeste practica. Beetje jammer dus, dat ze niet met hun tijd meegaan, en zich niet kunnen aanpassen.

Voor ons als studenten was dat erg lastig. Ten eerste waren de linux-installaties niet denderend stabiel op de TU Delft. Zo werd er voor de home-dirs een NFS gebruikt die er vaak uit lag. Kon je dus niet verder (linux handelde dat totaal niet graceful af... als je een commando invoerde, stond ie gewoon eindeloos te wachten totdat de NFS ooit eens antwoord zou geven).
Daarnaast moesten we onze verslagen dus ook onder linux schrijven... En dat betekende dus Open Office. In die tijd werkte dat bepaald nog niet denderend.

[Anoniem: 125509]

Ik heb alleen eigenlijk nooit iemand meegemaakt die zich als 'Windows-mens' profileerde.

Je leeft kennelijk in een heel andere wereld dan ik dan. Ik zie zelfs dat Microsoft zo ongeveer geldt als automatisme. Alternatieven wordt niet eens bij stil gestaan, of worden zonder heldere argumenten weg gewuifd.

Je herkent ze waarschijnlijk niet omdat Microsoft oplossingen nu eenmaal logisch lijken. Zo ervaar ik het tenminste vaak. Als ik dan de vraag stel of alternatief X overwogen is, wordt je aangekeken alsof je een vraag stelt over brandend water.

En praktica zouden gegeven moeten worden op het platform van je eigen keuze. Jammer dat dat niet mogelijk was. Ik kwam in die tijd ook Windows en OS2 systemen tegen die niet denderend stabiel waren. Het was nu eenmaal een niet zo stabiele tijd. Ik stel me alleen wel de vraag wat een proffessor en techniek van 20 jaar geleden met de discussie te maken heeft. Waarom bewijst dat dat de ene groep blinder is dan de andere tegenwoordig?

[Anoniem: 471038]

Je leeft kennelijk in een heel andere wereld dan ik dan.

Zoals ik zei: ik ben technisch informaticus. Dat is vast een iets andere tak van sport dan algemene kantoorautomatisering etc.
Wij technici zijn nogal wetenschappelijk en sceptisch ingesteld. Wij weten dan ook waar we over praten.

Ik kwam in die tijd ook Windows en OS2 systemen tegen die niet denderend stabiel waren.

Bij de TU Delft was het Windows NT4-netwerk prima in orde.

Ik stel me alleen wel de vraag wat een proffessor en techniek van 20 jaar geleden met de discussie te maken heeft. Waarom bewijst dat dat de ene groep blinder is dan de andere tegenwoordig?

Mijn ervaring is dat het een soort 'halo'-effect is... Die professors gingen niet met hun tijd mee, dus bleven ze bij UNIX/linux. Vervolgens dachten studenten van: "Hee, zij gebruiken linux, dat zan dan wel de beste keuze zijn", en gingen dat ook gebruiken, zonder er kritisch naar te kijken.
De argumenten komen ook vaak niet verder dan: "Windows is slecht omdat het geen linux is". Erg vermoeiend.

[onetime]

Linux is veel stabieler dan Windows. Veranderd ook veel minder.
Je stelt het dan ook verkeerd om;
Wat op Linux kan moet je dan ook op Linux doen.
Nog goedkoper ook; wel eens aan gedacht?
(en ook, als het een technische opleiding was hoor je meer te kennen dan alleen windows)

[Anoniem: 471038]

Wat op Linux kan moet je dan ook op Linux doen.

Dat argument kun je voor ieder OS opvoeren. Veel dingen kunnen op de meeste OSen.

Nog goedkoper ook; wel eens aan gedacht?

Nee, want Windows moest er sowieso zijn. Extra OSen kosten alleen maar meer geld.
In dit geval was blijkbaar niet echt de kennis in huis om de practicumzalen van betrouwbare dual-boot systemen te voorzien met een goede linux-infrastructuur. De systemen werkten onder Windows wel goed, maar onder linux was de NFS niet betrouwbaar.
Hoop extra moeite dus om die linux-installatie ernaast te zetten, en een hoop extra gedoe voor de studenten omdat het niet goed werkte. Had het practicum dan gewoon onder Windows gedaan.

(en ook, als het een technische opleiding was hoor je meer te kennen dan alleen windows)

Dat is een ander verhaal. Natuurlijk werd er ook UNIX onderwezen. Sowieso kreeg iedere student een shell-account op een HP-UX systeem. Het waren alleen de systemen in bepaalde practicumzalen die niet goed werkten.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Anoniem: 471038]

Visual Basic zeker.

Voornamelijk C/C++ en assembly, maar leuk dat je het vraagt.
Google misschien even op 'Scali Bohemiq', kun je wat van m'n demootjes zien door de jaren, veelal met strakke asm-code.
Zoals bv m'n jongste creatie, een flatshaded subpixel-corrected software renderer voor 286 (yup, 16-bit, en zonder FPU uiteraard, we zijn toch geen mietjes?) en EGA/VGA: http://www.pouet.net/prod.php?which=62165
Ben benieuwd naar jouw asm-code.

Ik vind het stukje dat je quote een beetje nietszeggend. Gewoon Unix-bashen.

Het zijn Bill en Lynne Jolitz, zeer bekend in de UNIX-wereld, en ontwikkelaars van 386BSD (waaruit dus de huidige Free/Net/OpenBSD zijn voortgevloeid, en ook varianten daar weer op, zoals OS X).
Om dat als 'nietszeggende UNIX-bashing' weg te zetten is wel heel erg triest. Geeft ook wel aan hoe weinig jij weet van de geschiedenis van UNIX.

Waarom zijn MS of Apple programmeurs wel beter ?

Heb ik dat beweerd dan? Het gaat hier alleen om wat er fout is gegaan met ruim 20 jaar bash.
Gaat ook niet zozeer om hoe goed of slecht een programmeur is. Een goede programmeur kan in een slechte organisatie ook niet goed functioneren, terwijl een slechte programmeur in een goede organisatie met de juiste ondersteuning juist heel goed kan functioneren.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Anoniem: 471038]

Assembly code. Ik ben zeer onder de indruk. Niet dus. Assembly is voor compiler-designers. Ieder ander die iets met assembly doet zou moeten worden opgesloten. "Strakke asm-code" is een contradictio-in-terminis.

Haha!
Echt?
Gast, die 1991 donut moet draaien op een 286 van 16 MHz (thema van de 1991 party was dus hardware die in 1991 beschikbaar was. In dit geval een 286, 16 MHz, 640K geheugen, EGA/VGA en optioneel een AdLib kaart).
Heb je enig idee hoe strak die code moet zijn om dat voor elkaar te krijgen? En hoe pietluttig zo'n CPU uit 1982 is? Om van de videokaart maar te zwijgen. En zoals ik al zei, je hebt ook geen FPU, dus je kunt geen floats gebruiken voor je 3d-berekeningen.
Dat krijg je met een compiler echt NOOIT voor elkaar. Met behulp van de juiste assembly-code op de juiste plek heb ik de code echt twee keer zo snel gekregen, als het niet meer is.

Ik ben benieuwd hoe weinig je ervan snapt. Hoe denk je dat ik de muziek afspeel in de achtergrond, wetende dat het MS-DOS is, een single-core CPU, en dus geen threads?
Of het feit dat de scroller asynchroon loopt (altijd 60 fps) van de donut (nieuwe frame zodra ie berekend is, zo snel als de CPU toelaat)?

Het gaat hier om een bug waar het laden van een functie in bash gebeurd door de hele environmental variable in te laden *en* uit te voeren. Andere shells (csh, tcsh, sh, etc) doen dat niet. Dit probleem gaat over bash. En heeft niks te maken of Unix "a quick series of hacks" is.

Of juist wel? Heeft de ontwikkelaar dat laden van functies ooit als 'quick hack' erin gebouwd omdat hij dat op dat moment wel handig vond? Zoals je zegt, andere shells doen dat niet, dus waarom zit het hier uberhaupt in? Gebruiken mensen het uberhaupt?

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Anoniem: 125509]

Ieder ander die iets met assembly doet zou moeten worden opgesloten.

Ik gok dat je van de post Ms-Dos generatie bent? In 91 was assembler, zeker voor zwaar grafisch werk, nog steeds redelijk onmisbaar. C / C++ kwam redelijk in de buurt, maar voor absolute controle en maximale snelheid was het een must.

Ik vind eigenlijk dat ASM hoort bij een stukje basis kennis van programmeren. Diep onder de motorkap is dat wat elke programmeertaal in de meest basale vorm oplevert. Zelfs Windows met als zijn multi-tasking en events valt gewoon uiteen in MOV's, PUSH'es, POP's en JUMP's. (En nee, ik ken de instructieset niet meer uit mijn hoofd. Het is 20 jaar geleden.)

heeft niks te maken of Unix "a quick series of hacks" is.

Wat wel weer waar is. De filosofie is dat het kleine brokjes zijn, die een taak hebben, die ze zo goed mogelijk doen. Het KISS principe (Keep it simple, stupid).

Maar zeker als je naar de commands van sommige command-line fetisjisten kijkt zou je wel gemakkelijk het idee kunnen krijgen dat het een samengeraapt zooitje is en dat het hacks zijn.

Maar een programmeur die zijn basis heeft in het Dos tijdperk zou moeten weten dat kleine doelgerichte modules en bibliotheken zeker geen "a quick series of hacks" is.

[Anoniem: 471038]

C / C++ kwam redelijk in de buurt

Niet bepaald. Je moet rekenen dat de CPUs in die tijd ook heel anders waren.
Compilers genereren code op een vrij rechttoe-rechtaan manier, en maken alleen gebruik van generieke instructies (vandaar dat RISC zo goed werkt met compilers... instructies waar een compiler niets mee kan, zitten er niet in).
Met deze vroege CPUs kon je veel tijd winnen door speciale instructies te gebruiken, zoals de string-instructies (lods/stos/movs/scas), en andere 'macro'-instructies.
Vooral bij een 8088 is de lengte van de code heel belangrijk. Iedere byte die je leest kost 4 cycles. Dus als je een instructie van 2 bytes kunt vervangen door eentje van 1 byte, heb je alweer 4 cycles winst.

Ook mul/div waren destijds heel duur. x86 heeft vormen van mul/div die bv 16-bit*16-bit doen, en een 32-bit resultaat opleveren. Of een 32-bit getal delen door een 16-bit getal, en dan een 16-bit resultaat.
Dit kun je in C/C++ niet opschrijven, en dus kan de compiler hier moeilijk speciale code voor genereren. Vaak doet hij dan een complete 32-bit*32-bit mul, of een complete 32-bit div, die veel duurder is (want op een 286 en lager kun je dat dus niet in 1 keer doen, dat moet dan met kruislings vermenigvuldigen danwel met een staartdeling).
C64 is trouwens nog leuker. De 6510-CPU die daarin zit, heeft niet eens mul/div in hardware. Moet je als programmeur dus zelf implementeren. Complexe 3d-berekeningen zijn dus nog wel een paar gradaties lastiger op deze systemen dan op een moderner systeem met een FPU.

Daarnaast speelt het segmented memory model ook nog een grote rol bij 16-bit code. Je werkt met blokken van maximaal 64K. Compilers waren ook niet altijd even handig in het gebruik hiervan, waardoor ze onnodig vaak van segment wisselden, wat dus weer extra cycles kostte.

Tegenwoordig zijn CPUs heel anders. Vanwege alle bandbreedte en caching hoef je niet meer zo te letten op de grootte van je instructies. Daarnaast hebben ook x86 CPUs tegenwoordig een RISC-backend, en zijn de macro-instructies geimplementeerd met een stukje microcode, waardoor ze sowieso langzamer zijn. 'Domme' compilercode is nu dus gewoon sneller.
Zo heb ik laast voor de grap een renderer uit m'n 486-tijd uit het stof getrokken, om hem naar ARM te porten. Daarvoor heb ik gewoon de inline-assembly vervangen door C-code. De grap was dat deze C-code ook op een modern x86 een stuk sneller draaide dan mijn assembly-code.
Dat kwam voornamelijk omdat mijn code destijds geoptimaliseerd was met het gebruik van partial registers. Op een 486 of Pentium werkte dat prima. Sinds de Pentium Pro hebben we echter out-of-order execution en register renaming. Hierdoor kunnen deze CPUs minder efficient met partial registers omgaan, waardoor er allerlei stalls in mijn code komen.

Maar een programmeur die zijn basis heeft in het Dos tijdperk zou moeten weten dat kleine doelgerichte modules en bibliotheken zeker geen "a quick series of hacks" is.

Ik stel voor dat je het hele artikel leest, want het lijkt erop dat je de opmerking niet in de juiste context kunt plaatsen.
Het gaat namelijk helemaal niet om de oppervlakkige notie dat UNIX allerlei tooltjes heeft die 1 ding goed kunnen, welke je weer aan elkaar plakt tot een groter geheel.
Wat zij bedoelen is dat er bv bepaalde dingen ooit ontworpen zijn voor een bepaald type mainframe of iets, maar dat op moderne hardware helemaal niet zo goed werkt (beetje vergelijkbaar met mijn voorbeeld hierboven, van hand-geoptimaliseerde code die op een 486 of Pentium wel sneller is, maar op nieuwere CPUs niet meer).

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[280562]

Ik ben zeker niet van de post-Dos generatie. Echter, ik heb me nooit me Dos bezig gehouden. Unix vanaf het eerste uur.

Het is mijn overtuiging dat de allerbelangrijkste factor bij programmeren is: readability.

Kun je zelf na een jaar je eigen code nog begrijpen ? Kan een ander dat ? Is het gedocumenteerd ? Zijn er zinvolle comments ? Hebben functies en variabelen verklarende namen ? Worden er geen obscure taal-constructies gebruikt ? Bij een hoop programmeurs is dat niet het geval. Onleesbare code. Dat betekent onmaintainbare code. Waardeloos.

Zo waardeloos, dat ik vind dat readability misschien nog wel belangrijker is dan scalability. En readability is zeker belangrijker dan correctness. Bugs kun je fixen. Onleesbare code kun je alleen maar wegflikkeren, je kunt het niet eens stuk-je-voor-stukje herschrijven. Performance doet me niks. Performance haal je door slimme algorithmen te gebruiken. Waar je misschien O(n^2) kunt vervangen door O(n log n). Performance haal je niet door asm te gebruiken. Een performance factor 2 is verwaarloosbaar in mijn ogen.

Het gebruik van asm maakt code totaal onleesbaar. Maar dan ook totaal. Vandaar dat ik er nul respect voor heb als mensen asm gebruiken. Sterker nog, ik ben er heel negatief over. Hobbyen is het, meer niet.

[Anoniem: 125509]

In assembler kan je prima leesbare code schrijven. Onleesbare code is *altijd* een keuze van de ontwikkelaar. Verder ga ik geen woorden meer aan je flauwekul spenderen.

[Anoniem: 471038]

Ik ben zeker niet van de post-Dos generatie. Echter, ik heb me nooit me Dos bezig gehouden. Unix vanaf het eerste uur.

Je spreekt jezelf hier min of meer tegen.
Het is pas sinds begin jaren 90 mogelijk om linux of 386BSD op een eigen PC te draaien. Tegen de tijd dat mensen dit daadwerkelijk ook gingen doen, was MS-DOS al vervangen door Windows 9x.
Zelfs mensen die voor hun werk op UNIX-machines werkten, hadden thuis dus een DOS-PCtje.
Maar ik schat jou in als iemand die pas na 1995 z'n eerste computer had, dus van na het MS-DOS tijdperk.

Performance doet me niks. Performance haal je door slimme algorithmen te gebruiken. Waar je misschien O(n^2) kunt vervangen door O(n log n).

Dat is stap 1 ja.

Performance haal je niet door asm te gebruiken. Een performance factor 2 is verwaarloosbaar in mijn ogen.

Klinkt duidelijk als iemand die de jaren 80/90 niet bewust heeft meegemaakt.

Het gebruik van asm maakt code totaal onleesbaar.

Dit zegt vooral iets over jou, en jouw gebrek aan kennis en ervaring, niet over assembly. Ik sluit me bij pkoopmanpk aan dat onleesbare code *altijd* een keuze is van de ontwikkelaar.

[280562]

Het is pas sinds begin jaren 90 mogelijk om linux of 386BSD op een eigen PC te draaien. Tegen de tijd dat mensen dit daadwerkelijk ook gingen doen, was MS-DOS al vervangen door Windows 9x.
Zelfs mensen die voor hun werk op UNIX-machines werkten, hadden thuis dus een DOS-PCtje.

Mooi hoe je allerlei conclusies trekt. Allemaal fout. Ik ga hier niet m'n CV posten om je ongelijk te bewijzen. Maar ongelijk heb je.

[Anoniem: 471038]

Mooi hoe je allerlei conclusies trekt. Allemaal fout. Ik ga hier niet m'n CV posten om je ongelijk te bewijzen. Maar ongelijk heb je.

Tsja, ik was erbij in die tijd (mijn eerste computer was in 1981), en mensen zoals ik weten dat ik gelijk heb. De systeemeisen van UNIX-achtigen waren extreem hoog in die tijd, en ook de licenties waren niet mis (zoals ik zeg, gratis/opensource versies zoals linux en 386BSD begonnen pas rond 1992).
Of wil je gaan beweren dat jij in de jaren 80 al een 386 kon betalen met een Xenix-licentie voor thuisgebruik?
Een MS-DOS PC was toen al duur genoeg. Vandaar ook de populariteit van home computers. Maarja, daar kon je al HELEMAAL geen UNIX op draaien.

Je kletst uit je nek, dat weet je zelf ook best. Zie ook elders, waar je even APIs/libraries 'vergeet' bij het beschrijven van een OS.
Als je echt al sinds de jaren 80/90 met UNIX werkt, zou je dat soort triviale fouten niet maken. Dan zou je ook weten wie Bill en Lynne Jolitz zijn. En dan zou je ook weten dat een factor 2 verschil in performance ENORM belangrijk is.
In mijn geval werkt de code nu acceptabel op een 286-16. Als de code 2 keer zo langzaam was, zou je een 286-32 moeten hebben, en die bestond gewoon niet. Ze gingen niet verder dan 25 MHz. Afgezien van het feit dat die computers 3 tot 4 keer zo duur waren (prijzen nemen exponentieel toe met de snelheid).
Performance was ALLES in die tijd. Veel software voor home computers werd om die reden ook compleet in asm geschreven, zeker in de jaren 80.

Ik ben dus wel benieuwd naar je CV.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[280562]

[CV deleted]

Soms is assemly nodig. Soms. In alle andere gevallen moet het vermeden worden als de pest.

Goed genoeg ?
Morgen edit ik dit er weer uit.

[Reactie gewijzigd door 280562 op 23 juli 2024 00:10]

[Anoniem: 471038]

Goed genoeg ?
Morgen edit ik dit er weer uit.

Niet echt. Ten eerste kom je niet over als een UNIX-kenner, vanwege punten die ik eerder al genoemd heb.
Ten tweede, zelfs als dit verhaal waar is... wil je dan beweren dat je thuis nooit een computer had staan?
Want als je eind jaren 80/begin jaren 90 een computer thuis had (wat vrij aannemelijk is, zeker als je zelf in die branche werkt), was de kans groot dat dat een MS-DOS PC was. En dan heb je dus gelogen dat je je nooit met DOS bezig gehouden hebt.

[280562]

Ik kocht mijn eerste PC thuis om spelletjes te spelen. Dat was 1999. De jaren daarvoor had ik een Sparcstation thuis (met Internet via ISDN). Ik was een professional, niet een amateur.

[Anoniem: 471038]

Ik kocht mijn eerste PC thuis om spelletjes te spelen. Dat was 1999. De jaren daarvoor had ik een Sparcstation thuis (met Internet via ISDN). Ik was een professional, niet een amateur.

Dan val je dus ook wel in de categorie die ik eerder beschreef, zoals sommige professors aan de TU Delft: hoewel de hele wereld op MS-DOS/Windows werkte, bleven zij bij UNIX hangen, en hadden zelfs nooit de moeite gedaan om kennis te nemen van deze populaire systemen. Dat vind ik vrij opmerkelijk, zeker voor iemand in zo'n positie.

Daarnaast, Sparcstations bestaan pas sinds 1989... wat had je daarvoor dan?

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[onetime]

De hele wereld op dos/windows werkte...

nee dus, professionals gebruikten mini en mainframes, wel eens van gehoord? Dos en zeker windows zijn vanuit de consumenten hoek gekomen.

[Anoniem: 471038]

nee dus, professionals gebruikten mini en mainframes, wel eens van gehoord? Dos en zeker windows zijn vanuit de consumenten hoek gekomen.

Was jij erbij? Klinkt van niet.
Misschien moet je je eens verdiepen in de geschiedenis van DOS/Windows.
DOS is geintroduceerd als OS voor de IBM PC. IBM staat voor International Business Machines, en de IBM PC was dan ook ontwikkeld als kantoormachine (was ook veel te duur voor de consument. Home computers als de VIC-20, C64 en dergelijke waren in die tijd op de consument gericht).

In eerste instantie was DOS voornamelijk populair voor tekstverwerkers (WordStar, WordPerfect), spreadsheets (VisiCalc, Lotus 123), simpele databases (dBase) en dergelijke.
Puur zakelijk dus. En veel wijder verspreid dan mini/mainframes uiteraard, omdat het een Personal Computer was: op ieder bureau stond er eentje.

Echt, verdiep je eens een keer in de geschiedenis voordat je wat roept. Want roepen dat de IBM PC/MS-DOS uit de consumentenhoek zijn gekomen is echt belachelijk.
Sterker nog, IBM heeft de PCjr ooit geprobeerd te lanceren als een goedkopere consumenten-versie van de PC. Deze is echter gigantisch geflopt.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[onetime]

Ja ik was erbij. En ik heb vanaf dos2.2 de consumenten en hobbyisten invloed heel goed gezien. Inderdaad de Personal Computer. Wel reken ik thuis gebruik tot consumenten gebruik.
Ik had zelf een 286-12 toen iedereen nog 8088-8's kocht.
Wat jij puur zakelijk noemt had ik (gecopieerd) prive thuis.
En ik niet alleen. Weet jij wel wat een https://en.wikipedia.org/wiki/Microprofessor_I is?
(he, wist ik niet, is van naam veranderd, en waar typ ik dit op?...)

Op ieder buro stond er eentje

- Echt niet. Terminals? Of helemaal geen computer? Komt zelfs nu nog voor.

[Anoniem: 471038]

Ja ik was erbij. En ik heb vanaf dos2.2 de consumenten en hobbyisten invloed heel goed gezien.

IBM compatibles speelden bij thuisgebruik in de jaren 80 maar een hele kleine rol. Het was ook zeker niet het primaire doel van het platform (zoals ik zeg, IBM probeerde met de PCjr een PC voor thuisgebruik te lanceren... goedkoper, en meer gericht op spelletjes).

Ik ben verder heel benieuwd wat jij als 'consumenten en hobbyisten invloed' weet te noemen.

Ik had zelf een 286-12 toen iedereen nog 8088-8's kocht.

Ja, ik had thuis ook vrij vroeg een PC, maar er stonden ook oa een C64 en een Amiga (want die waren veel interessanter voor consumenten, oa vanwege de betere games, en creatieve software). Ik was een van de weinigen die een PC thuis had. Daarna kregen vrienden ook een PC thuis, veelal afdankertjes van het werk.

Zo waren er ook wel mensen die een Apple Mac thuis hadden, maar dat was zeker niet het primaire doel van de machine. Daarvoor was hij te duur, en had hij voor de gemiddelde consument te weinig te bieden.

Er is nogal een verschil tussen "Er zijn consumenten die een zakelijke computer thuis hebben staan" en "De computer is voor de consumentenmarkt ontwikkeld".

- Echt niet. Terminals? Of helemaal geen computer? Komt zelfs nu nog voor.

Bij hoge uitzondering ja. Feit blijft dat er veel meer IBM PCs in omloop waren dan minicomputers/mainframes.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[klakkie.57th]

@gryz

Sorry hoor maar mensen die assembly kunnen coden zitten echt wel een stukje hoger op de ladder dan de doorsnee java .net developer.

Show some respect !!!

[Anoniem: 125509]

Ik denk daar toch anders over. Ik heb voor elke groep evenveel respect.

Ik heb Java en .Net code gezien die heel geavanceerd is, en Assembler, C en C++ waar de honden geen brood van lusten.

Ik heb vooral respect voor mensen die de grenzen van het systeem durven verkennen en die zich niet laten verblinden door vooroordelen en aannames.

[Anoniem: 125509]

Wat een nonsense.

[wootah]

Een systeem kan bovendien alleen worden beschermd als er een patch beschikbaar is. Het probleem is dat gebruikers apparaten als routers, nas-systemen en zelfs draadloze webcams met een ingebouwde webserver vaak minder snel patchen dan een desktop-besturingssysteem, en daardoor nog jarenlang kwetsbaar kunnen zijn.

Dat zegt tweakers dan wel, maar praktisch alle embedded linux apparaten draaien busybox. Busybox is niet vatbaar voor shellshock zover nu bekend en zover ik nu zelf heb kunnen testen op mijn routers en dergelijke.

[Mont2uk]

Thanks!
Ik was niet op de hoogte dat busybox niet vatbaar is. Nu hoop ik niet dat alsnog soortgelijke exploits voor busybox aan het licht komen. Dit zou, om de bekende redenen, een nog groter probleem zijn dan het probleem nu met bash.

[Reactie gewijzigd door Mont2uk op 23 juli 2024 00:10]

[dtech]

Zoals ik zei: er zijn al twee patches in een week geweest, en het probleem is nog niet opgelost.
Kwaliteit van de patch wordt dus NIET bewaakt.

Jullie hebben het over 2 verschillende definties van kwaliteit: de ene is dat het systemen niet instabiel maakt e.d., de andere is dat ze het lek (volledig) oplossen.

De afgelopen 2 patchen lossen het probleem niet 100% op aangezien er (ingewikkeldere/moeilijkere) manieren bleven om het lek te misbruiken, partial fixes dus. Ze beschermen echter wel tegen de tot dan toe bestaande exploits in the wild.

Ik zou zeggen dat 3 partial fixes met 5 dagen ertussen beter zijn dan 1 volledige fix na 2 weken, aangezien er telkens nieuwe exploits moeten worden ontwikkeld tussendoor die maar kort vatbaar blijven.

[Reactie gewijzigd door dtech op 23 juli 2024 00:10]

[Anoniem: 471038]

Jullie hebben het over 2 verschillende definties van kwaliteit: de ene is dat het systemen niet instabiel maakt e.d., de andere is dat ze het lek (volledig) oplossen.

Het is een beetje onzinnig om patches uit te brengen die een lek zouden moeten dichten, maar dit niet doen.
Mensen moeten namelijk hun systeem dan meerdere keren patchen, wat dus niet wenselijk is, vanwege de extra overhead etc. Van kwaliteit kun je dan dus niet spreken.

Ik zou zeggen dat 3 partial fixes met 5 dagen ertussen beter zijn dan 1 volledige fix na 2 weken, aangezien er telkens nieuwe exploits moeten worden ontwikkeld tussendoor die maar kort vatbaar blijven.

Ik zou zeggen dat je dan niet erg realistisch denkt.
In grotere organisaties kun je niet zomaar alles direct gaan patchen. Je moet eerst zo'n patch in een test-omgeving draaien, om te zien of alles blijft werken etc. Dat kan een aantal dagen duren.
Als mensen dan iedere keer met nieuwe patches komen, kun je iedere keer je tests opnieuw gaan beginnen (en kom je sowieso niet tot het uitrollen van de patch, als de patches elkaar sneller opvolgen dan jij je omgeving kunt testen).
Het is dus veel wenselijker om 1 keer een goede patch te hebben, die 1 keer door de test-cycles heen te gooien, en dan 1 keer uit te rollen.

[the-dark-force]

Mensen moeten namelijk hun systeem dan meerdere keren patchen, wat dus niet wenselijk is, vanwege de extra overhead etc. Van kwaliteit kun je dan dus niet spreken.

inderdaad, veel beter om een systeem een aantal weken met kwetsbaarheden te draaien dan de moeite moeten doen om iets meerdere keren te patchen...
wees blij dat deze fixes iig de scriptkiddy's buiten de deur houden.

Je moet eerst zo'n patch in een test-omgeving draaien, om te zien of alles blijft werken etc. Dat kan een aantal dagen duren
Het is dus veel wenselijker om 1 keer een goede patch te hebben, die 1 keer door de test-cycles heen te gooien, en dan 1 keer uit te rollen

helemaal mee eens, alleen het is overduidelijk dat je heel veel problemen gaat krijgen met bestaande scripts en software wanneer je de source van bash opknapt dus het testen kun je overslaan want 't maakt niet uit of de bug gefixt is als de rest van de software daardoor niet meer draait.

Daarnaast heb je niets aan de fix als er 3 soortgelijke bugs zijn gevonden en zou het dus misschien beter zijn om bash te reviseren.
incompatibility blijft een issue.

[Anoniem: 471038]

inderdaad, veel beter om een systeem een aantal weken met kwetsbaarheden te draaien dan de moeite moeten doen om iets meerdere keren te patchen...
wees blij dat deze fixes iig de scriptkiddy's buiten de deur houden.

Tsja, dat 'aantal weken' zuig jij uit je duim, dat is nergens op gebaseerd. Als we dat weglaten, is je verhaal ineens niet meer zo overtuigend.

Daarnaast heb je niets aan de fix als er 3 soortgelijke bugs zijn gevonden en zou het dus misschien beter zijn om bash te reviseren.
incompatibility blijft een issue.

Vrij simpel te ondervangen hoor.
Je kunt oude en nieuwe versies van bash naast elkaar draaien. Het is dan zaak om zo snel mogelijk je scripts te herschrijven zodat je de oude versie van bash kunt uitfaseren.

In andere markten is dat vrij gangbaar. Met Java, VB, C# etc moet je vaak ook je code op bepaalde punten aanpassen om met een nieuwe versie te werken. Sowieso heb je bij APIs/libraries vaak dat oudere functies 'deprecated' zijn, en dat je je code beter kunt aanpassen voor het gebruik van nieuwe functies.

[the-dark-force]

Als je bash goed wil opknappen dan zal daar zeker wel een fikse tijd overheen gaan aangezien je met compatibiliteit zit (het is een beetje flauw als je dhcp-client stopt na een fix) zeker als er 3 vergelijkbare bugs zijn dankzij het systematisch falen vd developer waardoor mogelijk grote delen code herschreven moeten worden.

als het zo simpel naast elkaar draait dan draai je bewust kwetsbare code ivm compatibility en dan beticht je het developers team van half werk ?!
daarnaast zal even snel al je scripts aanpassen vast tegenvallen, als je zelf zoveel vertrouwen in jouw oplossing had was het naast elkaar draaien van bash immers niet nodig.

ik denk dat een aantal weken zelfs nog redelijk krap is om bash fatsoenlijk op te knappen en de afhankelijke software probleemloos te laten draaien zonder er een kwetsbare bash naast te draaien...

[Anoniem: 471038]

als het zo simpel naast elkaar draait dan draai je bewust kwetsbare code ivm compatibility en dan beticht je het developers team van half werk ?!
daarnaast zal even snel al je scripts aanpassen vast tegenvallen, als je zelf zoveel vertrouwen in jouw oplossing had was het naast elkaar draaien van bash immers niet nodig.

Uhh wat?
Volgens mij begrijp je niet wat ik bedoel.
Wat ik bedoel is dat er straks misschien twee versies van bash zijn:
- legacy-bash (de huidige versie, die zo goed en zo kwaad als het kan gepatcht is tegen de ergste aanvallen)
- nextgen-bash (de rewrite, waar de security-problemen definitief opgelost zijn)

Die installeer je naast elkaar. Standaard gebruik je legacy-bash, want dan blijft alles werken.
Maar, dan ga je je scripts een voor een migreren naar nextgen-bash. Totdat er straks geen legacy-bash meer nodig is, en dan deinstalleer je die.

[the-dark-force]

in de tussentijd blijf je dus kwetsbaar dankzij je legacy bash en juist hetgeen dat bash zo sterk maakt (compatibiliteit) raak je dan kwijt met je next-gen bash.
't lijkt dan net een overheids ict project.

dan kun je net zo goed overstappen op dash o.i.d.

[Anoniem: 471038]

in de tussentijd blijf je dus kwetsbaar dankzij je legacy bash

Als er geen rewrite van bash komt, blijf je ook kwetsbaar. Er is dus geen alternatief.
Je moet overstappen naar de nieuwe bash, hoe sneller, hoe beter.

en juist hetgeen dat bash zo sterk maakt (compatibiliteit) raak je dan kwijt met je next-gen bash.

Wederom, je hebt geen keuze. Ofwel je houdt de oude bash, en je blijft kwetsbaar, ofwel je stapt over op de nieuwe.
Maar omdat iedereen overstapt op de nieuwe, is de compatibility geen issue meer.

dan kun je net zo goed overstappen op dash o.i.d.

Dat kan ook ja. Je moet overstappen naar een shell die geen last heeft van deze security-issues. Welke dat precies is, dat maakt niet zo veel uit. Hangt meer af van hoeveel werk het is om je scripts om te schrijven naar de nieuwe shell.

[280562]

Als je bash goed wil opknappen dan zal daar zeker wel een fikse tijd overheen gaan aangezien je met compatibiliteit zit (het is een beetje flauw als je dhcp-client stopt na een fix) zeker als er 3 vergelijkbare bugs zijn dankzij het systematisch falen vd developer waardoor mogelijk grote delen code herschreven moeten worden.

Grote woorden.
En waarom zouden grote delen van bash herschreven moeten worden ?

Wat ik begrepen heb dat er aan de hand is:

Als een proces een ander proces opstart, dan worden de environmental-variables doorgegeven aan het child-process. Op zich geen probleem. Wat er mis is, is dat de bash in het child-process alle variabelen waarvan het denkt dat het een functie is, eerst echt uitvoert. Door het uitvoeren wordt die functie "geladen".

Dit kan misbruikt worden als je commands toevoegt achter de functie. Dan wordt niet alleen de functie uitgevoerd, maar ook de commands aan het einde.

De truc is dus om een systeem een environment variable aan te laten maken. Die variabele er uit te laten zien als een functie. En er malicious code achter aan te plakken.

De eerste 3 patches proberen om de parser zo te fixen dat hij zich niet meer in de luren laat leggen.

De echte fix is natuurlijk dat wanneer bash opstart, het niet meer moet proberen om alle functies van het moeder-process uit te voeren. Ik denk dat de uiteindelijke fix dat dan ook zal doen.

Andere shells, (de Bourne shell, c-shell, tcsh, etc) hebben die probleem niet. Er is dus niks mis met Unix. Niks mis met de "oude manier van programmeren". Het was een design-fout in de architectuur van shell-functions. in Bash, en alleen in bash. Mensen hier trekken veel te vergaande conclusies, zonder van de hoed en de rand te weten.

[the-dark-force]

Omdat er meer is als alleen deze bash bug, als er 3 vergelijkbare bugs zijn gevonden en je moet meerdere scripts aanpasen aan de hypothetisch vernieuwde bash versie kun je toch stellen dat er grote delen code herschreven moeten worden ?
Wat natuurlijk extra leuk is bij de projecten met weinig of geen actieve developers.

(Ik had het over grote delen code niet over grote delen van bash, het valt me nog mee dat niemand is begonnen over het feit dat "groot" een relatief begrip is dus < echo "Hello World" is groot in mijn optiek )

[Reactie gewijzigd door the-dark-force op 23 juli 2024 00:10]

[280562]

kun je toch stellen dat er grote delen code herschreven moeten worden ?

Nee.
Het enige wat moet gebeuren (lijkt me) is een andere manier om functies te laden. Andere shells doen het wel goed. Het lijkt er op dat de laatste 3 bugfixes de parser beter willen laten opletten. Dat zou kunnen werken. Maar de beste manier is om het onderliggende probleem op te lossen. En dat is dat shellfuncties niet moeten worden aangeroepen als er een nieuw process start. Maar enkel en alleen als de programmeur van het shell-script een functie ook daadwerkelijk aanroept.

[dtech]

Als een partial fix echt zo'n groot probleem is, dan hebben mensen toch de optie om hem niet te apply'en? Het is in ieder geval nooit slechter om een partial fix of workaround te hebben zolang het een volledige fix niet vertraagd.

[Anoniem: 471038]

Als een partial fix echt zo'n groot probleem is, dan hebben mensen toch de optie om hem niet te apply'en?

Nee, die optie hebben ze niet.
De fix werd namelijk niet als partial fix gepresenteerd. Pas later werd ontdekt dat de fix toch niet helemaal goed was, en er een tweede fix nodig was.
Als men iets meer tijd had besteed aan het analyseren van het probleem en het testen van de eerste fix, dan was ie meteen goed geweest. Dat is quality control.

Het is dus wel slechter om een fix te hebben die geen volledige fix is.

[Countess]

Als men iets meer tijd had besteed aan het analyseren van het probleem en het testen van de eerste fix, dan was ie meteen goed geweest. Dat is quality control.

je mist het punt! er is geen kant en klare oplossing! het was dus niet een kwestie van zeg een uurtje langer er aan werken, en heeft dus helemaal niks met quality control te maken.

de partial fix beschermde al wel tegen alle op dat moment in het wild verschenen exploits. een volledige patch kan een paar weken duren. dat is VEEL te lang om de exploits die er al waren hun gang te laten gaan.

[H!GHGuY]

Zoals ik zei: er zijn al twee patches in een week geweest, en het probleem is nog niet opgelost.
Kwaliteit van de patch wordt dus NIET bewaakt.

Informeer uzelf. Het security gat an sich is opgelost met de 2de patch.
Waar ze nu nog over schreeuwen is een FEATURE die misbruikt kan worden.

Er is dus nog een veelgebruikt feature wat kan misbruikt worden, maar dat kan je niet oplossen zonder een groot deel van alle scripts die bash gebruiken te breken. Dit is gewoon het gevolg van een design beslissing.

[Anoniem: 471038]

Waar ze nu nog over schreeuwen is een FEATURE die misbruikt kan worden.

It's not a bug, it's a feature!
Waar heb ik dat vaker gehoord?

maar dat kan je niet oplossen zonder een groot deel van alle scripts die bash gebruiken te breken. Dit is gewoon het gevolg van een design beslissing.

Yup, zo zit de *nix/open source-wereld vol met foute ontwerpbeslisingen, die er al decennialang in zitten.
Hoog tijd om er nog eens kritisch naar te kijken, en de nodige dingen te herschrijven.

Of begrijp ik je verkeerd? Bedoel je dat omdat bash nu eenmaal zo ontworpen is, en omdat er zoveel bash-scripts zijn, dat we bash maar gewoon zo moeten laten, ook al kan het vrij makkelijk misbruikt worden?

[H!GHGuY]

Waar het nu nog om draait is dat je dit kan:

[code]
$ cat <<EOF >test.sh
#!/bin/bash
cat /dev/null
EOF

$ chmod a+x test.sh
$ env cat='() { echo rm -rf /; }' ./test.sh
[/code]

Deze feature wordt echter ook gebruik om bvb dit te kunnen doen:
[code]
VAR=true
if [ "$1" -eq "--false" ]
then
VAR=false
fi
# verder
if $VAR
then
echo "--false was passed"
fi
[/code]

Gewoon een run-of-the-mill feature wat misbruikt wordt. Hoe ze dit gaan oplossen, no idea.
Trouwens "it's a feature, not a bug" is een idiote opmerking hier. Het gaan om backwards compatibility versus security. Dat is geen simpele afweging. Alle voorstellen die je eerder in deze thread tentoonstelt zijn een spijtig vertoon van hoog van de toren blazen.

Kijk hier maar eens:
https://lwn.net/Articles/613640/
Tonnen packages hebben updates gekregen voor deze bash-bug. Een probleem als dit los je niet zomaar even op met bash-nextgen die de bug niet heeft. Of door 3 developers een week lang op te sluiten met laptop en een testomgeving zodat ze na die week van de eerste maal een goeie oplossing hebben.

Onze eerste fix na het patchen van bash was in python code os.system() vervangen door subprocess.Popen().

[Reactie gewijzigd door H!GHGuY op 23 juli 2024 00:10]

[Blokker_1999]

Ik ga ermee akkoord dat men regelmatig moet durven om functionaliteit te herschrijven en andere developers dient te dwingen om rekening te houden met vernieuwde/aangepaste functionaliteit om de veiligheid te garanderen. De computer van vandaag is niet meer dezelfde als deze van 20 jaar geleden. Er draait zoveel rommel op het internet vandaag dat de vereisten op gebied van veiligheid totaal zijn veranderd.

[Anoniem: 28912]

Ja, maar ik snap het verhaal niet helemaal.

Bash heeft toch gewoon een optie om environment variabelen niet mee te nemen? Is het eigenlijk ook niet een beetje de schuld van luie ontwikkelaars die de hogere environment variabelen mee pakken zonder over security na te denken?

[Blokker_1999]

Euhm jawel, de fout die gevonden werd, werd telkens aangepakt en er werd met de patch geen nieuwe bug gevonden. Wel komt men er achter dat er steeds ook een dieper probleem in blijkt te zitten. Dat kan je niet op de kwaliteit van de patch steken.

En neen, die drempel die hoort niet hoger te liggen. Als ik zie wat er soms op zulke mailing lists verschijnt dan zie je daar ook echt alles verschijnen. Iemand die iets niet durft vermelden op een mailinglist zal dat ook niet melden aan de koffie automaat.

[Anoniem: 471038]

Dat kan je niet op de kwaliteit van de patch steken.

Niet in enge zin. Maar ik bedoelde het breder: Men vindt een exploit... Ipv dan alleen maar even snel een patch te maken die deze exploit tegengaat, zou de omliggende code ook kritisch bekeken moeten worden: "Okee, dit probleem zit hier dus... zitten er toevallig soortgelijke problemen?" Dat is kwaliteit: verder kijken dan je neus lang is.
Blijkbaar vindt men de volgende dag een gerelateerd probleem, dus was de kwaliteit van de oorspronkelijke probleemanalyse te laag. Met een betere analyse was dat probleem meteen met de eerste patch meegenomen.

En neen, die drempel die hoort niet hoger te liggen. Als ik zie wat er soms op zulke mailing lists verschijnt dan zie je daar ook echt alles verschijnen. Iemand die iets niet durft vermelden op een mailinglist zal dat ook niet melden aan de koffie automaat.

Nogmaals, jij lijkt je niet in die situatie in te kunnen leven. Ik heb het niet over 'durven'. Ik heb het over het feit dat er gewoon een lagere drempel is voor het toevallig tegenkomen van een collega en even een informeel praatje maken, dan daadwerkelijk achter je computer te gaan zitten, je mailclient te openen, en een verhaal naar een mailinglist te typen.

[H!GHGuY]

Probleem was dat er in zo'n geval ook gewoon snel moet gereageerd worden. Je kan niet even een weekje opzijzetten om eens na te denken.
Daarnaast was de bug op het randje af van het disclosure embargo naar buiten gekomen en waren 4.5 uur later al exploits gespot...

Je kan je maar afvragen hoe snel Microsoft, Oracle of Adobe gereageerd zouden hebben op een bug van deze omvang.

[the-dark-force]

oh ik heb juist het idee dat mensen makkelijker communiceren veilig achter het schermpje, zie 4chan bijvoorbeeld

[Enai]

Het is niet omdat men kán kijken naar code dat men het ook doet. Wat is er interessant aan Bash?

[Anoniem: 463321]

Juist. Daarom is Open source niet per definitie beter zoals altijd gesuggereerd wordt. Hoeveel open code is niet meer bekeken? Na heartbleed en shellshock zal inderdaad meer gaan volgen.

[Countess]

Na heartbleed en shellshock zal inderdaad meer gaan volgen.

en juist dat geeft de kracht van open source aan. want dat is een fenomeen dat bij propitiatory code helemaal niet kan.

een bedrijf zal zeggen, probleem opgelost, klaar. vergeten en doorgaan waar we mee bezig waren.

maar bij opensource is na heartbleed, en na deze bug helemaal, de community geintereseert in de oude code die nog in gebruik is. sterker nog, door de eerste gevonden shellshock bug zijn gelijk nog een aantal andere bugs aan het licht gekomen. ook iets dat je niet ziet bij propitiatory code.

[Anoniem: 471038]

want dat is een fenomeen dat bij propitiatory code helemaal niet kan.

Het kan best hoor.
Dit is niet *helemaal* hetzelfde, maar ik heb oa patches gemaakt voor nVidia's Endless City: http://scalibq.wordpress....ellation-demo-on-radeons/
En Triton's Crystal Dream: http://scalibq.wordpress..../14/oldskool-demo-fixing/

Allebei niet open source, en in beide gevallen had ik dus ook geen toegang tot de source code. Toch heb ik patches kunnen maken. In het eerste geval heb ik de 'bug' gefixt dat je Cuda nodig had, en een nVidia kaart. Na de patch heb je een universele DX11-demo.
In het tweede geval heb ik de buggy Sound Blaster-code vervangen door code die wel werkt.

Bugs vinden en patchen in proprietary code kan dus wel degelijk.

[Anoniem: 125509]

Hoeveel mensen doen dat? Aan de ene kant geef je af op het gebrek aan reviews bij open source. En in een 'geniale' zet is dit je bewijs dat het reviewen van closed source mogelijk is? Komt op mij over als een enorme tunnelvisie.

[Anoniem: 471038]

En in een 'geniale' zet is dit je bewijs dat het reviewen van closed source mogelijk is?

Het is inderdaad het bewijs dat het mogelijk is. Meer niet.
Ik zou het dan ook op prijs stellen als je die opmerking over tunnelvisie terugtrekt.
Ik vind namelijk jouw visie ook wel een beetje 'apart'. Je hebt nu al op behoorlijk wat reacties van mij gereageerd, en in veel gevallen prober je wat ik zeg nogal uit z'n verband te trekken, wat steeds weer neerkomt op hetzelfde punt dat jij tevergeefs probeert te maken.

[Anoniem: 125509]

Helder, het is me nu duidelijk dat je aan het trollen bent. Ik trek me uit de discussie terug.

[Anoniem: 471038]

Helder, het is me nu duidelijk dat je aan het trollen bent.

Na tunnelvisie beschuldig je me nu weer van trollen.
Wat is er trollend aan iemand laten zien dat je ook bij closed-source best naar de code kunt kijken, en er best dingen aan kunt aanpassen?
Ik probeer mensen gewoon iets bij te brengen, want er werd beweerd dat het helemaal niet mogelijk was. Dat is het wel.
Ik heb nergens beweerd dat het makkelijk is.

Probeer je krampachtig je gelijk te halen, of ben je gewoon jaloers op mijn skills?

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Gomez12]

[...]
en juist dat geeft de kracht van open source aan. want dat is een fenomeen dat bij propitiatory code helemaal niet kan.

Tja, hoe zal ik het zeggen : OS had 20 jaar de tijd om dit fenomeen toe te passen, maar het is al 20 jaar niet gebeurt (in het openbaar dan, er zullen vast wel wat black hackers dit hebben gedaan).

Oftewel het feit dat het kan zegt niets, het toont wmb meer een probleem aan bij OS dat er formele regels ontbreken op gedeeltes die overgenomen worden. Qua eigen code zijn er goede regels, maar er wordt van alles overgenomen en dat wordt veelal niet meer gecontroleerd.

[280562]

Ik zou willen dat bij iedere poster hier op Tweakers.net er een icoontje naast de naam verschijnt, dat aangeeft wat zijn functie is. Programmeur, web-designer, sysadmin, netwerk-admin, support, management, sales, marketing, etc.

Heb je wel eens serieus geprogrammeerd ? Voor je beroep, dat je er geld mee verdient ? Heb je wel eens andermans code moeten onderhouden of veranderen ?

Dan zou je weten dat je 100 keer naar code kunt kijken, maar dat dat nog niet betekent dat je direct ziet wat er gebeurd of wat er mis is. Dat geld voor zowel open-source als proprietary. Het vinden van bugs berust voornamelijk op toeval. En bij toeval is het zo: hoe vaker je een dobbelsteen rolt, des te hoger de kans dat je een keer een 6 rolt.

[GekkePrutser]

Ik zou willen dat bij iedere poster hier op Tweakers.net er een icoontje naast de naam verschijnt, dat aangeeft wat zijn functie is. Programmeur, web-designer, sysadmin, netwerk-admin, support, management, sales, marketing, etc.

Zoiets is er al, klik maar op een username. Bij Gomez12 zie je dan dat hij inderdaad professionele software development ervaring heeft.

Zoiets uitgebreids als het profiel kan je nooit in 1 icoontje vangen natuurlijk. En niet iedereen vult het in (zoals jijzelf )

[280562]

Volgens zijn account-page heeft Gomez12 ervaring met alles. Fantastisch. Ik geloof dat een mens specialist in maar 1 ding kan zijn. Als je bereid bent om alles overhoop te gooien, dan kun je misschien eens per 7 jaar of zo specialist ergens anders in worden. Maar specialist in alles ?

[Countess]

ik geloof niet dat je begrepen hebt wat ik probeerde te zeggen.

wat er gebeurt nadat een bug is gevonden is fundamenteel anders als bij propitiatory software. het vinden van deze bug heeft bijvoorbeeld gelijk geleid tot het vinden van meer bugs in de zelfde code. en zelfs het vinden van de eerste bug is een direct gevolg van de heartbleed bug.

niks van dat alles zou zijn gebeurt in Proprietary. die zouden heartbleed hebben gefixed en daarna weer verder zijn gegaan op de normale manier.

dat er nu meer bugs naar boven komen in OS software is een GOED iets, dat aangeeft dat het WEL werkt.

[BlackOwl]

Dat die bugs zo lang in de code hebben mogen blijven zitten is een SLECHT iets, dat aangeeft dat het NIET werkt.

[Shark.Bait]

Juist. Daarom is Open source niet per definitie beter zoals altijd gesuggereerd wordt. Hoeveel open code is niet meer bekeken? Na heartbleed en shellshock zal inderdaad meer gaan volgen.

Nee, dat is niet zeker. We nemen nu immers allemaal aan dat "iemand" er wel naar zal kijken die kundig genoeg is. Wat wel zeker is dat criminelen er naar zullen kijken omdat ze bij zwakheden er geld aan kunnen verdienen. Mensen zijn net hondjes, zonder beloning komt er niet veel van terecht..

[H!GHGuY]

Goeie baas heb je. Hij laat je technical debt wegwerken.

Op veel plaatsen is het mantra echter: ben je geen features (=added value) aan het schrijven dan kost je alleen maar geld.

[Tonko Boekhoud]

Periodiek refactoren hoort gewoon bij lifecycle management.
Als je klanten je aansprakelijk stellen voor schade door verouderde code, kost dat ook alleen maar geld.


_{edit: typo}

[Reactie gewijzigd door Tonko Boekhoud op 23 juli 2024 00:10]

[H!GHGuY]

Mij moet je niet overtuigen. Ik stel alleen dat er genoeg bedrijven zijn waar refactoring geen deel is van de normale cyclus.
Technical debt is wat het is: debt. En op schulden krijg je rente. Wanneer de rentesneeuwbal op je afkomt is het "dag met het handje".

[Anoniem: 471038]

Goeie baas heb je. Hij laat je technical debt wegwerken.

Op veel plaatsen is het mantra echter: ben je geen features (=added value) aan het schrijven dan kost je alleen maar geld.

Ik ben dan ook zelf degene die de lijnen uitzet, en ik weet uit ervaring dat je soms gewoon moet uithuilen en opnieuw beginnen. Mensen die alleen maar nieuwe features willen zien, hebben het niet begrepen.

[Anoniem: 125509]

Bash is de afgelopen week al twee keer gepatcht, en nog steeds is het eigenlijke probleem niet opgelost.

Het is inderdaad jammer dat de community hier zo paniekerig reageert. Maar goed, het blijft wel een keuze van een beheerder of hij dit soort snelle pleisters ongetest op zijn systeem los laat.

Aan de andere kant. In sommige situaties stonden systemen wagenwijd open, zonder een goede work-around om het te sluiten. Dan kan een fix die in elk geval de bestaande exploits afblocked een goede keuze zijn.

Dit nieuwsbericht geeft dus ook aan dat het probleem eigenlijk niet te patchen valt

Ik zie niet in waarom dat blijkt. Het gebeurt echt wel vaker dat een fout meerdere patches krijgt. Soms eerst een grote pleister die het lek faliekant afsluit, gevolgd door kleinere pleisters en zalfjes die gerichter werken. Maar ook een pacht die gevolgd wordt door nog een patch of patches omdat het lek niet dicht blijkt te zitten.

Het zegt weinig over de kwaliteit en of leeftijd van code. Hooguit over de kwaliteit van een patch of de complexiteit van het probleem.

[Anoniem: 471038]

Ik zie niet in waarom dat blijkt.

De security-expert zegt dit:

Volgens beveiligingsonderzoeker Robert Graham is de onderliggende code van Bash ernstig verouderd. De Bash-bug, die ook wel Shellshock wordt genoemd, is volgens hem niet meer dan een waarschuwing dat er meer bugs zullen volgen. "De oorzaak is niet een programmeur die een fout heeft gemaakt, maar een systematisch falen in de code", schrijft Graham, die aantekent dat er al drie vergelijkbare bugs zijn gevonden. "De code is verouderd en geschreven naar de standaarden van 1984 in plaats van 2014."

Kortom, hij zegt dat het niet een incidentele bug is, maar dat bash structureel verkeerd in elkaar zit, en eigenlijk herschreven zou moeten worden.

[Anoniem: 125509]

Point taken. Ik was kennelijk niet goed wakker toen ik mijn reactie pende.

[Loller1]

Wat heb je aan "sneller doorvoeren" als je in 1 week tijd 2 updates voor een bug uitbrengt die de bug niet oplossen? Niks sneller, het duurt bij beide ongeveer even lang.

[Fr0ns]

Hoezo zou dit sneller gaan? Die zie ik niet helemaal geloof ik.

[12345dan]

Nee, closed-source is veiliger... Sorry hoor, maar hier is het niet mogelijk om doelbewust gaten te houden en ze daarna zelfs te verkopen. Ja, er is af-en-toe een probleem, zoals nu. Ik lees elke dag dat besturingssystemen van commerciële bedrijven immense lekken bevatten, en Linux? Nee, enkel nu.

[Loller1]

Denk je nu echt dat Linux nu gewoon 1 lek bevat en er dan weer een lange tijd geen heeft? Linux zelf zit ook vol gaten, het is software, door mensen gemaakt, het kan niet perfect zijn, en dus bevat het beveiligingslekken en gaten. Ga eens kijken bij open source software hoeveel kritieke lekken ze wel niet fixen, Firefox en Chrome zijn zeer goede voorbeelden daarvan. Niks tegen open source trouwens, maar het argument dat je software zou moeten gebruiken omdat het open source is en "closed source" slecht is is totale onzin.

[12345dan]

Graag ook even lezen waarop ik reageer. Ik veronderstel dat open-source software over het algemeen wel degelijk veiliger is dan closed-source besturingssystemen. Uiteraard, het vertelt enkel iets over het licentiemodel. Als ik echter voorbeelden neem, Linux vs Windows en Linux vs OS X, veronderstel ik dat er minder malware in het wild te vinden is voor open-source software. Android hoort hier uiteraard niet bij, maar dat komt door de nalatigheid van Google om onder andere alle applicaties toe te laten zodat de applicatiemarkt meer applicaties bevat dan Apples App Store.

Bovendien heb ik niet gezegd dat closed-source slecht is, iOS en OS X zijn prima besturingssystemen.

[Anoniem: 471038]

Als ik echter voorbeelden neem, Linux vs Windows en Linux vs OS X, veronderstel ik dat er minder malware in het wild te vinden is voor open-source software.

Maar dit zegt niets over hoe veilig of onveilig een systeem is.
Puur theoretisch zou het best kunnen dat er totaal geen malware is voor het minst veilige OS ter wereld, om de simpele reden dat niemand ooit malware ervoor geschreven heeft.
Omgekeerd kan het ook zijn dat het meest veilige OS ter wereld toch de meeste malware heeft, omdat zelfs het meest veilige OS niet 100% waterdicht is, en om de een of andere reden iedereen nu net dit OS getarget heeft (misschien vanwege het grootste oppervlak, of omdat er het meest te halen valt qua bankgegevens of iets... of noem maar wat. Misschien is er zelfs maar 1 lek in het hele systeem, en target al die verschillende malware eigenlijk datzelfde lek. Er is zelfs malware die niet eens een lek in het OS uitbuit, maar puur op social engineering gebaseerd is).

Er spelen dus veel meer factoren een rol bij de hoeveelheid malware dan puur en alleen de veiligheid van een OS.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[12345dan]

Volledig mee eens, ik maakte echter vergelijkingen met vaakgebruikte software. Dus hier geldt dat niet.

[Anoniem: 120693]

Ga eens kijken bij open source software hoeveel kritieke lekken ze wel niet fixen, Firefox en Chrome zijn zeer goede voorbeelden daarvan.

Mmmmm hoeveel? Bij Chrome en Firefox zijn er vrijwel kritieke lekken gesloten in de laatste 12 maanden. Waarschijnlijk omdat die niet gevonden zijn.

Ik ben het geheel met je eens dat er in veiligheid niet veel verschil was maar de laatste twee problemen op het niet MS platform zijn bijzonder ernstig in omvang en gevaar. En Bash bug is not steeds niet gefixed en er zullen miljoenen apparaten in de wereld in gebruik blijven waarbij deze bug een gevaar zal blijven zijn. Ik weet al dat ik sommige wat oudere apparatuur zal moeten afdanken omdat de firma's niet meer bestaat om me patches te sturen. Probleem bij de bashbug is dat er niemand ECHT verantwoordelijk is.

[Rolfie]

Ik krijg vaker updates in mijn linux machines dan op mijn windows machines.

De hoeveelheid opensource bugs is echt niet kleiner dan op closed source.

[12345dan]

Linuxdistributies komen er tenminste vooruit. Apple noemt de meest kwaadaardige fouten een nihil-achtig iets.1

Bovendien dichten vele commerciële bedrijven veel lekken in één keer. Apple is daar een voorbeeld van, bij de release van iOS 8 zijn bijna 60 lekken gedicht, terwijl iOS 7 maandenlang niet is geupdated.

[latka]

Windows update doet alleen kernel, browser en notepad updates. Linux distributies hebben het over 10.000+ applicaties die via een kanaal binnen komen. Totdat MS de algehele distributietaak op zich neemt is het appels en peren vergelijken.

[Zer0]

maar hier is het niet mogelijk om doelbewust gaten te houden en ze daarna zelfs te verkopen.

Stel dat de Shellshock geen bug was, maar opzettelijk door Chet geplaatst was en er daadwerkelijk sinds 1992 al in zit...Niemand heeft hem sinds die tijd ontdekt...
Het is zeker niet ondenkbaar dat het mogelijk is met opzet "bugs" te plaatsen in Open Source software.

[Gomez12]

[...]

Stel dat de Shellshock geen bug was, maar opzettelijk door Chet geplaatst was en er daadwerkelijk sinds 1992 al in zit...Niemand heeft hem sinds die tijd ontdekt...

Geen enkele white hat hacker heeft hem ontdekt / gemeld. Dat zegt echter niets over of het ding al dan niet ontdekt is...

[Anoniem: 118226]

Ook closed source zegt ook alleen iets over het licentiemodel.

Veiligheid en kwaliteit krijg je van goed programmeer werk, reviews, testen, testen en testen. In de vorige zin staat niets over closed of open source, omdat dat er niets mee te maken heeft.

[halofreak1990]

Sorry hoor, maar hier is het niet mogelijk om doelbewust gaten te houden en ze daarna zelfs te verkopen.

Jawel. Als je maar creatief genoeg bent, kun je zelfs in een open-source project backdoors en whatnot implementeren zonder dat iemand anders er ook maar een flauw idee van heeft. Dat open source beter en/of veiliger zou zijn dan closed source is een mythe.

[neeroeter]

Bij cloesed source weet je uberhaupt niet waar de gaten liggen totdat je daadwerkelijk aangevallen wordt, da's ook niet lekker. Je weet ook niet hoeveel aandacht betreffend bedrijf aan de bugs schenkt.
Elke software heeft bugs. Bij open-source mag de organisatie ervan wellicht niet on par zijn met een closed-source beherend bedrijf, de transparantie en open discussie maken heel veel goed. Deze bash toestand maakt dat wat mij betreft weer eens duidelijk. Opvallend hoe Apple niet verder komt dan dat het voor de gemiddelde gebruiker geen issue zal zijn en dat ze ergens wel met een fix komen, met andere woorden, ze schieten weer eens in de kramp...

[Anoniem: 118226]

Bij open source weet je ook niet waar de gaten liggen totdat je daadwerkelijk aangevallen wordt.

Let er ook even op dat ik nergens zeg dat een model beter is als het andere. Open of closed zegt iets over het licentie model. Veiligheid en kwaliteit krijg je van goed programmeerwerk, reviews, testen, testen en testen. Dat staat los van open of closed.

Niet zo als een fanboy in de kramp schieten

[Caelorum]

Bij open source weet je ook niet waar de gaten liggen totdat je daadwerkelijk aangevallen wordt. [....]

Mwoah, met het verschil dat je bij closed source afhankelijk bent van de ontwikkelaar om aan te geven vanuit welke hoek je kwetsbaar ben, waar dat bij open source iedereen met de kennis van programmeren je dat uiteindelijk zou kunnen vertellen. Zodra je weet waardoor je kwetsbaar bent kan je er al dan niet iets aan doen. In dit geval zou je kunnen proberen bash te vervangen door iets anders, al is dat in veel gevallen niet meer echt te doen.
Iedereen zegt hier zo mooi dat veiligheid los staat van open en closed source en dat dat laatste alleen een licentiemodel is en dat is gewoon niet waar. Het zegt wel degelijk ook iets over de veiligheid. Namelijk de grootte van de groep die je informatie kan geven om de kwetsbaarheid te minimaliseren en dit kan zowel positief als negatief zijn (correlatie met hoeveelheid gebruikers?).

[Anoniem: 118226]

Even in de troll mode: Goh, een lek in open source software, in dit geval Bash. Miljoenen programmeurs staan te trappelen om in de code te duiken, dus het is al opgelost?

We hebben het hier over tamelijk complexe software en het aantal mensen dat bij het bekend worden van het lek daadwerkelijk iets nuttigs met de source code kan doen is beperkt. (Dat blijkt nu ook weer. Daar is echt geen ontkennen aan). Ook daar zit er geen verschil tussen closed en open source.

Veiligheid bereik je met goed programmeer werk, reviews, controles, testen, testen en testen. Dat vereist een goed organisatie, niet een bepaald licentiemodel.

[Caelorum]

Ik zeg niet dat software veiliger is als het opensource is, maar de effecten van kwetsbaarheden worden wel degelijk anders erdoor.

[H!GHGuY]

Het verschil tussen open- en closed-source zit in deze gewoon in het proces waarmee ze security issues te lijf gaan.

Open-source heeft een transparant model van development. Security issues zijn hier echter een kleine afwijking waarbij in veel gevallen eerst een kleine groep mensen het probleem analyseert en fixt + wat tijd geeft aan andere partijen om de patch klaar te stomen voor roll-out.

Bij closed-source is het koffiedik kijken of, hoe en wanneer er een fix komt.
Ik vraag me af hoe en hoe snel Microsoft/Apple/Adobe/Oracle zou reageren bij een probleem van soortgelijke omvang:
http://www.tomsguide.com/...ity-patch,news-19351.html
Het is niet also daar alles heilig is of van de eerste keer goed.

Voor de rest is het enige verschil dat open-source de gebruiker (white of black hat) de mogelijkheid heeft om... Niet dat ze dit effectief kan, doet of moet, maar de mogelijkheid is er. Zie het als een gratis escrow service.

Ten tweede biedt dit ook de mogelijkheid om zelf te patchen. Kijk naar PowerPC Apple gebruikers. Zij hebben geen support. De enige mogelijkheid die zij hebben is om de laatste versie van bash zelf te compileren. Kun je niet met closed-source. Op dit punt is zelfs iets te zeggen voor GPLv3, dewelke vereist dat gebruikers zelf replacements kunnen installeren van GPLv3 software.

[Anoniem: 471038]

Bij cloesed source weet je uberhaupt niet waar de gaten liggen totdat je daadwerkelijk aangevallen wordt, da's ook niet lekker.

Dat ligt er maar aan hoe 'closed' closed source is.
Wat jij stelt, geldt natuurlijk lang niet voor iedereen: de meeste gebruikers van open source kunnen de code niet lezen, en/of hebben niet de resources om zelf security-audits te doen op de code die ze gebruiken.
Bij bepaalde instellingen zou dat wel kunnen (bv overheid), maar daarvoor maken closed-source bedrijven ook vaak uitzonderingen. Zo is het bij Microsoft wel degelijk mogelijk om de code in te zien als third party.

[neeroeter]

Tegen betaling uiteraard
In het licht dat software idd altijd fouten bevat, gaat het om andere zaken. En dan is transparantie een goed argument voor open-source. De argumenten tegen open-source die ook hier weer eens worden neergelegd, zoals een rommelige of geen structuur, matige communicatie, die kan je als gebruiker belangrijk vinden en je tot een keuze doen komen. Ieder moet voor zichzelf maar beslissen wat hij belangrijker vindt.
Voor mij is het naast betrouwbaarheid, vooral het ideele karakter van open-source dat mij bevalt. Closed-source ? Zo weinig mogelijk op mijn boxes.
Nogmaals , dat er nu een open discussie plaatsvindt mbt deze ernstige bug of ontwerpfout, biedt mij vertrouwen. Naast dat door LAMP het internet het best leuk doet al een paar jaartjes. Klein voorbeeldje

[Anoniem: 471038]

Ik ben geen idealist, ik ben een perfectionist.
Daarom trekken dingen als open source en LAMP mij niet aan. Rommelige net-niet oplossingen.
Niet dat ik tegen open source an sich ben... Ik heb zelf ook een aantal projecten van mij onder de BSD-licentie vrijgegeven.

[Anoniem: 125509]

Ik ben geen idealist, ik ben een perfectionist.

Dat maakt de opmerkingen onder deze quote nogal curieus.

Ik als detacheerder weet dat closed source niet zelden aan elkaar hangt van puisten en omwegen. De organisatie heeft vooral de focus op vooruit gaan, nieuwe features en nieuwe functies om nieuwe markten te ontsluiten.

Het onderhouden van code en refactoren, om code up to date en logisch te houden, wordt gezien als een ongewenste kostenpost. Tot op het punt van een ontkenningfase ter grote van een metropool. Ik heb onderhoud mogen plegen op pakketten waarbij het team dat bezig was met het blussen van brandjes groter was dan het team dat bezig was met nieuwbouw.

Beweren dat open source en LAMP rommelige net-niet oplossingen zijn, getuigt van een zelfde ontkenningsfase. Je weet helemaal niet wat de kwaliteit van closed source is. In uitgelekte sources van bijvoorbeeld Microsoft kom je ook comments tegen, om van bepaalde stukken af te blijven omdat niemand die nog lijkt te begrijpen. Om die reden zou je als perfectionist dus Microsoft producten net zo goed als 'net niet, rommelige' pakketten moeten afwijzen.

Een perfectionist kijkt naar wat in welke situatie het beste past. Juist de idealist verbergt zich achter dit soort non-argumenten.

[Anoniem: 471038]

Je weet helemaal niet wat de kwaliteit van closed source is.

Ik wel. Zoals ik elders al noemde, ik reverse-engineer af en toe closed source applicaties, en pas zelf patches toe.

Een perfectionist kijkt naar wat in welke situatie het beste past.

Wederom,zoals ik elders al noemde, ik gebruik Windows en FreeBSD naast elkaar, om exact die reden.

[Anoniem: 125509]

Sorry, ik wil best veel geloven, maar niet dat je met een paar reverse engineering projecten genoeg beeld opbouwt van het volledige CS landschap. Ik blijf dan ook bij mijn stelling dat je 99,9% van de tijd geen hoogte hebt van de kwaliteit van de onderliggende closed source.

Net zo min als dat je bewering, dat open source rommelig zou zijn, op feiten gebaseerd is. Je gaat mij niet wijs maken dat je dat volledig tegen cs afgezet hebt. Om de simpele reden dat dat voor normale stervelingen niet haalbaar is.

En ik had gelezen dat je ook Bsd gebruikt. Maar dat maakt je stellingname tov open source nog niet minder ongenuanceerd.

[Anoniem: 471038]

Sorry, ik wil best veel geloven, maar niet dat je met een paar reverse engineering projecten genoeg beeld opbouwt van het volledige CS landschap. Ik blijf dan ook bij mijn stelling dat je 99,9% van de tijd geen hoogte hebt van de kwaliteit van de onderliggende closed source.

Dat beweer ik ook niet. Maar van zaken waarbij ik het belangrijk vind om te weten hoe het in elkaar zit, neem ik wel een kijkje, en daar heb ik dus wel een beeld van.

Net zo min als dat je bewering, dat open source rommelig zou zijn, op feiten gebaseerd is. Je gaat mij niet wijs maken dat je dat volledig tegen cs afgezet hebt. Om de simpele reden dat dat voor normale stervelingen niet haalbaar is.

Wederom, hierbij baseer ik me op de code waarbij ik het belangrijk genoeg vond om zelf een kijkje te nemen.
Daarnaast gaat het niet zozeer om de code an sich, maar ook meer highlevel, om bepaalde ontwerpbeslissingen, keuzen van algoritmen etc.

[pe1dnn]

En dat geld ook voor closed source. Verschil is wel dat als je iets vind, je dat bij open source kunt analyseren en repareren en bij closed source niet.

En als het oude code is, dan rest bij closed source alleen nog weggooien, want geen bedrijf steekt tijd in een oud product. In dit geval een courant stuk code maar had net zo goed wat anders kunnen zijn.

En reken er maar niet op dat elk stuk code wel grondig gereviewed word bij bedrijven, is veel te kostbaar. Bij open source is de kans juist veel groter, zeker bij projecten waar meerdere mensen aan werken. Maar nee, zeker niet alle code, en vooral niet de code die al heel lang bestaat en gewoon werkt,geen ontwikkeling meer is en dus niemand meer naar kijkt.

Ik weet wel dat bij de huidige open source ontwikkeling elke commit naar GIT wordt bekeken voordat het wordt toegelaten tot de master branch. Dit is behoorlijk strenger dan bij veel bedrijven, juist omdat er zo veel mensen aan werken.

[Anoniem: 118226]

Ook closed source zegt alleen iets over het licentiemodel.

Ik zeg nergens dat een van de twee beter is. Ik zeg juist dat je op basis van het licentiemodel geen enkele uitspraak kan doen.

De rest van je uitspraken zijn allemaal aannamens en die laat ik aan jou over.

[pe1dnn]

Ook closed source zegt alleen iets over het licentiemodel.

Zelfs dat niet eens, het zegt alleen dat je indat geval als publiek de bron code niet in kan inzien. Dat heeft nog niets met het licentie model te maken. Als Microsoft alle code van Windows zou publiceren voor gebruik voor beveiligingsonderzoek dan zou dat nog geen jota aan de Windows licentie veranderen.

Aan de andere kant als ik een public domain programma maak en iedereen het recht geef om er mee te doen wat hij/zij wil maar houd de code voor mezelf dan heeft dat ook geen invloed op de licentie.

Je kan wel in een licentie bepalen dat anderen je code mogen gebruiken of dat dat juist niet mag. Maar dat is los van de vraag of je de code openbaar maakt. Enige is natuurlijk dat als je toestemming geeft je code te gebruiken dat alleen zinvol is als het beschikbaar is...

De GNU licentie gaat nog verder en verplicht je om afgeleide code ook weer vrij te geven. Maar publiceren van code op zich zegt helemaal niets over het licentiemodel.

[Anoniem: 471038]

Als Microsoft alle code van Windows zou publiceren voor gebruik voor beveiligingsonderzoek dan zou dat nog geen jota aan de Windows licentie veranderen.

Ik denk dat je hier twee dingen door elkaar haalt:
1) De licentie op de broncode.
2) De licentie op een product.

In het geval van open source zijn de twee doorgaans dezelfde.
In het geval van Windows niet: de Windows-licentie zoals jij het noemt, bepaalt alleen wat je met Windows als (binair) product mag doen.
De source code wordt hier niet bijgeleverd, en de Windows-licentie is hierop dan ook niet van toepassing.
Er zit echter wel een 'licentie' op de source code van Windows. Sowieso valt het onder copyright. Daarnaast past Microsoft op bepaalde delen van de code bijvoorbeeld de 'shared source'-licentie toe: http://www.microsoft.com/en-us/sharedsource/default.aspx
Microsoft heeft ook allerlei sample-code in hun SDKs, en die vallen ook weer onder een bepaalde licentie. En zo zijn er vast nog veel meer licenties te noemen die op bepaalde delen van de code van Windows/Microsoft van toepassing zijn.

[eborn]

Kwaliteit kun je niet afleiden uit een enkele bug. Dit heeft te maken met het aantal bugs, de aard van de bugs en hoe lang de bugs onopgemerkt en vervolgens onopgelost blijven.

Niemand zal ontkennen dat dit een zeer serieuze bug is. En ik weet zeker dat er nog meer van deze bug rondzwerven, die mogelijk al lang bekend zijn bij specifieke instanties. Maar dan nog zegt het niets over Open Source in het algemeen.

[Anoniem: 118226]

Mijn punt is dat open source alleen iets zegt over het licentiemodel, en closed source ook.

Het zegt helemaal niets over kwaliteit, zoals maar al te vaak als voordeel van open source wordt beweerd.

[mad_max234]

Ik hoop nu dat voor iedereen eindelijk duidelijk is dat open source alleen iets zegt over het licentiemodel en niets over kwaliteit of hoeveel mensen er daadwerkelijk naar kijken om er fouten uit te halen.

Wie heeft dat dan ooit beweerd? Want open source zegt uiteraard helemaal niks over de kwaliteit van de code of wat dan ook over de code zelfs, twee totaal verschillende dingen. Iedereen met beetje kennis van wat open source is zal die twee echt niet door elkaar halen. Denk als je weet wat open source is dat je al genoeg kennis hebt om dat te bepalen lijkt me, en die andere 99% van de consumenten weten niet eens wat het inhoud laat staan dat ze het linken aan beveiliging.

[Anoniem: 118226]

Lees de thread hier op tweakers maar eens door. Er zijn er zat die bij hoog en laag beweren dan open source veiliger/beter is dan closed source (en een iets beperktere groep andersom)

[BorgMan]

Al die mensen die vroeger riepen dat je voor Mac en Linux geen firewall en virusscanner en whatsoever nodig had zullen zich nu best wel zuur voelen eh?

Als ik het zo lees is dit een probleem dat zo diep ligt, dat een complete rewrite van de code waarschijnlijk meer zou oplossen voor toekomstige apparaten dan de bug pletten (wat blijkbaar ook echt super lastig is). Voor huidige apparaten is het uiteraard broodnodig, maar voor toekomstige releases zou het misschien wel handig zijn om het dan meteen naar huidige standaarden te upgraden...

[Wwwillem]

...een virusscanner en firewall zouden niets aan dit probleem veranderen.

[Dorank]

firewall:

iptables -A INPUT -m string --algo bm --string '{:;};' -j DROP

Zelf poorten/protocollen aanpassen om fall positives te voorkomen, en de string variaties voor whitespaces om de crux toevoegen.

clamav:
Het is natuurlijk peanuts om dit aan de clamav signatures toe te voegen. Alhoewel is zo nog geen source daarvoor kan vinden.

[elmuerte]

Is dat niet heel vervelend om bijvoorbeeld deze pagina te bekijken?
Verder doet het niet veel tegen HTTPS verkeer.

[z1rconium]

Veel bedrijven gebruiken een WAF (web application firewall) die ssl traffic kan analyseren (heel kort door de bocht doet ie een MITM attack voor traffic inspection en forward het of niet, inclusief client cert).

[Dorank]

Het is geen ideale oplossing, maar slechts een proof of concept: het kan wel.

Wil je je beter beschermen zijn er betere tools, zoals een scanning proxy (squid met clamav). Hoe je ssl scanned in deze setup heeft z1rconium al uitgelegt.

[Wwwillem]

Inderdaad, nu dit bekend is kunnen virusscanners en firewalls hier pas rekening mee houden.

[Rolfie]

Een virusscanner die scripts kan analyseren, kan dit wel detecteren en onderscheppen.

Iets wat niet iets nieuw is op windows systemen. Diverse AV leveranciers hebben hier al de nodige ervaring in.

[Anoniem: 547741]

Wat wil je met de firewall, poort 22, 80 en 443 dichtgooien?

Voor de rest heb je misschien gelijk. Het is heel lastig dit te corrigeren terwijl je niets kapot wilt maken dat momenteel afhankelijk is van bash zoals het momenteel werkt. Ik vrees dat dit een langdurig proces gaat worden, maar ben blij dat het gevonden is.

[Anoniem: 471038]

Al die mensen die vroeger riepen dat je voor Mac en Linux geen firewall en virusscanner en whatsoever nodig had zullen zich nu best wel zuur voelen eh?

Ik hoop dat ze het eindelijk eens gaan inzien... Maarja, als je dat altijd al geroepen hebt, weet ik niet of een reality-check uberhaupt nog een optie is...

[Bjornmeijer935]

Hoe heeft dat hier iets mee te maken? Het gaat om een exploit in een applicatie die net zo goed in een andere besturing systeem had kunnen voorkomen. Een virus scanner gaat dit niet blokkeren, een een firewall wellicht alleen als je packet inspection doet met Snort of dergelijke. En om nu "even" een snort firewall op te zetten is denk ik voor de meeste thuisgebruikers niet weggelegd.

[rommeke]

Een firewall of scanner doet hier niets tegen. Je deamons onder een 'eigen' account draain en geen scripts onder bash laten uitvoeren wel. Volgens mij is dit ook wat de meest Linuxdistibuties doen, alleen lusers hebben bash als default shell. En even controleren of er geen link is van /bin/sh => /bin/bash

[Anoniem: 621536]

Wie roept dat dan? De linux distributies hebben standaard een firewall: iptables/nftables.

[Pietervs]

Hoera, we hebben iets gevonden om open source mee af te kraken? Want zo komt je reactie een beetje over...
Ik draai thuis al jaren Linux (en diverse soorten Windows,dualboot of stand-alone). Op alle systemen heb ik virusscanners en firewalls aan staan, om de doodsimpele reden dat geen enkel besturingssysteem echt 100% veilig is.

[BorgMan]

Het is zeker niet opensource bashen! Het gaat mij er om dat er vaak een "uit de hoogte" houding vanuit Mac en Linux gebruikers werd aangenomen richting Windows gebruikers; redelijk recent heeft Tweakers een poll online geknald met of mensen een antivirus gebruiken, waarin onder andere ook ik me afvroeg hoe het zo kon zijn dat er zoveel Linux en OSX gebruikers zijn die vrijwel niets aan antivirus, firewalls of wat dan ook deden "omdat het niet nodig was". Ik begrijp maar al te goed dat een antivirus hier vrij weinig tegen doet, maar het gaat oven om het complete plaatje, vandaar

@ de rest: er wordt al druk heen en weer gediscusseerd met hoe een firewall dit euvel kan aanpakken, dus blij toe dat het wel degelijk kan. Overigens zal ik er ook heel eerlijk bij vermelden dat ik geen firewall expert ben, maar dat ik echt in de veronderstelling was dat een firewall dergelijke zaken met redelijk gemak kon onderscheppen ALS hij goed geconfigureerd is. Dat een huis-tuin-keuken gebruiker dat niet zelf doet, a la, maar als een softwareboer een update kan pushen om de firewall er op te attenderen, dan zit het alsnog wel re-de-lijk snor wat betreft foute code; toch?

[Anoniem: 471038]

Maar het feit blijft dat er vele malen minder malware voor die systemen is. Het is de statistiek die bewijst dat ze veiliger zijn; de reden waarom ze veiliger zijn doet er niet toe.

Dat ligt eraan hoe je 'veilig' bedoelt.
Als je alleen denkt aan de kans om malware te krijgen, dan ja.
Maar er wordt vaak beweerd dat deze OSen structureel veiliger ontworpen zijn, en dat kun je zeker niet afleiden van de hoeveelheid malware (waarvan dit bash-probleem dus een voorbeeld is: het zit er al meer dan 20 jaar in, ook al is er blijkbaar nooit wijd verspreide malware geweest die er misbruik van maakte).

maar die lekken worden snel gepatched.

En dat maakt het allemaal okee?
Vind ik niet.

Om even aan te geven... Voor Windows moet ik een programma als 'SandBoxie' downloaden om zaken in een sandbox te runnen. Bij Mac zit de sandbox in het OS zelf ingebouwd.

Okee, hiermee diskwalificeer je jezelf volkomen.
Sinds IE7 draait IE namelijk standard in een 'protected mode' sandbox-omgeving, en daarnaast is er sinds IE10 ook nog een 'enhanced protected mode': http://blogs.msdn.com/b/i...ookies-metro-desktop.aspx

En ik durf te beweren dat geen enkel andere combinatie van OS/browser een dusdanig geisoleerde sandbox-omgeving heeft.
Je hebt dus geen vakkennis, en je opmerkingen over 'architectuur van Windows OS' dienen ook niet serieus genomen te worden, want wat jij beschrijft, kan met ieder OS (mits je de rechten hebt... die je dus vanuit een IE-proces niet kunt krijgen).

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[Anoniem: 616000]

Voor zij die niet weten wat BASH is:

Bash, wat staat voor Bourne Again Shell, is een shell voor POSIX-systemen en wordt onder andere gebruikt op Linux en OS X. Het is geschreven door GNU en is sterk geïnspireerd op sh (afgeleid van de eerste twee letters van shell (Engels voor omhulsel)), het opdrachtregelprogramma van Unix. De naam is een woordgrapje op de naam van de originele shell, die voluit Bourne shell heet naar de auteur (Stephen Bourne). Bourne again wordt in het Engels hetzelfde uitgesproken als born again, hetgeen wedergeboren betekent. Bash streeft 100% achterwaartse compatibiliteit met sh na.[wiki]

Het is dus een bug, die zowel Linux als OSX kan treffen.

[Reactie gewijzigd door Anoniem: 616000 op 23 juli 2024 00:10]

[z1rconium]

Correctie: Het is dus een bug, die zowel Linux als UNIX kan treffen.
OS X is een op freebsd gebaseerde UNIX versie.

[Zer0]

Het is een bug die alle systemen waar bash gebruikt wordt kan treffen. FreeBSD is bijvoorbeeld standaard niet vatbaar omdat bash niet standaard geïnstalleerd is.
Ook linux distributies die standaard geen bash maar een andere shell gebruiken zijn niet vatbaar.
WIndows systemen met cgywin geïnstalleerd zijn wel weer vatbaar.
Het is een bug in bash, niet in linux of unix.

[Maurits van Baerle]

Nitpick: OS X is gebaseerd op NeXTSTEP, niet op *BSD. Daarom zie je onder de motorkap overal de letters NS (van NextStep) opduiken in namen van libraries, api's etc. Het userland van OS X is wel afgeleid van BSD en daarom komt deze verwarring vaak voor. Apple heeft OS X inderdaad wel laten certificeren als UNIX.

Hoewel Apple een kwetsbare versie van Bash meelevert met OS X maken de services van OS X zelf geen gebruik van Bash en zijn gewone gebruikers dus niet kwetsbaar. Dat verandert echter zodra mensen zelf bijvoorbeeld dingen gaan porten van Linux die verwachten dat er een werkende Bash op het systeem staat. Als je dus zelf dingen met MacPorts hebt geinstalleerd is het wel handig om zelf even die Bash versie te updaten.

[pe1dnn]

Semantiek. Next Step os weer gebaseerd op BSD Unix dus indirect toch weer wel een afgeleide van BSD. Alleen de kernel is echt anders want is afgeleid van de Mach kernel, maar bash is gewoon een applicatie en komt dus gewoon bij BSD vandaan.

Overigens de native shell van Berkeley Unix was csh (C shell), AT&T System V gebruikte sh. Bash komt niet van de oorspronkelijke Unix, alle bash versies komen van dezelfde oorsprong.

Andere shells zijn nog ksh (ook bourne shell tachtig), ash (a shell...) en tsh. Maar bash is de winnaar omdat die gewoon overal op staat.

[Anoniem: 471038]

Correctie: Het is dus een bug die alle OSen kan treffen die bash als shell gebruiken.
Je kunt bash namelijk ook bv op Windows draaien, via Cygwin of Msys.

[wankel]

Voor zij die niet weten wat BASH is:

[...]

Het is dus een bug, die zowel Linux als OSX kan treffen.

De tekst is beschikbaar onder de licentie Creative Commons Naamsvermelding/Gelijk delen, er kunnen aanvullende voorwaarden van toepassing zijn. Zie de gebruiksvoorwaarden voor meer informatie.

[RoestVrijStaal]

Het grootste probleem is dat verouderde syntax nog steeds masaal gebruikt wordt.

Zoals het verouderde:
currentMoment=`date +%Y-%m-%d_%H%M`
i.p.v. het tegenwoordig aanbevolen:
currentMoment=$(date +%Y-%m-%d_%H%M)
Om een resultaat van een commando in een variabele op te slaan.

Heck, die Norihiro Tanaka van het vorige artikel maakt ook nog gebruik van backticks.

Het wordt tijd dat ieder die een *nix-shell heeft/gebruikt kennis neemt van correcte syntax. http://wiki.bash-hackers.org/scripting/obsolete

[blorf]

Dat heb ik ook nooit begrepen, ben in het begin van mijn *nix gebruik gelijk die dollartekens gaan gebruiken. Beter leesbaar en beter bereikbaar op het toetsenbord. Ook het enkele aanhalingsteken alleen gebruiken bij 'single-character' waarden lijkt me een goeie.

Maar ja, zet je met een webserver die via zijn CGI een shell + lokale binutils uitvoert als child-processen met dezelfde ge-erfde permissies niet gewoon een deur open?
Als je hetzelfde doet met Perl, Python of C heb je dat probleem niet. (Als je tenminste niet vanuit die code alsnog systeemcommando's uitvoert waarbij je blind parameters doorgeeft)
Het verhaal wordt nogal opgeblazen naar mijn idee. Als security van belang is lijkt het me wel handig om op te sommen wat je webserver allemaal moet mogen. Als daar de hele inhoud van je /usr/bin en /usr/sbin met execute attribuut bij staat moet er volgens mij wel een belletje gaan rinkelen.

[Reactie gewijzigd door blorf op 23 juli 2024 00:10]

[CAPSLOCK2000]

Dat heb ik ook nooit begrepen, ben in het begin van mijn *nix gebruik gelijk die dollartekens gaan gebruiken. Beter leesbaar en beter bereikbaar op het toetsenbord.

Vroeger, lang geleden, was er alleen de backtick-notatie en gewoontes die eenmaal in ingesleten veranderen maar moeilijk. Ik ben zelf van na de nieuwe syntax en gebruik dus bijna altijd de dollarteken-syntax, maar niet altijd. Ik vind de backtick juist makkelijker bereikbaar. De backtick is een enkele toets op de hoek van je toetsenbord. Voor de $() syntax heb je drie keer de shift nodig en drie tekens midden in de rij. In oneliners gebruik ik dus wel eens de backtick.
Het is lui en in scripts zal ik het niet snel doen, maar in losse commando's is het wel makkelijk.

Ook het enkele aanhalingsteken alleen gebruiken bij 'single-character' waarden lijkt me een goeie.

Pas op, enkele aanhalingstekens hebben een andere dan dubbele:
ABC=123 echo 'hoi $ABC'
hoi $ABC

ABC=123 echo "hoi $ABC"
hoi 123

Je hebt ze allebij nodig.

[blorf]

Gewoon preventief escapen. Is gelijk mooi duidelijk te zien dat het om $ als karakter gaat en niet om een variabele-naam en je weet zeker dat het niet om een of andere reden toch zo wordt geiterpreteerd door de shell.

echo "hoi \$ABC"

weer te overriden met

eval echo "hoi \$ABC"

[eborn]

De enige manier om dit soort dingen definitief de wereld uit te helpen is om het uit te schakelen. Natuurlijk, het kost gigantisch veel werk om alles na te lopen. En er zal veel kapot gaan. Maar soms moet je door die harde pil bijten om verder te komen.

[Dorank]

Er zijn nog andere omgevingen dan sh waar backticks gebruikt worden voor het uitvoeren van commandos. bv perl.
Als je deze syntax al 20 jaar gebruikt is dat zeer lastig af te leren.

[ReneX]

Voor een deel heeft dat te maken met oude scripts (en bij elke update vind er vaak een copy/paste plaats zonder na te denken of de code die er staat eigenlijk wel goed was en is).

[Wim-Bart]

Stelling: Het op het moment implementeren en live houden van Linux systemen is een bedrijfs risico.

Reden: Door de laksheid van de community en het niet goed controleren van de source code maakt het mogelijk dat er meer van dit soort basale fouten aanwezig zijn. Het is afwachten in hoe verre hackers wel in de code duiken op zoek naar dergelijke fouten en deze vinden voordat de community sit doet. Linux is pas weer veilig tot iedere regel code meerdere malen is gecontroleerd door mensen met verschillende inzichten en is aangepast. Te beginnen met legacy code vanaf dag 1. Zolang dit niet wordt gedaan is Linux gewoonweg gevaarlijk.

[Mijzelf]

Ik denk dat je beter je computer gewoon uit kunt zetten. Bash draait op alle Unixen en afgeleiden, zoals OSX, Solaris en *BSD, op Linux, op Haiku, en zelfs op Windows.

OK, het draait niet standaard op al die operating systemen, maar het draait ook niet standaard op de meest voorkomende Linux systemen, nl. routers.

Als ik erover nadenk zou ik geen enkele binary weten die gegarandeerd op ieder Linux systeem zit, op de kernel zelf na dan.

Die kernel is trouwens ongeveer 20 miljoen regels code, en dat wordt dan een binary van 2~7 MB. Oftewel 3~10 regels code voor iedere byte binary. Als je dat kunt extrapoleren, dan vertegenwoordigt een Linux Live CD'tje van 700MB dus 2~7 miljard regels code.
Daarbij moet je nog rekening mee houden dat die 700MB zwaar gecomprimeerd is, dus mogelijk moet je nog met 2 keer zoveel regels rekening houden.

[Reactie gewijzigd door Mijzelf op 23 juli 2024 00:10]

[Wim-Bart]

Inderdaad, het is een ondoenlijke klus. Alleen zijn er genoeg gekken die het wel doen, alleen zonder ons te delen.

Het probleem zit er in dat er een soort schijnveiligheid is rond open source waarbij vaak wordt geschermd met het feit dat het veiliger is doordat de code voor een ieder inzichtelijk is.

Wat met name uit deze situatie blijkt is dat zelfs de originele makers niet eens meer kunnen achterhalen wanneer de bug er in is gekomen, en dat zelfs na 2 patches het probleem niet verholpen is en er zelfs een keten van andere bugs naar voren komt.

Beangstigend is tevens dat heel veel professionele bedrijven, in dit geval bash, hebben overgenomen zonder het blijkbaar te controleren. En ik vraag mij af, in hoeverre er nog meer naar boven komt. Tevens hoe snel de patches ook zijn, er blijven dus miljoenen devices online met deze bug zond er ooit gepatched te worden omdat er gewoon geen updates voor komen, het product commercieel EOL is of om wat voor reden dan ook.

Zolang de mens software maakt zullen er fouten in zitten en moeten we er mee leren leven maar ik betwijfel of we, met de kennis van nu veel legacy spul in leven moeten houden en niet gewoon zaken moeten afschrijven. Bijvoorbeeld, schrijf bash af met een veiliger alternatief, of haal er functionaliteit uit. Dat er andere zaken omvallen is geen probleem, misschien moeten die ook terug naar de tekentafel. En hoe veel spul valt er na deze patches niet al om.

Ik wil niet zeggen dat uxen zuigen, maar ik denk dat de oss gemeenschap eens bij zichzelf te rade moet gaan en moet leren dat vooruitgang ook wel eens kan komen uit oude paden verlaten, oude huizen vervangen door nieuwe et cetera.

[Dorank]

Het probleem zit er in dat er een soort schijnveiligheid is rond open source waarbij vaak wordt geschermd met het feit dat het veiliger is doordat de code voor een ieder inzichtelijk is.

Maar het alternatief is dat je de code niet kan inzien (closed source), iets wat zeker onveiliger is (niemand kan de code namelijk auditen). Verder is er weinig verschil, overal worden fouten gemaakt/geintroduceerd, gevonden (met of zonder source) en misbruikt (met of zonder code). Het verschil dat er is dat potentieel wel een fix gemaakt kan worden door derden met open sourced code.

BTW ik moet helaas de hele dag met open source code werken. Als er een probleem gevonden wordt, wordt er van mij verwacht dat ik het probleem gefixed krijg. Dat houd meestal in dat ik:
-de bug rapporteer
-op onderzoek uitga om de fout te localiseren
-indien ik voldoende verstand heb van het probleem en code een Q&D fix maak
-dat aan het bugreport hang en de daadwerkelijk developers de boel netjes laat fixen

Closed source software is voor mij veel makkelijke, als er een probleem is:
-raporteer de bug
-meldt iedereen dat er een bug is en dat ze pech hebben als ze er tegen aan lopen

[Anoniem: 471038]

iets wat zeker onveiliger is (niemand kan de code namelijk auditen).

Dat is niet waar natuurlijk.
Ten eerste zien de mensen die aan de code werken de code wel in natuurlijk. Interne audits zijn vrij normal bij professionele bedrijven (ISO 9001 normen en dat soort dingen).
Ten tweede zijn er ook bedrijven die een third-party inhuren voor een externe security-audit.
Het zou me niet verbazen als er in de praktijk meer/beter/kritischer naar belangrijke closed source code wordt gekeken dan naar open source.

[Anoniem: 125509]

Probeer je nu met deze bewering bedrijven als bijv IBM, Novell, Red Hat en Oracle neer te zetten als 'niet professionele' bedrijven?

Denk je werkelijk dat deze bedrijven denken dat, omdat het open source is, ze de pakketten die ze neerzetten bij grote bedrijven niet zorgvuldig hoeven te reviewen?

Er zijn hele grote bedrijven die open source gebruiken, een aantal daarvan hebben het zelfs redelijk als kern activiteit. Open source in het hoekje van hobby product duwen, omdat het dat is op de desktop is, doet weinig recht aan het product als geheel.

Het zou me niet verbazen...

Mij wel. Bij closed source wordt op zijn best maar door 1 bedrijf een third-party ingehuurd voor een security-audit op de source. Ik zeg niet dat het bij open source vaker gebeurt, maar ook niet minder vaak.

In zowel open als closed source zit oud zeer. Omdat je bij open source dat toevallig ook zelf kunt vast stellen maakt het niks meer of minder dan closed source.

[Anoniem: 471038]

Probeer je nu met deze bewering bedrijven als bijv IBM, Novell, Red Hat en Oracle neer te zetten als 'niet professionele' bedrijven?

Nee, maar leuk dat jij dat er denkt uit te halen.

Denk je werkelijk dat deze bedrijven denken dat, omdat het open source is, ze de pakketten die ze neerzetten bij grote bedrijven niet zorgvuldig hoeven te reviewen?

Zeer zeker niet. Zoals ik op mijn blog destijds ook zei... de heartbleed-bug werd juist via Red Hat ontdekt, omdat zij een security-audit deden op de code.
Dus grote bedrijven doen zelfs bij open source security-audits.
Het punt is vooral dat de bug blijkbaar niet gevonden was door vrijwilligers.

Omdat je bij open source dat toevallig ook zelf kunt vast stellen maakt het niks meer of minder dan closed source.

Hier ben ik het niet mee eens. Omdat iedereen denkt "Er zullen wel mensen naar kijken", kijken ze er zelf niet naar. En dan komt het er dus op neer, zoals hier bij bash, dat er bugs in zitten die meer dan 20 jaar onontdekt blijven.
Dat maakt het bij open source dus minder. Bij closed source WEET je wie er wel of niet naar kijkt. En dus WEET je dat het handig is om af en toe een security-audit te doen.

Gelukkig zijn bedrijven als Red Hat zo slim om dat bij open source ook te doen. Ik vraag me alleen af... Doen ze dat alleen bij dingen als SSL, waarbij het vrij voor de hand ligt dat de code veilig moet zijn? Of nemen ze andere code ook mee, zoals bash?

[Anoniem: 125509]

Omdat iedereen denkt "Er zullen wel mensen naar kijken", kijken ze er zelf niet naar. En dan komt het er dus op neer, zoals hier bij bash, dat er bugs in zitten die meer dan 20 jaar onontdekt blijven.

Maar hoe verschilt open source hier met closed source? Ook daar doe je die aanname en komen soms oude bug boven.

[Reactie gewijzigd door Anoniem: 125509 op 23 juli 2024 00:10]

[Anoniem: 471038]

Maar hoe verschilt open source hier met closed source? Ook daar doe je die aanname en komen soms oude bug boven.

Zoals ik al aangaf, bedrijven die bv aan de ISO 9001-norm willen voldoen, zijn verplicht om hun code te auditen, en dit te documenteren. We hebben het dus niet over een aanname. Je *weet* dat het gebeurt, want je bent verplicht dit regelmatig in te plannen, en om dit te registreren.

Ik heb nog nooit gehoord van een open source-project dat aan de ISO 9001-norm voldoet.

[Reactie gewijzigd door Anoniem: 471038 op 23 juli 2024 00:10]

[r_j]

In de tijd dat ik bij AT&T zat stond alle code gewoon op alle systemen (met uitzondering van de kernel van system V).

[Mijzelf]

Beangstigend is tevens dat heel veel professionele bedrijven, in dit geval bash, hebben overgenomen zonder het blijkbaar te controleren.

Ik heb het even voor je geteld, bash 4.3 heeft 150000 regels code, alleen de .c en .h files.
Dus zonder build scripts, makefiles en de rest. De totale tar file bevat 681373 regels.

Als je dat wilt gaan controleren kun je beter direct iets anders schrijven. Alleen vervang je dan iets wat al decaden overeind is gebleven door iets nieuws, met nieuwe bugs, en nieuwe problemen.

150000 regels zal al snel 5 tot 10 manjaar werk zijn, oftewel, je gooit een half tot een heel miljoen het raam uit als je het gaat herschrijven. En dat is dan alleen nog maar een shell.

[r_j]

Kunnen we dan niet beter overstappen op ksh? Wellicht kan David Korn hier een licht op laten schijnen.

[Mijzelf]

Wie is we? Debian en Ubuntu gebruiken geen bash als default shell voor services, *BSD ook niet. Embedded Linux devices niet. Ik weet het niet voor Red Hat en Suze en vrienden.

Als alle unix achtigen zouden overstappen op een bepaalde shell, ben je een monocultuur aan het bouwen, die kwetsbaarder is dan de huidige situatie.

De huidige situatie is dat bash op veel systemen aanwezig is, en vatbaar is voor dit probleem, maar aangezien bash verder niet gebruikt wordt, is de impact 0.

[Anoniem: 471038]

Als alle unix achtigen zouden overstappen op een bepaalde shell, ben je een monocultuur aan het bouwen, die kwetsbaarder is dan de huidige situatie.

Dit argument klinkt wel een beetje als 'security through obscurity'.
Volgens die logica zou je zeggen dat het niet uit zou moeten maken als iedereen hetzelfde gebruikt, zolang de security maar op peil is.

[Mijzelf]

Ik zou het liever risicospreiding noemen.

Wanneer is de security op peil? Voor zover ik kan overzien is er in feite niets mis met bash. Hij gaat op een bepaalde manier om met environment variabelen, dat is gedocumenteerd en prima.

Het gaat alleen mis als bash wordt aangeroepen vanuit een ander programma die environment variabelen zet die van buitenaf kunnen worden gemanipuleerd, zoals het geval kan zijn met httpd en sshd.

Terwijl er niets mis is met CGI, en ook niets mis is met bash, is de combinatie een probleem. Dat maakt security lastig in te schatten. Vandaar de risicospreiding.

[Anoniem: 471038]

Voor zover ik kan overzien is er in feite niets mis met bash. Hij gaat op een bepaalde manier om met environment variabelen, dat is gedocumenteerd en prima.

Daar ben ik het niet mee eens.
Ik zie uberhaupt het nut niet zo in van deze functionaliteit. En aangezien deze functionaliteit dus uitgebuit kan worden, moet je jezelf eens heel kritisch gaan afvragen of deze functionaliteit uberhaupt wel aanwezig had moeten zijn, en zo ja, of er geen maatregelen getroffen kunnen worden om toch misbruik tegen te gaan.

Terwijl er niets mis is met CGI, en ook niets mis is met bash, is de combinatie een probleem. Dat maakt security lastig in te schatten.

Dit is de normale gang van zaken bij security-problemen: hackers zijn zeer creatief, en vinden manieren om (combinaties van) software uit te buiten waar de ontwikkelaar nooit aan gedacht had (denk bv ook aan bugs in Flash/Java/etc waarbij iemand via een website toegang tot jouw systeem kan krijgen). Les 1 in security is dan ook om te leren te denken als een hacker.

[WhatsappHack]

Maar wat stel je dan voor om te draaien? FreeBSD/openBSD? Windows?

De eerste twee zijn ook community projects, die laatste is duur, ook zat risico's mee, resource hog en lang niet alle software is er compatible mee.
Zo heeft alles wel z'n problemen, als administrator speel je daar op in. Ondoenlijk is t absoluut niet, en een risico...? Tja, elk systeem met gevoelige info die op t net aangesloten staat is een risico, ongeacht software. En is t de server niet, dan exploiten ze wellicht je router een keer als daar een gigantisch gat in gevonden wordt. Altijd wel iets wat KAN gebeuren, het belangrijkste is de risicos minimaliseren...

[Wim-Bart]

Er zijn geen alternatieven, ieder OS heeft zo zijn nukken en problemen. Het is echter hoe we er mee om gaan. Veel wordt gezegd, we blijven bij dit want we willen niets veranderen uit angst dat zaken omvallen. Maar helaas, dan blijven we legacy spul overeind houden welke heden ten dage misschien niet meer voldoet. Net zoals die bedrijven die nog steeds XP in de lucht houden omdat hun leverancier niet mee wil werken. F$#k die leverancier, voor hem 10 anderen. Misschien kost het meer, maar niets en niemand is onvervangbaar in deze wereld. Zelfs hoog gespecialiseerde software is door anderen te bouwen.

En hoe veel tijdbommen liggen er niet te wachten door dit gedrag. Ook al zo een leuke "if it aint broken, don't fix it". Probleem is, misschien was met re factoring dit al lang gefixed geweest, want het was jaren "niet kapot" maar helaas, jaren liggen dus alle systemen open en bloot.

Kortom, mensen moeten beseffen dat heilige huisjes soms eens omver getrapt moeten worden en dat niet alles is zoals het lijkt. Ook nu blijkt gewoonweg weer, vertrouwen in iets wat altijd werkt is leuk, maar totaal misplaatst.

[grep]

ja, want nieuwer is altijd beter?
Zijn ook genoeg voorbeelden dat je ongepatcht niet vulnerable was (pas vulnerable vanaf versie x.xx)
Zo zwart-wit is het niet.

[Silmarunya]

Stelling: ondanks het enorme aantal servers en andere grote installaties dat draait op Linux en de relatief rommelige code zijn meldingen van real-world exploits uiterst zeldzaam.

Reden: problemen met Linux worden dan wel regelmatig gevonden, maar meestal ook snel gepatcht. Bovendien vereisen de meeste recente exploits ofwel fysieke toegang tot het systeem, ofwel een incompetente of onoplettende systeembeheerder - en beide zijn relatief eenvoudig te vermijden

Absolute veiligheid bestaat niet. De vraag die men zich moet stellen is of de beschikbare alternatieven wezenlijk veiliger zijn. Het antwoord daarop? Geen idee, dat is eigenlijk nooit echt objectief getest. Feit is wel dat alle momenteel courante besturingssystemen kwetsbaarheden hebben en de allergrootste kwetsbaarheid van allemaal - de gebruiker - platformonafhankelijk is.

[Reactie gewijzigd door Silmarunya op 23 juli 2024 00:10]

[BuzzardHawk]

Hoe kan de gewone consument zich hier tegen beschermen? Hij heeft web cameras, een Wifi router en een NAS.
Wachten op firmware? Ik denk dat 99% niet eens weet wat.firmware is.

[Soldaatje]

Al die zooi niet direct aan het net hangen helpt al een hoop...

[rommeke]

De meeste embedded systemen gebruiken een andere (veel kleinere) shell dan bash en zover ik uit de tekst kan opmaken is deze kwetsbaarheid alleen van toepassing op bash.

[eborn]

Niet. Ga er maar vanuit dat er heel veel devices online blijven met een oudere bash die kwetsbaar is. Of het device vervolgens zelf ook kwetsbaar is, hangt natuurlijk van veel factoren af. Maar er zullen er genoeg overblijven die in het beste geval als bot ingezet gaan worden.