Servers eenvoudig overbelastbaar met hash-aanval

De New Scientist schrijft dat wetenschappers van de Houston University in de VS een speciale vorm van netwerkaanvallen hebben ontwikkeld, die niet zozeer de bandbreedte van een aansluiting opslokt, maar wel eenvoudig de computer erachter lam kan leggen. De techniek werkt als volgt: elke aan een netwerk aangesloten computer voert aan alle binnenkomende pakketjes bepaalde berekeningen uit. Deze 'hashes' zijn over het algemeen vrij eenvoudig en snel uit te rekenen, maar men is er nu in geslaagd de pakketjes zodanig te ontwerpen dat een gemiddelde computer hier zeer intensief mee bezig gaat. Zelfs bij een klein beetje netwerkverkeer zal het apparaat zichzelf al snel voor honderd procent op de hashes storten en geen CPU-cycles meer over hebben voor andere taken. Hiermee is het zelfs mogelijk servers plat te leggen over een smalle 56k6-telefoonlijn. De wetenschappers onderkennen de gevaren die met hun ontdekking op de loer liggen, maar werpen daar tegenin dat het goed is dat de techniek eerst is ontdekt door de wetenschap in plaats van door kwaadwillende sujetten:

A paper outlining the attack will be presented at the Usenix Security 2003 conference in August 2003. Wallach admits that releasing it might inspire some hackers to try and use the technique, but believes it is important to raise awareness.

"Any technique that can be used to launch attacks eventually will," Wallach told New Scientist in an email. "The only way to fix a problem that affects so many different systems in different ways is to widely publicise the problem."

Reacties (60)

[serkoon]

Toch wel jammer dat er van het oorspronkelijke nieuws weinig over is gebleven. Daarom maar even een korte (en zo correct mogelijke) samenvatting.

Het gaat er dus om dat veel programma's en ook kernels hashtables gebruiken om data op te slaan. Bij 'normaal gebruik' zijn deze vrij efficient, maar de performance kan behoorlijk inklappen bij 'abnormaal gebruik'. Je kunt dus in sommige gevallen als aanvaller invloed uitoefenen op de efficientie van hashtable-gebruik in software, waardoor een DoS mogelijk kan worden. Hiervoer moet je 'collissions' forceren, wat vrij complex is in de meeste gevallen, als het al mogelijk is..

De onderzoekers hebben oa Squid getest, dat met een paar honderd packets per seconde al plat gegooid zou kunnen worden. Er is laatst ook een dergelijk DoS-probleem in de Linux kernel gevonden trouwens..

[Leon]

Het originele bericht gepost op de securityfocus bugtraq mailinglist staat hier

En hier heeft hij nog wat meer informatie op een site gezet

** Affected Products:

Extremely widespread. Confirmed vulnerable applications
include Perl, the Linux kernel, the Bro IDS, and
the Squid HTTP proxy cache. Although unconfirmed,
vulnerablities appear to be in the GLIB utility library, DJBDNS
cache, TCL, Python, and Mozilla.

We conjecture that many implementations of hash tables in both
closed source and open source software, unless specifically
designed to be immune, may be subject to attack. It is likely
that many unexamined applications are also vulnerable.

** Impact:

Varies from insignifigant to critical, depending on application
and application's configuration.

** Risk:

Remote and local attackers can cause system or application
performance to degrade.

** Deployment:

Confirmed or possibly vulnerable applications are extremely
widely deployed.

** Ease of Exploitation:

Relatively straightforward. The attacker compute a set of input
that causes collisions. In many cases, 15 minutes of code
inspection, twenty seconds programming and two hours of CPU
time.

** Is exploit code available publicly?

It is not known to be available publically. However,
small demonstration files for several applications are available
on the project page at http://www.cs.rice.edu/~scrosby/hash

[ArnoudJ]

Als ik me niet heel erg vergis heb ik al eens een security-fix voor m'n apache server geinstalleerd waarbij stond dat de fix voor zo'n soort hash aanval was. Het probleem was dus al bekend. Of deze patch alle vormen van hash aanvallen tegen kan houden of alleen 1 specifieke weet ik niet.

[Verwijderd]

Voor zover ik het goed meegekregen heb gaat het hier om een probleem dat zich op een lager level afspeelt. Voordat de pakketjes doorgegeven worden aan Apache, worden ze eerst door de kernel van je systeem bekeken. Daar worden die berekeningen aan de hash ook uitgevoerd. Het zal dan waarschijnlijk om een andere fix voor Apache gaan dan dat hier bedoeld wordt.
[edit] - typo

[Leon]

Laatste security advisory' s voor apache (2) hadden niets met deze vorm van aanvallen van doen:

Apache Portable Runtime Denail of Service and Arbitrary Code Execution Vulnerability

[Verwijderd]

Niet door hackers maar door, onderzoekers? Nucliare bom is ook door onderzoekers uitgevonden, dat wil nog niet zeggen dat we er blij mee moeten zijn!

beetje kort zichtig je ontwikelt iets om te vernietigen en je zegt daarna dat je zo geweldig bent omdat jij het hebt uitgevonden en geen crimineel en dus dat het niet erg is

typo

[Swinnio]

Niet door hackers maar door, onderzoekers? Nucliare bom is ook door onderzoekers uitgevonden, dat wil nog niet zeggen dat we er blij mee moeten zijn!

Das natuurlijk onzin (en offtopic ). Onderzoekers hebben dit probleem niet uitgevonden, maar ontdekt. Het bestond in feite dus al. Door het nu aan de kaak te stellen, kan er misschien een oplossing voor gevonden worden, voordat er schade mee kan worden aangericht.
Andersom geldt niet. Je kunt niet door snel een nucleaire (want zo schrijf je dat) bom uit te vinden er voor zorgen dat ie nooit meer door anderen gebruikt kan worden. Als er iemand kortzichtig is, ben je het dus zelf.

[theXE]

Maar mischien gaat de overheid daar dit wel gebruiken om een cyberoorlog te houden tegen landen die zij gevaarlijk vinden zoals Noord-Korea, en Syrië. Dit zijn landen die niet bekend staan om hun snelle internetverbindingen, en zo kunnen ze toch gepakt worden, zonder dat ze dus xDSL hebben o.i.d.

[boesOne]

Je kan landen met smalle verbindingen in een cyberoorlog juist op de conventionele manier met een DDOS plat krijgen.

Deze exploit van ethernet protocol is juist handig bij die servers die zo'n dikke lijn hebben dat je ze nooit plat kan DDossen, zoals de DNS root servers.

Ik ben geen tcp/ip expert maar volgens mij zit deze xploit vrij diep in het protocol.. Elk pakketje heeft een hash dacht ik zo, en die heeft ie niet voor niks. Ben benieuwd hoe ze dit gaan patchen..

[Verwijderd]

Andersom: dit kun je verkopen aan smallband landen zoals Noord Korea en Syrië zodat die Amerika kunnen aanvallen

[Verwijderd]

en nog iets...wie zegt dat die wetenschappers de eerste waren?
misschien heeft een blackhat hacker er al jaren een exploit voor ontwikkeld die nooit publiek gemaakt is.

pas dit toe in een soort code red worm en het internet ligt lam.(waarmee ik niemand aanzet )

[Skyclad]

Je kan niet de wereld herprogrammeren om nucleare bommen onschadelijk te maken, je kan wel software aanpassen om een bug eruit te halen. ERG groot verschil!

(Al afgezien dat misschien jouw wereld vergaat wanneer je internet connectie sterft, maar de meeste mensen dat toch liever hebben dan een nucleaire aanval.)

[martijnvds]

Maar de vraag is: hoe lang zal het duren voordat een kwaadwillende 'cracker' er achter komt hoe hij zulke pakketjes kan maken en sturen?

Imho belangrijk dat de wetgeving op dit gebied strenger wordt. Ook al is het moeilijk iemand te pakken, je moet er voor zorgen dat de strafmaat vooraf al afschrikt, en mensen er van af laat zien om hele computernetwerken plat te leggen.

[tweakerbee]

Het is ten eerste nog nooit bewezen dat hoge straffen een goede vorm van afschrikking zijn. Ten tweede is het zo dat de anonimiteit (of de illusie daarvan) het voor veel mensen erg makkelijk maakt om stoute dingen te doen.

[Verwijderd]

Hmm, volgens mij gaat deze discussie heel ergens anders naartoe, maar goed:

Een hoge strafmaat werkt wel degelijk afschrikkend, als de straf maar op een "harde" manier aankomt... Nederland luistert goed naar Amnesty en is dus bijzonder slecht in het hard straffen van criminelen... Kijk eens naar de verhalen over wat er in bijvoorbeeld Amerika in de gevangenissen gebeurd... Tenzij je zeker weet dat je in het clubje met de macht terechtkomt, wil je daar echt niet terechtkomen hoor... En wat dacht je van lijfstraffen? Jij hackt een computer, wij hakken je handen af? Ik wil niet gaan beweren dat het goed is ofzo om op die manier te straffen, maar ik wil slechts aangeven dat het niet altijd zo is dat een "hoge" strafmaat niet afschrikkend werkt...

[Verwijderd]

Het is inderdaad beter da wetenschapper hier eerst achterkopen, maar zou het niet beter zijn dat ze eerst ook de oplossing aanrijken voor dit bericht de wereld in te sturen?

Ik kan best begrijpen dat je als wetensschapper trots bent als je iets ontdekt, maar denken jullie niet dat er nu heel wat mensen met minder goede bedoelingen ook in deze richting dingen gaan beginnen proberen?

[miw]

Je slaat hier de spijker op z'n kop. Alleen krijg je natuurlijk veel meer publiciteit als je de hack gelijk publiceerd. Da's ook veel makkelijker dan er ook gelijk een oplossing voor te bedenken. Trouwens, als je de oplossing gelijk aangeeft zegt iedereen: "O leuk, bedankt" en besteed er verder weinig aandacht aan. Op deze manier krijg je als onderzoeker veel meer bekendheid en daar lijkt het steeds meer om te gaan.

edit:
Het bovenstaande is in dit geval niet correct. Het artikel blijkt een oplossing te leveren in de vorm van een universal hashing functie. Ook het beperken van het resource gebruik wordt voorgesteld.

[Verwijderd]

Opzich een zeer gevaarlijk probleem omdat dus een enkel persoon hetzelfde effect kan krijgen als een hele grote groep met een DoS attack.

En ik denk dat er best vaak enkelingen zijn die een bepaalde server uit de lucht willen halen, maar dit niet kunnen omdat ze dus een grote groep nodig zijn, en via deze nieuwe(?) manier zou het dus wel mogelijk zijn.

Wel goed teken opzich dat wetenschappers hier achter zijn gekomen voor de hackers dit wisten uit te voeren. Wel vind ik het erg dom om dit nieuws naar buiten te brengen.

Ze hadden naar mijn inziens beter strikt geheim met de grootste Server software/Netwerk software developers de bug kunnen fixen en dan het naar buiten brengen.

[theXE]

Houston, we have a problem...

[justice strike]

is dit niet op te lossen door een kaartje te kopen die tcp/ip offloading ondersteund? waardoor alle checksums (niet alleen ethernet dus) door de nic afgehandelt worden. dan heb je ook geen last van cpu overloading (mja nou alleen van de nic dan )

en een beetje goede server zorgt ervoor datje de affinity van tcp/ip stack tot 1 processor beperkt (in geval van smp systeempjes)

[Verwijderd]

Er zijn niet ontzettend veel servers die over zulk kaartje beschikken. Meer nog, tot voor enkele weken geleden wist ik niet dat er kaartjes waren die de TCP/IP stack afhandelden in plaats van de hoofdprocessor.

Leuk idee dus, maar geen oplossing op dit moment.

[jp]

You lost me... omdat jij niet wist dat dat soort kaartjes bestaan worden ze niet gebruikt?

Ik vrees dat je jezelf iets te hoog in schat

Maar serieus... iedereen die zich er mee bezig houdt en probeert te begrijpen wat alle termen waar verkopers mee gooien daadwerkelijk in houden, weten waar het over gaat.

Hell, zo uit mijn hoofd ondersteunen alle Intel Pro100's die offloading al, en da's AFAIK een standaard kaartje die je in je PC of server stopt...

[Pewwy]

Ik zal je niet vertellen hoeveel bedrijven rustig een realtek kaartje in hun server laten installeren. Niet dat ik het begrijp, maar ik kom het te vaak tegen

[pistole]

Ik zal je niet vertellen hoeveel bedrijven rustig een realtek kaartje in hun server laten installeren. Niet dat ik het begrijp, maar ik kom het te vaak tegen

offtopic:
je hebt het dan waarschijnlijk niet over "servers" maar meer over veredelde werkstations...

[Olaf van der Spek]

Het gaat hier niet om checksums maar om hashes. En volgens mij gaat het ook niet over de berekening van hashes zelf maar over wat er daarna mee gebeurd.

en een beetje goede server zorgt ervoor datje de affinity van tcp/ip stack tot 1 processor beperkt (in geval van smp systeempjes)

Waarom?
Bovendien kan het probleem zich ook voordoen in hardware, dus offloading is geen oplossing.

[Adm.Spock]

ALs je de stack op slechts één CPU laat lopen gaat alleen die ene CPU in de stress. De andere CPU('s) hebben dan niets van doen met het berekenen van de stack.

Resultaat, je kan niet meer internetten, maar de server zelf loopt gewoon door.

[Verwijderd]

Tja dat de wetenschappers er als eerste achter komen is idd beter, maar ik was er geruster op geweest asl ze gelijk ook met iets van een oplossing waren gekomen.
Dit klinkt namelijk wel vrij ernstig en die kwaadwillende sujetten hebben echt niet zo heel veel tijd nodig om hier iets vervelends mee te doen.

edit:
Neo je was me net voor

"The only way to fix a problem that affects so many different systems in different ways is to widely publicise the problem."

Daar heeft ie imo wel gelijk in, er wordt nu waarschijnlijk al flink gebrainstormed over hoe dit snel en effectief op te lossen.

[Countess]

een quickfix bedenken voor dit probleem is vrij simple. een CPU limit stellen voor het hashen van netwerk packetjes (lieft voor ieder packetje afzonderlijk zodat alles gewoon door blijft draaien als er 1 paketje dwars ligt)
dit oplossen is iets voor de software/drivers schrijvers, en niet echt iets wat die wetenshappers hoeven te doen.

[Verwijderd]

Als je dat doet kan een 'hash-attack' in combinatie met een DoS (pakketjes met zo'n gevaarlijke hash gaan flooden) ook weer een gevaar vormen. Veel makkelijker is om gewoon een limiet te stellen aan het aantal cycles wat een pakketje mag gebruiken. Heeft het pakketje meer cycles nodig wordt het gewoon vernietigd o.i.d. aangezien het dan om een niet 'legitiem' pakketje gaat.

[trenjeska]

het gaat erom dat er gebruik wordt gemaakt van de meest vervelende waarden in het data-pakketje om het hash algorithme dat wordt gebruikt mee te laten rekenen. dus een pakketje dat iets meer rekentijd kost kan even of zelfs meer legitiem zijn dan een pakketje waarvan het zo berekend is.

[Guru Evi]

En wie gaat bepalen hoeveel cycles jij nodig hebt om een pakketje te hashen? Ik heb een 486 DX4 als router met Realtek netwerkkaart, heeft meer cycles nodig dan mijn AMD Athlon met Intel Gigabit netwerkkaart.

[avon]

Dit is inderdaad bedreigend, maar te voorkomen
door alleen hash paswoorden van bepaalde ip
adressen toe te staan.

Hierdoor wordt voorkomen dat onbekende computers
de servers gaan belasten.

Echter is het punt dat zoveel pc's/servers nog steeds
veel oudere exploits open hebben staan.... waarschijnlijk
is luiheid van de beheerder de grootste bedreiging.

[Defspace]

Dit gaat niet over hashes over passwords. Maar hashes over je IP Packetjes/netwerk packetjes. Elke computer met een netwerkaansluiting is dus een potentieel doelwit. Ook is hier weinig aan te doen behalve driver/hardware modificaties.

[pfismvg]

Dit gaat niet om pasword hashes denk ik. Meestal worden password hashes 1 keer berekend op de server en daarna opgeslagen in een database. het wachtwoord wat bij de client wordt ingetikt wordt door de client browser omgezet in een hash en daarna naar de server gestuurd en vergeleken met de hash in de database. Niet rekenintensief op de server dus.

artikel is errug vaag en waarschijnlijk gaat dit niet over het tcp/ip protocol maar over bepaalde services die er bovenop draaien (denk aan services als http smtp enz.)