Microsoft en Cisco patchen tcp-lek

Een aantal fabrikanten heeft patches uitgebracht voor een kwetsbaarheid in het tcp-protocol, dat kan worden misbruikt voor een DoS-aanval. Het lek, dat al een jaar bekend is, kan onder meer worden gebruikt om Vista-machines over te nemen.

Microsoft en Cisco hebben patches voor een lek in de implementatie van het tcp-protocol uitgebracht. Het lek zou het mogelijk maken om met speciaal geconstrueerde packets een denial of service-aanval uit te voeren. Voor de aanval zou zeer weinig bandbreedte vereist zijn.

Volgens Cisco is er nog geen malware gesignaleerd die het lek misbruikt; er is wel een exploit, maar die is niet publiek gemaakt. Wel is het bestaan van het lek al bijna een jaar bekend. Het lek berust op het uitputten van systeembronnen door een reeks connecties open te houden. Er is wel een drieweg-handshake nodig om het lek te misbruiken, waardoor het voor een aanvaller lastig is om zijn ip-adres te spoofen.

Microsoft meldt dat het lek op bepaalde besturingssystemen, waaronder Windows Vista en Windows Server 2008 R1, kan worden gebruikt om op afstand code uit te voeren, zodat een machine kan worden overgenomen. Windows 7, Windows Server 2008 R2 en Windows XP met SP2 of SP3 hebben geen last van het lek. Gebruikers van Windows 2000 SP4 zijn wel kwetsbaar, maar voor hen wordt geen patch gepubliceerd: om het probleem op te lossen zou de architectuur van een deel van het OS zodanig moeten worden gewijzigd dat het onzeker is of applicaties blijven werken, zegt Microsoft.

Cisco rept niet over remote code execution. Routers die de kwetsbare Cisco-software draaien, kunnen als gevolg van een aanval wel nieuwe tcp/ip-connecties weigeren, waardoor ze opnieuw moeten worden opgestart. Oudere versies van Linux en BSD zijn overigens ook kwetsbaar; het lek is in de recentste kernels echter al gedicht. Redhat heeft bij wijze van workaround voor gebruikers van oudere kernels wel een klein firewall-scriptje online gezet.

Reacties (99)

[gertvdijk]

Oudere versies van Linux en BSD zijn overigens ook kwetsbaar; het lek is in de recentste kernels echter al gedicht.

In de CVE zie ik niets na 2.6.24 dat kwetsbaar is. Als dit waar is - aangezien 2.6.25 al sinds april 2008 (!) uit is vind ik dit toch weer eens een mooi voorbeeld van dat issues in de open source community gewoon veel sneller worden verholpen/aangepakt. Jammer dat de commerciële dit soort dingen zo lang laten liggen of dat het ze zichzelf zo moeilijk maken dit soort dingen te fixen...

In het artikel vind ik dit aspect dan ook aardig onderbelicht. Linux heeft in de servermarkt een groot aandeel en de toepassing van dit lek heeft voornamelijk betrekking op servers (platleggen).

[Reactie gewijzigd door gertvdijk op 23 juli 2024 14:25]

[Verwijderd]

het wordt opgepakt als iemand er toevallig zin in heeft in de opensource wereld... imposante problemen... of leuke gui's hebben natuurlijk veel meer kans om opgelost te worden dan kleine problemen of bijvoorbeeld documentatie... terwijl dat natuurlijk ook essencieel is voor heb beheer. ik meen me in het verleden berichten gelezen te hebben dat die dingen structureel niet gedaan werden of niet voldoende

open source sneller... miss maar zonder enige vorm van zekerheid immers je kan niemand dwingen om eraan te werken. je kan ook niemand dwingen om het grondig te controleren. ik heb vertrouwen in een samenwerkings verband tussen cisco en microsoft dat het probleem nu ook echt is opgelost...

ook vraag ik me af als microsoft nou sneller was geweest het omgekeerde beweerd zou worden...

ik denk het niet

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

het wordt opgepakt als iemand er toevallig zin in heeft in de opensource wereld... imposante problemen...

Zo werkt de open source wereld niet. Het zijn professionele bedrijven zoals RedHAT of IBM die de kernel mede onderhouden. Men heeft dezelfde economische drijfveren als in de "closed source wereld"

[Verwijderd]

gertvdijk zei toch duidelijk dat het zou gaan OM NIET commercieele partijen... IBM REDHAT en oracle zijn commercieele partijen.

dus... zijn commercieele bedrijven nu altijd slecht... of zijn ze nou altijd goed

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[gertvdijk]

gertvdijk zei toch duidelijk dat het zou gaan OM NIET commercieele partijen... IBM REDHAT en oracle zijn commercieele partijen.

Wat ik bedoelde was natuurlijk commerciële, gesloten, non-community-based software, zoals Microsofts' producten. Grote bedrijven die bijdragen leveren aan de open source community of de software opnieuw verspreiden vallen daar niet onder, aangezien zij voor een groot deel wel community-driven of -based zijn.
Closed-source commerciële software is lang niet altijd slecht, maar in dit opzicht (security problemen aanpakken) gewoon inferieur, imo. Dat is en was mijn punt.

[Reactie gewijzigd door gertvdijk op 23 juli 2024 14:25]

[Verwijderd]

gezien het artikel zegt dat er eigenlijk geen misbruik van gemaakt is...

is het dus nog steeds gewoon op tijd...

miss een kwestie van prioriteitstelling?

[watercoolertje]

Dat dacht ik ook, wat boeit mij het nou dat dat gat er zit als ze mij uit die miljard PC's uitkiezen om als eerste te grazen te nemen met een nieuw lek, so be it In de woestijn kijk je ook niet elke stap of er een auto aan komt, die zijn er simpelweg bijna niet te vinden

[LollieStick]

In de woestijn kijk ik wel elke stap of ik ergens een watercooler zie

[demonite]

suc6, heb je veel aan zonder water..

[cariolive23]

het wordt opgepakt als iemand er toevallig zin in heeft in de opensource wereld

Dat zal voor vrijwillige bijdrages zeker gelden, maar er zijn ook genoeg programmeurs die worden betaald om bugs te fixen. Bedrijven zoals bv. RedHat, Oracle, IBM, etc. leveren tenslotte ook hun bijdrages aan Linux.

Daarnaast is april 2008 (Linux) en september 2009 (Microsoft) wel een zeer groot verschil. In deze 16 maanden zouden dus heel wat mensen toevallig zin kunnen hebben gehad om het lek te dichten, dat was voor Linux alleen niet meer nodig. Het lek was al gedicht.

[himlims_]

grote/complexe problemen worden veelal behandeld/opgelost door de grotere jongens (ibm bijv.) en krijgen deze 'toegewezen' door het team wat de kernel beheerd

[Verwijderd]

dus even zonder gekheid... opensource comunity de heilige bescherming tegen de macht van enge comercieele bedrijven (om het zo maar even te brengen)

kan niet zonder die zelfde commercieele bedrijven die het echt niet doen uit liefdadigheid.

laten we wel zijn... novel... heeft jaren echt de hoofdprijs laten betalen... met een paar honderd gulden per 25 gebruikers licentie rechten

ook ibm heeft tot voor een paar jaar geleden enorme bedragen gevraagt voor simple unix servertjes...

de laatste keer dat ik een prijslijst van redhat zag viel het me op dat een licentie duurder was dan een xp prof licentie in de winkel... miss is dat een vertekend beeld vanwege extra's die je erbij kreeg...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

dus even zonder gekheid... opensource comunity de heilige bescherming tegen de macht van enge comercieele bedrijven (om het zo maar even te brengen)

Open source en commercieel zijn geen tegenstelling, ik snap niet zo goed waarom dit steeds in die context wordt getrokken.

[Verwijderd]

de laatste keer dat ik een prijslijst van redhat zag viel het me op dat een licentie duurder was dan een xp prof licentie in de winkel... miss is dat een vertekend beeld vanwege extra's die je erbij kreeg...

Heb je ook de voorwaarden van de licentie gelezen?
1. Je hebt de mogelijkheid om een gratis alternatief te gebruiken. (zonder betaalde licentie)
2. Bij de licentie zit al support.
3. Je hoeft maar 1 licentie te kopen voor je volledige serverpark.

EN opensource <> gratis
het zegt enkel dat je de broncode meegeleverd krijgt en je die vrij kan gebruiken. (of zelfs bijvoorbeeld doorgeven, meerdere malen opnieuw gebruiken, etc.) Niettegenstaande veel programma's wel gratis zijn.

Of anders gezegd: het draait in deze gemeenschap dan ook vooral om de uren die gepresteerd worden (vooral bij support) en niet om reeds gepresteerde uren die reeds opgebracht hebben en opnieuw moeten opbrengen.

Je kan het een beetje vergelijken met de IKEA (closed source) en de schrijnwerker (opensource). Beide ga je betalen. In de IKEA betaal je een vaste prijs voor een pakket, de schrijnwerker betaal je zijn uren en het materiaal.

[kozue]

het wordt opgepakt als iemand er toevallig zin in heeft in de opensource wereld... imposante problemen... of leuke gui's hebben natuurlijk veel meer kans om opgelost te worden dan kleine problemen of bijvoorbeeld documentatie... terwijl dat natuurlijk ook essencieel is voor heb beheer. ik meen me in het verleden berichten gelezen te hebben dat die dingen structureel niet gedaan werden of niet voldoende

Behalve dat het natuurlijk onzin is wat je uitkraamt, zoals hierboven al eerder gezegt, is het ook nog eens onterecht om dit soort gedachten te associëren met open source. Hoe denk je dat programmeurs bij MS denken? Die zullen het ook veel leuker vinden om een flashy gui te maken dan naar mogelijke lekken in de kernel te gaan zitten spitten.
Bij MS is echter "geen zin" niet de drijfveer, maar meer "geen geld voor over", aangezien ze daar alleen iets fixen als het een economisch voordeel oplevert.
En uhm, jij noemt het ontbreken van documentatie op, terwijl MS nog nooit vrijwillig documentatie heeft geschreven? Alle documentatie die MS ooit gemaakt heeft, is ontstaan omdat ze moesten (door antitrust regels), of om hun monopolie te versterken (.NET, silverlight, ooxml, etc)

open source sneller... miss maar zonder enige vorm van zekerheid immers je kan niemand dwingen om eraan te werken. je kan ook niemand dwingen om het grondig te controleren. ik heb vertrouwen in een samenwerkings verband tussen cisco en microsoft dat het probleem nu ook echt is opgelost...

Wow, jij hebt een bord voor je kop zeg. Na al die mislukte patches van MS die meer problemen introduceerden dan ze oplosten heb jij nog steeds vertrouwen dat het op is gelost? Ben je al weer vergeten hoe ze zaten te stuntelen met een lek in IE7, die na de patch nog steeds lek bleek te zijn en 1 of 2 nieuwe problemen veroorzaakte, zodat ze weer met een nieuwe patch moesten komen, die ook niet goed werkte?
En btw, ik lees hier nergens iets over een samenwerkingsverband. Voor zover ik dit probleem begrijp is het een universeel tcp probleem en hebben de patches van cisco en MS totaal niks met elkaar te maken.

ook vraag ik me af als microsoft nou sneller was geweest het omgekeerde beweerd zou worden...

ik denk het niet

Natuurlijk niet. MS heeft geen betrouwbaar track record op het gebied van beveiliging en patches. De open source community lost beveiligings lekken snel en goed op, MS wacht liever op de eerstkomende patchdag om een halfwerkende patch uit te brengen. Als ze dan toevallig een keer sneller zouden zijn, is het een uitzondering op een regel, en gaat heus niemand ze op zitten hemelen hoor.

[Verwijderd]

zonder enige vorm van zekerheid immers je kan niemand dwingen om eraan te werken. je kan ook niemand dwingen om het grondig te controleren.

zoals verschillende bedrijven WEL doen:
Als je zelf niet in staat bent om het na te gaan, kan je altijd een programmeur inhuren ...

Het blijft een feit dat het probleem:
1. Reeds geruime tijd gepached is.
2. Er op andere OS'ses nooit een gevaar geweest is om code uit te voeren.

[Verwijderd]

In de CVE zie ik niets na 2.6.24 dat kwetsbaar is. Als dit waar is - aangezien 2.6.25 al sinds april 2008 (!) uit is vind ik dit toch weer eens een mooi voorbeeld van dat issues in de open source community gewoon veel sneller worden verholpen/aangepakt. Jammer dat de commerciële dit soort dingen zo lang laten liggen of dat het ze zichzelf zo moeilijk maken dit soort dingen te fixen...

Nadeeltje alleen is dat distro's gebaseerd op die oudere kernels dus niet worden geupdate en oude windows versies wel.
Dus met een up to date RHEL van vorig jaar heb je wel nog dit probleem maar met een 6 jaar oude windows server versie krijg je wel een security update.

[elmuerte]

Dat is niet waar. Je RHEL van vorig jaar heeft al lang een security update gehad voor deze patch. In de FOSS wereld worden patches over het algemeen gebackport naar de release van de software die in de distro zit. Dit om er voor te zorgen dat er niks anders veranderd. Dus jou RHEL die misschien een 2.6.20 kernel had krijgt gewoon die security patch, en heet dan 2.6.20-1 (oid). Zo lang een bepaalde distro release gesupport wordt met security patches zullen er security patches uitgebracht worden.

Bij Debian worden oude releases 1 jaar nadat de volgende stable release ondersteund met security patches. Dus, de huidige old-stable "etch" word nog 1 jaar nadat de huidige testing "squeeze" stable word, ondersteund (ergens in 2010, dus +- 3 jaar security support gehad).
Bij Ubuntu heb je 3~5 jaar lang security updates voor de Ubuntu LTS releases.
RedHat geeft voor de major RHEL releases ongeveer 7 jaar security support. RHEL 3, uit october 2003, krijgt nog security updates to october 2010. De laatste RHEL release is 5, uit 2007. Zie: http://www.redhat.com/security/updates/errata/

[Reactie gewijzigd door elmuerte op 23 juli 2024 14:25]

[Verwijderd]

Dat is niet waar. Je RHEL van vorig jaar heeft al lang een security update gehad voor deze patch. In de FOSS wereld worden patches over het algemeen gebackport naar de release van de software die in de distro zit.

Nee, wat jij zegt is niet waar.
RedHat zegt in CVE-4609

Due to upstreams decision not to release updates, Red Hat do not plan to release updates to resolve these issues

Alle RH producten gebaseerd op kernels voor 2.6.24 blijven dus sowieso kwetsbaar.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Nee dat klopt niet, RedHAT producten gebaseerd op een bepaalde kernel versie kunnen meestal gewoon goed functioneren op een latere kernel, en zijn dus niet kwetsbaar. Het is alleen zo dat RedHAT de kernel 2.6.24 niet meer zal repareren, maar dat staat los van functioneren van de producten. Dat laatste heeft met API/library-calls te maken, en dan moet je toch echt in detail uitleggen wat je bedoelt, welke API/library-calls wel functioneren onder 2.6.24 maar niet meer functioneren onder 2.6.25

Ik ben benieuwd naar meer informatie.

[Verwijderd]

Jij suggeeert nu dat enterprise klanten zelf maar even een nieuwe kernel in hun RHEL moeten inbouwen omdat RH de door hen in RHEL standaard mee geleverde kernels van voor 2.6.24 niet gaat patchen ?

Ik denk niet dat dat een populaire methode van werken gaat worden.
Ik denk ook niet dat RH nog support geeft op zelf gehackte/omgebouwde versies van hun producten.

[Verwijderd]

Je denkt dat enterprise klanten nooit een kernel updaten omdat er een issue is in een vorige versie? Dit gebeurt vaker dan je denkt, en met steun van de distributeur.
En soms verspringt ook het versie nummer.

Zolang de API/librarie-calls uit de vorige versie maar aanwezig zijn mag er eigenlijk geen probleem optreden

Zelf heb ik op mijn Linux-servers alleen dit jaar al enkele malen (twee maal, drie maal?) een kernel update gehad. Overigens steeds begeleid door uitgebreide testscripts, maar iedere keer probleemloos.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Zelf heb ik op mijn Linux-servers alleen dit jaar al enkele malen (twee maal, drie maal?) een kernel update gehad.

Een kernel update is niet per se een hogere kernelversie (minor revision) maar maar vaak alleen een bug/security fix versie dus dat zegt niks.
Enterprise edtities en long term support versies draaien normaal jarenlang op dezelfde minor revision kernelversie.

[Verwijderd]

Een kernel update is niet per se een hogere kernelversie (minor revision) maar maar vaak alleen een bug/security fix versie dus dat zegt niks.

Maar vaak ook wel. Als er een nieuwere kernel versie nodig is om veilig te kunnen draaien, dan wordt dat gedaan. Ik zou niet weten waarom je dat niet zou doen (natuurlijk na zorgvuldig testen). Een en ander is niet meer dan een update.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Je denkt dat enterprise klanten nooit een kernel updaten omdat er een issue is in een vorige versie?

Ik denk dat de meeste klanten die dergelijk enterprise linux versies aanschaffen dat juist doen te werken met de stabiele kernelversies zodat ze hun server zo stabiel mogelijk houden en ze daarom juist niet hun kernel willen updaten maar op de bewezen kernel versie van hun enterprise editie willen blijven.

[Verwijderd]

Ook bewezen kernel versies kunnen (op moment van release onbekende) security issues bevatten. Dan ga je updaten.

Het woord kernel klinkt erg zwaar, maar in WIndows, waar de bewezen kernel bestaat uit een verzameling DLL's en executables is het gebruikelijk om te updaten indien nodig. Waarom zou dat bij een meer monolitisch (maar eigenlijk toch modules) geörienteerde architectuur (zoals Linux) niet kunnen?

Het lijkt mij sterk dat er nog een enkele binary van de bewezen XP-kernel uit 2001 nu nog dezelfde is in 2009. Nou dan?

Dat is trouwens niet alleen bij Windows en Linux zo, maar bij nagenoeg ieder OS.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[bartcramer]

Natuurlijk niet. Red Hat geeft 7 jaar security support op al zijn versies van RHEL. Dat betekent dat in ieder geval alle CVE-kwetsbaarheden worden opgelost. Omdat security patches bijna nooit de functionaliteit veranderen, kan men deze dus bijna met de ogen dicht toepassen. Wat goede systeembeheerders dus ook doen.

[Verwijderd]

Official Statement from Red Hat (09/08/2009)
The attacks reported by Outpost24 AB target the design limitations of the TCP protocol. Due to upstreams decision not to release updates, Red Hat do not plan to release updates to resolve these issues however, the effects of these attacks can be reduced via the mitigation methods as written in http://kbase.redhat.com/faq/docs/DOC-18730.

[Verwijderd]

[...]
Nadeeltje alleen is dat distro's gebaseerd op die oudere kernels dus niet worden geupdate en oude windows versies wel.
Dus met een up to date RHEL van vorig jaar heb je wel nog dit probleem maar met een 6 jaar oude windows server versie krijg je wel een security update.

Klopt niet hAl,
Windows 2000 wordt niet gerepareerd, terwijl het wel tot medio 2010 wordt beloofd te ondersteunen. In feite een soort van niet nakomen van belofte!

[Verwijderd]

Hmmm, Windows 2000, een product dat end of life is en nog maar heel beperkt wordt ingezet en waar al meerdere opvolgers voor beschikbaar zijn of het huidige slagschip onder de Linux enterprise producten.

Microsoft heeft patched dus alle vunerable Windows producten vanaf 2003 (en XP uit 2001 is niet vunerable).

Linux patched alleen producten met nieuwe up to date kernelversies vanaf april 2008 en patched zelfs niet eens current versies van hun producten met oudere kernel versies.
Als je nu een gloednieuwe RHEL versie installeert en volledig patched blijf je gewoon kwetsbaar omdat de daarin gebruikte kernelversie niet wordt gepatched.

[Verwijderd]

Ik heb er een hekel aan om dezelfde discussie met de zelfde persoon op meerdere plaatsen tegelijkertijd te voeren. Dus verwijs ik naar
mijn reactie hier'

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[kozue]

Onzin. Zoals je in het artikel kunt lezen zit dit probleem niet in XP, dus of ze het zouden fixen in een 6 (eigenlijk 8 ) jaar oude kernel? Ik denk het niet, de support voor XP is voor zover ik weet al verlopen. Je kunt het al zien aan de genoemde Win2k, waar het probleem ook in zit, en ze het niet willen fixen.
Alleen Vista en Win2k8 worden gefixt. Vista is uit 2007 (2½ jaar oud), en een 2½ jaar oude distro wordt de kernel ook van gerepareerd.

Verder vermoed ik dat MS zit te liegen dat ze barsten. Het probleem zit in win2k, en in vista, maar niet in een tussenliggende release? Ik denk dat het meer een gevalletje is van "we weten dat het er in zit, maar gaan het niet toegeven omdat we het toch niet gaan fixen". Er zijn nog te veel XP gebruikers om gewoon de middelvinger naar op te steken, dat zou ze teveel klanten kosten denk ik.

[Reactie gewijzigd door kozue op 23 juli 2024 14:25]

[Verwijderd]

Er is wel een drieweg-handshake nodig om het lek te misbruiken, waardoor het voor een aanvaller lastig is om zijn ip-adres te spoofen.

Met de beschikbaarheid van gigantische botnetwerken hoeven kwaadwillenden zich nauwelijks zorgen te maken over het wel of niet anoniem zijn van hun eigen IP adres. Er kan altijd een bot geofferd worden.

[Dracoo]

Ik weet niet of de beheerders van het botnet daar zo blij mee zijn, zij willen natuurlijk liever dat het bestaan van hun botnet onbekend blijft. Het opsporen van een botnet gaat immers een stuk makkelijker als je een schakel van zo'n botnet in handen hebt.

@elmuerte:
Bij veel DDOS aanvallen is dit dus niet nodig, in ieder geval niet bij een UDP aanval (aangezien er geen response terug hoeft). Dan kun je je IP adres eenvoudig spoofen waardoor het achterhalen van de bron pc lastig wordt.

Maar je hebt gelijk dat die ene zombie ze niet zal interesseren, ik zat met mijn gedachten juist bij de consequentie voor de rest van het botnet: als er eentje bekend is, valt de rest waarschijnlijk ook te traceren.

[Reactie gewijzigd door Dracoo op 23 juli 2024 14:25]

[elmuerte]

De zombies zijn in een botnet juist altijd bekend op het moment dat ze iets doen. Het is voor een botnet operator jammer als een zombie onschadelijk gemaakt wordt, maar geen ramp.

[Reactie gewijzigd door elmuerte op 23 juli 2024 14:25]

[.oisyn]

Tja, noem het maar een "lek". Natuurlijk, in het geval van Vista en Server 2008 is het een lek omdat je er code mee kunt uitvoeren, maar hier wordt met "lek" al het feit bedoeld dat je simpelweg connecties kan openen naar een bepaalde host. Dat dat kan is een vrij normale gang van zaken. De patch waar het hier om gaat is dan simpelweg om dat beter te handlen - zoals bijv. als het aantal connecties opraakt, dat je dan verbindingen gaan sluiten die na de handshake al een tijd geen data verstuurd hebben, ipv dat nieuwe keihard genegeerd worden. Maar anders dan dat is er niet zo heel erg veel aan te doen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:25]

[matthijsberg]

volgens mij zit het ongeveer zo:

Het "lek" is dat de sessies niet, zoals normaal het geval is, afsterven maar voor langere of zelf onbepaalde tijd actief blijven. Normaliter is er voor een DOS aanval een groot aantal packets noodzakelijk omdat voor de overflow er een continue stroom van packets noodzakelijk is. De stroom moet dan grote zijn dat de hoeveelheid die het systeem kan verwerken wat leid tot de DOS.

Indien de sessies niet "verwerkt" worden op het systeem maar open blijven staan dan is er veel minder verkeer noodzakelijk omdat er zogenaamd gestapeld wordt. Voor een DOS aanval zijn in dit geval dus veel minder bots en veel minder verkeer nodig.

Meer info vind je ook hier: http://www.govcert.nl/download.html?f=144

[.oisyn]

Het "lek" is dat de sessies niet, zoals normaal het geval is, afsterven maar voor langere of zelf onbepaalde tijd actief blijven.

Nee, dat is niet normaal het geval. Actieve sessies, wat open verbindingen zijn na een 3-way handshake, blijven gewoon actief totdat een van de twee hosts de verbinding sluit danwel totdat na het versturen van data blijkt dat de andere partij een RST packet stuurt.

Deze patch zorgt er dan ook niet voor dat dit soort sessies na een tijdje sluiten. Wat de specifieke patch van MS doet is (naast het dichten van het échte lek waarin code geexecute kan worden) gewoon willekeurige sessies sluiten op het moment dat er te weinig resources zijn om een nieuwe verbinding aan te gaan.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:25]

[SPee]

Dat is niet het probleem, wat ik denk.
Het aantal actieve sessies is bekend en als er te weinig zijn, kunnen de niet gebruikte connecties 'opgeofferd' worden. Dat lijkt me niets nieuws.

Volgens mij was meer het probleem dat de 3-way handshake niet wordt afgemaakt.
De server stuurt wel de 'ACK' terug, maar daar komt dan geen antwoord (binnen een bepaalde tijd) op terug. Hierdoor is op de server wel de connectie bekend en gereserveerd, maar wordt die nog niet tot de actieve verbindingen gerekend en zal/kan dus niet worden 'opgeofferd'.

Waarschijnlijk is de patch dat deze nu ook 'opgeofferd' kunnen worden als er te weinig zijn, of dat ze na een bepaalde tijdslimiet weer worden vrijgegeven.

Wat ik hier verder lees, is dat Linux hier niet vatbaar voor is.

[.oisyn]

Volgens mij was meer het probleem dat de 3-way handshake niet wordt afgemaakt.

Pertinent onwaar. Dat heet een SYN flood. Dan stuurt de attacker gewoon SYN packets met een gespoofd source address.

Hier gaat het om Sockstress. Omdat de handshake juist wél wordt afgemaakt, kan er ook niets gespoofed worden - de attacker moet nog een keer reageren met een antwoord op de SYN-ACK (en dus niet de ACK) van de server (dat antwoord van de client is dus wel weer een ACK), en wat eigenschappen die in dat SYN-ACK pakketje stonden. Dit zet de verbinding open en reserveert extra systeem resources. Dat is bij nog niet afgemaakte handshakes (half-open connecties), zoals jij suggereert met SYN floods, niet het geval, want die komen na een tijdje gewoon op een time-out waardoor ze weer vrijgegeven kunnen worden.

Tegen een SYN flood kun je je aardig beveiligen (het aantal te alloceren resource per socket is gering, en de timeout kan vrij kort zijn aangezien je toch vrij snel een ACK verwacht). Dat is met Sockstress echter een veel groter probleem, omdat het in feite gewoon een normale gang van zaken is. Wat ook de hele reden is dat ik "lek" er een te groot woord voor vindt. Het enige dat je kunt doen is verbindingen afschieten op het moment dat je resources te kort komt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 14:25]

[thedicemaster]

niet meer.

oudere versies haden hier ook last van, de linux programmeurs waren alleen iets sneller dan cisco en ms met hun fix.

[Ali3nSt0rmz]

ENKEL in server 2008 Release 1
Vanaf de R2 (wie heeft er nog R1?) is het niet meer mogelijk het uit te buiten

[sorted.bits]

Is R2 niet de Windows 2008 met dezelfde kernel als Windows 7? Ik denk niet dat er al heel veel bedrijven zijn overgestapt op die versie..

[Verwijderd]

Wie 2008 R1 heeft? Wie niet? 2008 R2 is nog niet eens voor de normale klant te krijgen volgens mij. R2 is wat anders als SP2.

[Fairy]

Een heleboel, want als je op R1 draait ga je echt niet zomaar R2 aanschaffen en de server upgraden/herinstalleren, dat is voor veel bedrijven een veel te grote investering.

Er draaien nu ook ontzettend veel bedrijven op Windows 2003 R1 en R2 en dat is ook logisch want Microsoft support deze versie ook 100%

[Reactie gewijzigd door Fairy op 23 juli 2024 14:25]

[Verwijderd]

Oudere versies van Linux en BSD zijn overigens ook kwetsbaar; het lek is in de recentste kernels echter al gedicht. Redhat heeft bij wijze van workaround voor gebruikers van oudere kernels wel een klein firewall-scriptje online gezet.

Als bijvoorbeeld Redhat en andere distros'die oudere kernels nog gewoon gebruiken in hun geupdatete serverversies dan is het vreemd dat de oplossing niet wordt teruggepoort

[Verwijderd]

[...]
Als bijvoorbeeld Redhat en andere distros'die oudere kernels nog gewoon gebruiken in hun geupdatete serverversies dan is het vreemd dat de oplossing niet wordt teruggepoort

Het mag voor jou vreemd overkomen. Er zijn vele redenen denkbaar waarom het niet terug gepoort wordt. Misschien dezelfde reden waarom ook Windows 2000 niet wordt gerepareerd (terwijl die ook nog bijna een jaar officieel wordt ondersteund (http://support.microsoft.com/lifecycle/?p1=7274)).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Er is wel een verschil tussen een stokoude windows 2000 versie die al twee opvolgers heeft die wel gepatched worden en een current versie van linux die gewoon nu nog wordt aangeboden voor huidige hoogkritsche linux oplossingen

[Verwijderd]

Windows 2000 wordt nog steeds ondersteund. (maar niet gerepareerd!!)

Kernel 2.6.24 wordt nergens meer aangeboden, en is dus ook geen current version. Tenminste, niet dat ik weet. Als jij anders weet hoor ik dat graag.
Inmiddels zit ik op kernel 2.6.28, dus al vier opvolgers later, en de laatste kernel versie is 2.6.31.

Verreweg de meeste software heeft weinig kennis van de kernel versie, zoals ik al in een andere reactie aangaf.

Misschien dat jij weet hebt van software die wel draait op kernel 2.6.24, maar niet op kernel 2.6.25. Dan is dat heel jammer. Ik hoop dat dat dan gerepareerd kan worden, bij voorkeur in de software.

Maar eerlijk gezegd kan ik me het bestaan van dergelijke software niet voorstellen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Kernel 2.6.24 wordt nergens meer aangeboden, en is dus ook geen current version. Tenminste, niet dat ik weet. Als jij anders weet hoor ik dat graag.

Oudere kernels worden wel degelijk aangeboden in current main line linux producten.
SUSE 10 zit op 2.6.16
RHEL 5 zit op 2.6.18
Ubuntu 8.04 long term support zit op 2.6.24
Deze producten blijven op dezelfde kernelversie en backpoorten normaal security patches uit hogere kernelversies.

De SUSE en RHEL kernel zijn nu dus echter kernels die dus voor dit probleem geen gebackpoorte oplossing krijgen en die dus vunerable blijven voor deze TCP vunerabilities tenzij je zelf de kernel update wat juist niet de bedoeling is van dergelijke stabiele (server) producten.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Aangezien het triviaal is om een nieuwe kernel te installeren is het geen issue.

[Verwijderd]

udere kernels worden wel degelijk aangeboden in current main line linux producten.
SUSE 10 zit op 2.6.16
RHEL 5 zit op 2.6.18

Je gaat uit van marketingteksten die enkel jaren geleden zijn geschreven. Denk je dat deze producten niet worden geupdate? Welk software bedrijf ben jij gewend??

Een beetje reeel zijn, ik schreef al eerder vandaag dat ik van mijn distributeurs dit jaar twee kernel updates had gekregen.

[Verwijderd]

Je gaat uit van marketingteksten die enkel jaren geleden zijn geschreven

Ik heb de gebruikte versies door deze producten van wikipedia geplukt.
Over het algemeen worden deze door open source fans erg strak bijgehouden

Denk je dat deze producten niet worden geupdate? Welk software bedrijf ben jij gewend??

Deze producten worden wel geupdate maar bijvoorbeeld van 2.6.18.31 naar 2.6.18.32.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Tja, ik weet dat niet, in hoeverre Wikipedia betrouwbaar is, er is daar ook veel vandalisme. En allerlei harrewarrige discussies. Ik zal dat niet snel als betrouwbare referentie gebruiken.

SUSE 10 zit op 2.6.16
RHEL 5 zit op 2.6.18

Suse 9 zat op nog een oudere versie. Wij in ons bedrijf gebruiken Suse 11. al bijna een jaar (uit het hoofd), en dat zit bij ons op kernel 2.6.28 (op dit moment), dus wat dat betreft is jouw informatie erg verouderd.
Volgens de website zitten (enterprise-versie) ze op 2.6.27, zo zie je maar hoe de werkelijkheid en website uit elkaar kan lopen)

En als Redhat (zoals jij zegt, maar je informatie is verouderd en uit een dubieuze bron) perse een jaren oude kernel blijft uitleveren en weigert te updaten, dan zou ik als klant dag met het handje zeggen. Want dat is het mooie van Linux, er is keuze. Linux != RedHAT. Maar ook bij Redhat kun je gewoon naar een nieuwere kernel updaten
Microsoft/Windows is er maar een, Windows 2000 wordt niet gerepareerd, punt uit. Bij Linux is keuze

Uiteindelijk gaat het niet om Redhat of Suse of een andere, maar om Oracle, Apache, Mysql, LDAP, Samba, Tomcat of wwhatever ook je die Linux-server gebruikt, en dan kies je de distro die je het beste behandelt.

Een OS is maar een OS, amper spannend en zeker inwisselbaar, de toegepaste software, die is nuttig.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Wij in ons bedrijf gebruiken Suse 11. al bijna een jaar (uit het hoofd), en dat zit bij ons op kernel 2.6.28 (op dit moment), dus wat dat betreft is jouw informatie erg verouderd.

Wij hebben volledig gepatchte RHEL 5 servers en die zitten toch echt op kernelversie
2.6.18-128.2.1.el5 (of zoiets). Dat is dus 2.6:18 met securitypatches die door RedHat uit hogere versie gebackpoort zijn.
Echter RedHat geeft dus expliciet an dat dit voor deze TCP issues NIET zal gebeuren.

[Verwijderd]

Linux != RedHAT. Er is keuze-mogelijkheid.

Ik leg dat uit in mijn reactie van gisteren.

Het betreffende TCP-lek is heel moeilijk te misbruiken, zeker wanneer er een IP-tables scriptje wordt ingezet, zoals RedHAT voorstelt aan de klanten. Lees ook reacties elders in deze thread. Het kan zijn dat dat de overweging is van RedHAT, maar dat moeten ze bij jou op het werk maar zelf navragen.

Het TCP-lek speelt pas een rol nadat een three-way handshake heeft plaatsgevonden. Het is dus geen SYN-flood, daartegen zijn Linux-kernels al meer dan tien jaar beschermd.
Met andere woorden, de aanvaller heeft zijn handtekening (lees IP-adres) moeten zetten, en kan geblokkeerd worden. Om effect te halen zou hij gelijk vanuit een ander IP-adres weer dezelfde aanval moeten uitvoeren.
Je zou dus een grootscheepse multi-botnet attack moeten uitvoeren voor een beetje effect.
Als je dat soort grootse dingen wilt/kunt doen, dan wil je in het algemeen meer resultaat dan het buiten werking zetten van een server voor enkele minuten. Er komt technisch nogal wat bij kijken om deze aanval uit te voeren.

Wij hebben bij ons op het werk overigens geen enkel probleem omdat wij gebruik maken van de fix die ongeveer een jaar geleden in de kernel is gebouwd.

Waar we mee te maken hebben is een gehypted probleem dat Microsoft met veel lawaai aan de klok hangt omdat zij het gisteren hebben gefixd.
Ze hadden het een jaar geleden moeten fixen, dat is andere koek.
Maar afgezien daarvan, het lawaai is natuurlijk omdat RedHAT gisteren een bepaald statement deed, en daar wordt in het dagelijkse moddergevecht dankbaar gebruik van gemaakt, meestal niet gehinderd door kennis van zaken.

Eigenlijk is het jammer dat ik daar ook zoveel tijd aan heb besteed. Ik liet me meeslepen. Want het is allemaal werkelijk een storm in een glas water.

Even terzijde, volgende illustreert hoe dit soort discussies werken
Ik las elders dat de ontdekker van het probleem een half jaar geleden in zijn huis is verbrand. Twee mensen vonden het leuk om daar grapjes over te maken, misschien was zijn iPhone ontploft.

grapjes maken over iemand die levend is verbrand, hoe diep zullen we nog zinken in dit soort discussies.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Linux != RedHAT. Er is keuze-mogelijkheid

Als je niet aanvoelt dat als het huidige vlaggeschip product van linux (RHEL is het linux product dat verreweg de meeste omzet genereert) juist het product is dat niet gepatcht wordt dat dat slecht is voor linux als product in het bedrijfsleven dan is er weinig te verhelpen.

Je moet niet doen alsof dat maar niks is. Het is juist opvallend dat in een tijd waarin linux distro's claimen support voor versies te verlengen om aantrekkelijker te worden voor bedrijven dat men er bij de kernel ervoor kiest om die versies dan maar niet de voorzien van alle security patches.

Daarmee gaat juist de essentie van het hele concept van lange termijn supported versies de deur uit.

[Verwijderd]

Linux is al jarenlang aantrekkelijk voor bedrijven, zeker op het server segment. In sommige server segmenten is Linux al tien jaar onbetwist leider. Daar kan dit probleem niets aan af doen. net zo min als dit probleem het marktaandeel van een andere partij zal verstoren

En als RedHAT dit in deze release niet patcht, dan is dat prima voor hun. het is hun keuze. Ik heb daar geen last van. Want heb ik en anderen ook al een paar keer gezegd dat er een prima IP-tables script is, want deze aanval is wel erg makkelijk om af te wentelen, en daarbij ook nog erg moeilijk om uit te voeren. Ik was zo goed om dit uitgebreid toe te lichten: hier
Daarnaast is het gewoon mogelijk om naar een andere distributeur te switchen. In de meeste gevallen, bij professioneel ingerichte machines is dat een karweitje van drie uur. Bij Linux kun je een vendor lockin meestal makkelijk voorkomen.

Jij noemt RedHAT een vlaggeschip, dergelijke emotionele uitingen spelen in ons bedrijf niet. Ik heb benadrukt dat er keuze is, Wij maken een bewuste keuze, jullie blijkbaar een andere. Jullie systeembeheerders zullen het kunnen inschatten en dit probleem niet belangrijk vinden om even een Suse machine op te tuigen of een kernel-upgrade te doen. Blijkbaar valt het allemaal wel mee. Dat is ook de opinie van veel deskundigen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Jij noemt RedHAT een vlaggeschip, dergelijke emotionele uitingen spelen in ons bedrijf niet.

Dat heeft niks met een indivudueel bedrijf te maken maar met het het product.
De essentie van deze exercitie is dat enterprise en long term support versies niet samengaan met de snel ontwikkelende kernel en dat security patches niet volledig teruggepport (kunnen) worden zodat zelfs nog volledig actuele main stream linux distro's niet meer up to date gepatched kunnen worden.

Daarnaast is het gewoon mogelijk om naar een andere distributeur te switchen. In de meeste gevallen, bij professioneel ingerichte machines is dat een karweitje van drie uur

Bij een proffesioneel ingerichte organisatie peins je er niet over om zo maar even de serversoftware onder je bedrijfkritische toepassingen te veranderen.

Jij vind het blijkbaar pima dat het belangrijkste en bekendste actuele linux server product niet meer dergelijke patches ontvangt en in feite een permanent bekend lek oploopt.
Ik vind het een opvallende zaak omdat juist linux leveranciers met producten als RHEL een imago probeert uit te stralen van stabiliteit en security. Als je na een paar jaar niet meer in staat bent om dat product volledig te patchen dan is dat geen goed teken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Long term support is wel mogelijk, ook zonder terugpoorten

Je kan ook vooruit in de kernelversie, je kan middels een workaround een aanval verijdelen, meerdere mogelijkheden.

Zelf (maar dat is persoonlijk) ben ik geen voorstander van terugpoorten binnen minor-versies,
Zeker als dat veel op de kop zet, wat hier aan de hand is, de kosten zijn erg hoog en worden amper terugverdiend. Zeker ook indien het probleem op een andere manier kan worden opgelost, wat hier ook aan de hand is.

Met Linux als product heeft het allemaal niets te maken, iedereen die denkt dat Linux staat of valt bij RedHAT heeft heel wat gemist, laatste tien jaren.
Misschien is dat voor RedHAT (en voor jou) iets wat nog geleerd moet worden. Dat kan.

En nogmaals, het lek is nagenoeg niet exploitable met de IP-tables-instructies. Dus waar gaat het allemaal over? Snap je eigenlijk wel wat het lek is? Ik betwijfel dat ten zeerste.

Kijk MS heeft dit lek een jaar laten open staan. Waarom heb ik jou afgelopen jaar daar niet over gehoord? Dat vreselijke lek wat open stond? Het lek is al een jaar bekend, tot in detail bij mensen die het werkelijk wilden weten.
Waarom niet publiekelijk Microsoft een jaar lang ten schande gemaakt?

Waarom hoor ik jou er niet over dat een Windows2000 dat officieel nog steeds gesupport wordt, waarvan meer dan 10 miljoen computers aan het Internet worden gemeten, dat niet wordt gepatcht, waarvoor geen IP-tables script of andere workaround bestaat?? Waarom veeg jij je eigen straatje niet?
Het mijne is schoon, al meer dan een jaar.

Waarom bagatellisseer je in deze discussie lekken in WIndows die heel actueel en heel erg ernstig zijn en nog niet gepatcht? Zoals je hier doet?

Denk daar maar eens over na.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Long term support is wel mogelijk, ook zonder terugpoorten (je kan ook vooruit in de kernelversie, je kan middels een workaround een aanval verijdelen, meerdere mogelijkheden).
Halsstarig vasthouden aan een bepaalde kernelversie kan ook als fout worden beschouwd.

Dus als RHEL 5 niet overgaat op een nieuwe kernelversie zitten ze fout ?!
In feite kan Linux blijkbaar nog niet eens twee jaar een kernelversie ondersteunen met security patches.
Dat vind ik nou fout

[Verwijderd]

Dus als RHEL 5 niet overgaat op een nieuwe kernelversie zitten ze fout ?!

Ik zal niet zeggen dat ze fout zitten, ik heb dat ook niet gezegd, lees maar terug. Ik heb daarover niet zo'n uitgesproken standpunt
En omdat over Linux in het algemeen te zeggen is een ernstige vergissing.

Overigens ben ik je wel dankbaar dat je me middels je opmerkingen in de gelegenheid stelt om dit allemaal uit te leggen. Ik vind Linux een goede zaak, en ben blij dat ik misverstanden uit de weg kan ruimen. (al betwijfel ik of iemand dit nog leest
Met dezelfde energie waarmee jij nu al twintig reacties lang kritiek op Linux/RedHAT hebt beantwoord ik je vragen en opmerkingen ook 20 reacties lang

In feite kan Linux blijkbaar nog niet eens twee jaar een kernelversie ondersteunen met security patches.

Wat je zegt klopt niet, alleen minor versies worden binnen dezelfde major-versie niet teruggepoort door de kernelmaintainers, alleen vorige major-versies, die dan een nieuwe minor versie krijgen.
Hier zie je de 2.4 versie, op de markt vanaf 2001
http://www.kernel.org/pub/linux/kernel/v2.4/
Je ziet recente patches (2009, dat zijn backports), voor bedrijven die "verslingerd" zijn aan die 2.4 versie, dit gebeurt door de kernel-maintainers.
Dus in feite ondersteunt Linux op dit moment een vorige kernel versie al bijna tien jaar.

De 2.6 kernel, is op de markt vanaf 2003 is de actuele. Updates vormen nieuwe minor-versies.
Achter de minor-versies komen nog de patches op de minor-versies, maar zijn meestal een vendor aangelegenheid.

Alleen als er een belanghebbende is om een patch op een minor-versie naar een minor-versie binnen dezelfde major-versie terug te porten, dan moet die dat zelf maar doen. Iedereen mag het op zich nemen om en oude kernel te gaan onderhouden. Maar er is niemand geïnteresseerd.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Alleen als er een belanghebbende is om een patch op een minor-versie naar een minor-versie binnen dezelfde major-versie terug te porten, dan moet die dat zelf maar doen. Iedereen mag het op zich nemen om en oude kernel te gaan onderhouden

Dat is dus precies wat de leveranciers vvan enterprise en long term support versies proberen maar blijkbaar gaat dat dus niet volledig lukken en zullen bepaalde lekken gewoon blijven zitten.

[Verwijderd]

Suse slaagt er wel in om long term support te geven, maar ook een recente kernel te draaien. Misschien moet RedHAT daar eens kijken hoe ze dat doen. Maar nogmaals, het is niet mijn probleem, en geen Linux-probleem, het is een RedHAT-probleem.

Overigens worden bij Microsoft ook geen patches op minor versies teruggeport naar minor versies binnen dezelfde major-versie. Als je als vendor afhankelijk bent van een bepaalde minor-versie-DLL, en daarin wordt een lek ontdekt, dan zul je moeten upgraden.
Of op een andere manier dat lek onbereikbaar maken.
(de Windows kernel is een verzameling DLL's)

Het is gewoon common sense in software ontwikkeling

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Verwijderd]

Zo te zien draait SUSE 10 gewoon op een oude kernel hoor en die wordt nog veel gebruikt. Ik zie daar geen minor version version update naar een versie die deze in het artikel besproken bug niet meer bevat

[Verwijderd]

Net zoals jij het geen probleem vindt voor bedrijfskritische software om over te gaan naar R2 van Windows 2008, zal het voor 99% van de software ook geen probleem zijn om over te gaan naar Suse 11, dat op kernel 2.6.27 draait. Daarin was dit probleem al een half jaar geleden opgelost. Waarom had MS een jaar nodig om dit op te lossen?

Was het niet urgent bevonden? Daar lijkt het op. En waarom was het dan niet urgent?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:25]

[Olaf van der Spek]

Ik weet vrijwel zeker dat bijvoorbeeld Debian wel met een oplossing komt.

[Olaf van der Spek]

Een aantal fabrikanten heeft patches uitgebracht voor een kwetsbaarheid in het tcp-protocol,

Waarom wordt nergens uitgelegd wat die kwetsbaarheid nou is?
Toch jammer dat er pas in de reacties links te vinden zijn die het wel uitleggen.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 14:25]

[wildhagen]

Als je het artikel ook verder gelezen had dan alleen de eerste regel had je gezien dat het uitgelegd word. Zie de tweede alinea van het artikel.

Je had bijvoorbeeld ook het Security Bulletin MS09-048 van Microsoft kunnen bekijken waar ook een en ander in word uitgelegd, inclusief mitigating factors etc.

[Reactie gewijzigd door wildhagen op 23 juli 2024 14:25]

[Olaf van der Spek]

had je gezien dat het uitgelegd word.

Waar dan? Ik zie nauwelijks details.

[mu-sick]

Is dit een fix voor het 'lek' dat slowloris.pl misbruikt?

[StM]

Slowloris is op HTTP niveau. Dit werkt op het tcpniveau en werkt op basis van het misbruiken van beveiligingen in het tcp protocol.

[dezejongeman]

http://security.nl/artike...hten_ernstig_TCP-lek.html

hier een link met nog wat informatie over het dichten van het lek.

[smartbit]

De 25c3 sessie TCP Denial of Service Vulnerabilities http://events.ccc.de/cong...rplan/events/2909.en.html (hier te downloaden ftp://ftp.ccc.de/congress...rvice_vulnerabilities.mp4) legt het nog een keer uit.

[Goldin]

Voor de genen onder ons die geen verstand hebben van hacks/bugs, DoS staat voor: Denial-of-service. En komt er meestal op neer dat een computer/server overspoeld word met opdrachten (door internet/netwerk) waardoor hij compleet vast komt te zitten.

ik vind het overigens wel weer typisch dat het pas naar een jaar gefixed word.

[joepHDW]

De DOS aanval die gebruik maakt van dit TCP-lek heet ook wel SockStress.
Bekijk http://sockstress.com/ voor meer informatie en uitleg over het probleem.