Header-virussen omzeilen contentscanners

De systeembeheerders hebben er weer een kopzorg bij, het is namelijk mogelijk om de virusscanner op serverniveau te omzeilen, dit volgens een bericht van Valentijn Sessink op SecurityFocus. Het is namelijk zo, dat een gedeelte van het virus ongezien in de header kan meeliften en - tot nu toe - alleen geactiveerd kan worden met behulp van Outlook Express. Het virus wordt genegeerd omdat deze na meerdere carriage returns in de header staat, terwijl Outlook Express de karakters onterecht als end-of-line interpreteert. Hierdoor wordt het gedeelte na de carriage returns een bijlage en kan met behulp van code een attachement worden gestart zonder dat deze geopend is door de gebruiker. Voorlopig zijn alleen Outlook Express gebruikers van versie 5.5 en 6.0 het slachtoffer, maar andere mailprogramma's kunnen ook open staan voor deze bug. De aanwezigheid van deze bug is nog niet uitgebreid getest op andere platformen, mailprogramma's en virusscanners. Hoewel Microsoft al verschillende keren een bericht heeft gehad van Sessink, is er nog geen enkel respons uit Redmond gekomen met betrekking tot deze bug. Valentijn Sessink kwam als volgt op het spoor van deze bug:

My first attention was drawn by a virus that sent a long header starting with "MIME-Version: 1.0^MContent-Type: multipart/related;". This was January, 18. A Slashdot posting about the famous "begin " bug made me test out a couple of Outlook weaknesses; I remembered the "^M" posting and - well, here it is.

Captain Blythe was zo vriendelijk om ons dit bericht te submitten

Reacties (51)

Sjongejonge, een goede virusscanner kijkt naar de mail content en niet naar de header.
En het is geen bug, op zijn hoogst zoals in het artikel vermeld : weaknesses.

Het is wel een bug, en vet ook. Het punt is juist dat Outlook nu attachments ziet die er helemaal niet zijn - die de virusscanner dus ook niet kan zien.

Lees mijn oorspronkelijke stuk op Bugtraq nauwkeurig, en je ziet wat er mis kan gaan.

Over het verschil tussen een "bug" en "weaknesses" zou ik me verder bij Microsoft maar niet al te vrolijk maken.

Zelf dacht ik niet aan een weakness, maar toch aan een ontwerpfout in de mail-header, omdat er ongewenste informatie aan kan worden meegegeven.

[edit] Linuxman, ik heb nomaals artikel gelezen, en nog steeds ben ik ervan overtuigd dat we het niet alleen over een Outlook bug hebben. [quote]
maar andere mailprogramma's kunnen ook open staan voor deze bug
[/quote]

maar toch aan een ontwerpfout in de mail-header, omdat er ongewenste informatie aan kan worden meegegeven.

lees nou es goed waar het om gaat, de ontwerpfout zit in outlook omdat die een mail header interpreteert als attachment terwijl het gewoon een mail header is.

De systeembeheerders hebben er weer een kopzorg bij, het is namelijk mogelijk om de virusscanner op serverniveau te omzeilen

Ik ben het hier niet mee eens...aangezien een 'goede' systeembeheerder er ook voor zorgt dat op de clients/workstations de anti-virus definitions up to date zijn... en dit is helemaal niet moeilijk aangezien je de update heel gemakkelijk kan automatiseren door het via het login script te doen (KIX Login scripts).

Dus wat ik vind is dat dit zeker niet voor extra kopzorgen gaat zorgen aangezien als een systeembeheerder zijn werk goed doet alles al uptodate is en de virussen er op workstation niveau worden uitgepikt!

en daar gaat die 'goede systeembeheerder' de fout in, hij heeft alles up-to-date en gaat met een gerust hart naar bedje toe...

en dan komt daar een mailtje met een 'ongeldig attachment', de virusscanner ziet enkel een ongeldig attachment en scanned dit niet, want dit is geen attachment, helaas is iedereen outlook dat veregeten te vertellen; boom, en juist op schijnbaar veilige netwerken is de schade van een virus groter.

overigens eveneens een probleem van de huidige virusscanners, deze zoeken enkel op de profielen van bekende virussen, zodra ze anamolieën ontdekken laten ze dit doodleuk door, meen dat ook sircam hier gebruik van maakt.

Hoewel Microsoft al verschillende keren een bericht heeft gehad van Sessink, is er nog geen enkel respons uit Redmond gekomen met betrekking tot deze bug.

kijk, dat soort mededelingen vind ik eigenlijk nog veel verontrustender dan de virusmelding op zich...

Het is ook niet waar, MS heeft al eerder gezegd bezig te zijn met een patch voor dit probleem.

Die "begin" bug bijv. is een van de redenen waarom in NG's Outlook Express' nieuwslezer zo ongenadig afgefakkeld word.
Daar is al ruim 3 jaar geleden wat van gezegd, maar nog steeds heeft MS er niets aan gedaan.

Outlook Express is wat dat betreft nog steeds non-compliant met rfc's, en het verbaast me dan ook dat je zegt dat ze het wel weten.

Dat is zelfs een vrij standaard bericht. Dit is een van de grote voordelen die OpenSource heeft ten opzichte van bedrijven als M$. Zodra zoiets is gevonden in een opensource progje, is het lek binnen een uur ofzo gedicht. Lang leve BuqTraq's

maar, ik geef toe, ms krijgt wer een paar minpuntes hiervoor, en eudora krijgt er in mijn geval weer een paar bij

Eh ..

1) Eudora is zo ongeveer het meest onveilige mail-programma. Zi eook de Duitse c't van enige tijd geleden. Die kwam al meest onveilige eruit. Al die vermeende bugs (zoals het automatisch openen van attatchments) zitten namelijk meestal al lang niet meer in Outlook en Outlook EXpress, maar wel vaak nog wel in Euora.

2) Verder Open source is geen garantie dat bugs gevonden worden en 'gefixed'. Dat denken wel veel mensen, maar het tegendeel is waar.

Daar zijn verschillende oorzaken voor. Belangrijkste is wel dat veel mensen niet de tijd/kennis/interesse hebben om de code te gaan doorploegen op fouten en die bovendien te herstellen zonder ergens anders weer een lek te maken.

Mooi voorbeel dis het algemeen als zeer veilig bechouwde BSD. Zat al jaren een lek in waardoro je root kon worden. Was algemeen beken in de hackers-wereld. Is pas afgelopen zomer 'gefixed'. Na jaren!
En was toch gewoon open source ...

Let wel, dit is geen anti-Linux/OpenSource post of zo. Heb zelf Linux gebrukt (gebruik nu Solaris 8 UNIX) en schrijf bijna dagelijks code voor open source projecten.
Ik wil alleen waarchuwen voor het denken dat open source of een OS per definitie voor extra veiligheid zorgen.

Met open source en Linux moet je net zo goed blijven oppassen voor lekken en virusen, als met andere systemen en OS-en. Het blijft immers de gebruker die doorslaggevend is ...

Armin

\[off-topic]
oh ja, security through obscurity, microsoft zal niks zeggen totdat ze een oplossing hebben gevonden.
vind ik echt stom,
maar ja, dat is hier niet echt van toepassing.

Als mailprogramma's niet zo slim werden gemaakt dan had je hier toch geen last van? Als ze alleen text mail kunnen versturen, misschien met wat opmaak enzo, maar zonder scripting mogelijkheden dan is het toch heel veilig. Het doel van mailprogramma's is om te mailen, en daar heb je geen HTML mail, etc voor nodig, en wat je niet in de mail kunt stoppen doe je gewoon in een attachment, en die kun je dan weer zonder zorgen scannen.

Dat is dus ook wat er hier gebeurt, er wordt gewoon een attachment gemaakt met gevaarlijke inhoud.
Het verschil is dat het nog geen attachment is als het door de mailserver heen gaat. Daarom ziet de virusscanner in de mailserver hem ook niet.
Pas in de client aangekomen wordt een stuk van de header plots aangezien als attachment en 'ontstaat' er een gevaarlijk attachment.

Dat heet vooruitgang. Een auto is ook allang niet meer een ding voor van A naar B te rijden.

Ik vraag me af tot hoever je een groot programma kunt maken die 100% waterdicht is. Bugs heb je heel snel, gewoon door een combinatie van functionaliteiten.. jammer maar helaas.

Maar het blijft wel opvallend dat Outlook gewoon de kroon spant kwa non-veilige software..

Bugs heb je heel snel, gewoon door een combinatie van functionaliteiten.. jammer maar helaas

alleen soms had je bugs makkelijk kunnen voorkomen - zoals deze (lees de bugtraq posting over deze bug maar). De mail specs zeggen dat alleen het newline character geldig is, en outlook negeert deze standaard en doet alsof een carriage return character ook een newline is.

Alle virus scanners die dus het mail protocol kennen zien de attach dus niet - want die is er ook niet. Maar outlook volgt de standaarden niet, dus die vindt dat er wel een attachment is.

dom..

Alhoewel je inderdaad gelijk hebt dat dergelijke dingen vrij eenvoudig te voorkomen zijn, is je redenatie iets te simpel. De specs hebben het over een newline. Maar wat is een newline? Onder Windows is het een Carriage Return met een Line Feed. Onder Unix en Linux is het een enkele Carriage Return. Op de Macintosh is het een enkele Line Feed. Aangezien je natuurlijk ook mail kunt sturen tussen een Linux- en een Windows-pc zal Outlook soms berichten krijgen waarbij er als newline overal CR wordt gebruikt. Nu interpreteert hij dat als newline (wat op zich goed is) en dan krijg je dit soort bugs...

De specs hebben het over een newline. Maar wat is een newline? Onder Windows is het een Carriage Return met een Line Feed.

helaas pindakaas, dat had je gedacht
een newline is ASCII character 10, en die staat expliciet vermeld in de mail protocollen, dus je hele redenering gaat niet op.

Ik heb een tijdje met het NNTP protocol geprogrammeerd/gescript in PHP, en dat lijkt heel erg veel op de mail standaard. Voor zover ik weet wordt elke regel van de header afgesloten met \n en wordt de header zelf afgesloten door een lege regel.
Het bericht eindigde met .\r\n voor zover ik nog weet.

Hoe krijg je het dan in je kop om een mailer te schrijven die zich niet aan deze standaard houdt?

BTW: Dat dit niet te detecteren is is iets te simpel door de bocht: ik gebruik zelf Amavis-milter-perl, een opensource perl scriptje. Zou het niet HEEL erg simpel zijn om dat ding aan te passen zodat ie dezelfde bug aanneemt als MSOE?

Bugs heb je heel snel, gewoon door een combinatie van functionaliteiten.. jammer maar helaas.

mischien is dit juist het probleem waarom al die functionaliteit van VB em javascript html code in een mail. Als je iets mooi wil opmaken maak je er een PDF van ofzo en stuur je die mee

Helaas, twee-maal fout.

Outlook =/= Outlook Express, en dit bericht gaat niet over Outlook. Dat zijn twee hele verschillende programma's al doet de marketingnaam anders vermoeden.

Ten tweede is Eudora de koning van de onveilige programma's. Stond niet zo lang geleden in de Duitse c't een artikel over onveiliheid. Bedenk namelijk dat meeste virusschrijvers uiteraard voor Outlook of Outlook Express een virus gaan schrijven. Anders verspreid het viurus zich simpelweg te weinig, en dat is uiteraard niet de bedoeling van de virusschrijver.

Overigens geldt voor alle programma's dat de gebriuker de onveilige factor is, niet zozeer het programma. In tegenstelling tot vele mythes moet je nog altijd zelf het attatchment openen en starten bij Outlook en Outlook Express (en vrijwel elk ander mail-programma).

Armin

Ik zou maar niet te veel op linux boffen.
Over enkele jaren ontdekken die gozertjes uit Afrika, Rusland en Asie ook Linux, als ze het al niet hebben ontdekt, want Linux is gratis in tegenstelling tot Windows waar we flinke licentie-kosten voor moeten dokken. Mensen uit de minder bedeelde landen zullen dus gebruik gaan maken van Open Source- of gratis besturingssystemen zoals Linux. Wellicht zitten tussen die jongens ook virusschrijvertjes bij. En jawel, dan word linux ook onveilig. Kortom zolang je oppast met wat je opent en je virusscan up to date houd zal de schade, zelfs onder windows beperkt blijven.

Misschien een off-topic maar ik wou algabra er even op wijzen dat het Windows mailprogramma outlook niet virusgevoeliger is dan Linux.

De groeten

Inderdaad. Grootste veiligheids-risico is denken dat een OS je per definitie veiliger/minder gevoeliger maakt voor aanvallen van virussen en/of hackers.

UIteraard door het kiezen van een exotisch OS, waar minder virussen voor bestaan en minder lekken bekend van zijn (let wel dat is wat anders dan dat ze niet bestaan * ), kun je het risico verlagen, maar dat komt niet door het OS, maar door het feit dat het een 'exotisch' OS is.

Armin

*) mooi voorbeeld is het open source BSD. Men heeft enige maanden geleden een zeer enstige bug gefixed die er al jaren in zat, al enkele versies lang. De bug werd ook al vaak misbruikt door hackers (je kon er root door worden). Zo zie je maar ook open source en het algemeen zeer veilig geachte BSD is feilbaar ...
En dat het open source is en er vele bekwame mensen naar de code kijken, voorkomt niet dat bugs jaren blijven bestaan ondanks dat ze misbruikt worden.

Onzin. Er zullen vast programma's zijn die veel onveiliger zijn maar minder naar gekeken wordt...

Het lijkt erg off-topic maar je ziet hier heel opvallend het grote voordeel van het gebruik van XML.

Veel oude protocollen maken gebruik van constructies die tegenwoordig eigenlijk niet meer als erg jofel zouden worden beschouwd. HTTP gebruikt bijvoorbeeld newline constructies om onderdelen van een message te scheiden. Dat werkt op zich allemaal prima, als dan ook maar iedereen zich exact aan de standaard houdt. Dat is lastig. Newlines zijn helaas vrij vervelende dingen die op verschillende platformen verschillende karakter-samenstellingen kunnen zijn. Helaas zijn veel HTTP consumers echter nogal vergevingsgezind en accepteren ze varianten van deze newlines. Dat leidt tot verwarring, tot bugs en tot beveiligsgaten.

XML lost al deze onduidelijkheden op om drie redenen: (1) De syntax is erg duidelijk waardoor er geen twijfel kan bestaan over een interpretatie. (2) Whitespace speelt in principe geen rol in XML. En de belangrijkste: (3) gebruik van standaard tools zoals een XML parser.

Door de scheiding van een standaard syntax kan je in alle applicaties gebruik maken van componenten die werken op deze syntax. Een XML parser is hier een goed voorbeeld van. Een XML parser kan op zich zelf geperfectioneerd worden en toegepast worden in alle applicaties die gebruik maken van XML. Door deze abstractie kan je in een applicatie meer gebruik maken van standaard componenten waardoor je hoogst waarschijnlijk een grotere kwaliteit kan garanderen.

Als deze protocollen dus de XML syntax zouden gebruiken zou een dergelijke exploit waarschijnlijk kansloos zijn...

Newlines zijn helaas vrij vervelende dingen die op verschillende platformen verschillende karakter-samenstellingen kunnen zijn.

Zoals LinuxMan hierboven al zei is het newline character een ASCII character (nl. 10). Er is dus geen twijfel mogelijk over de intepretatie daarvan.

Een ander probleem is dat je het liefst wel een sluitings teken wilt hebben. Stel dat je dat niet hebt dan zullen je IO routines een stuk moeilijker in elkaar zitten omdat je i.p.v. op 1 teken (nl. de LF) moet gaan wachten tot er bepaalde XML tags voorbij komen. Je zou dus een input routine moeten gaan schrijven die niet meer regel georienteerd werkt maar naar tags gaat kijken. Dit maakt het geheel een stuk lastiger.

Stel: je vraagt een pagina op via HTTP. Er komt dan een verzoek in de vorm van:
GET / text/html


Hierna begint de server data te spuien (na de LF achter html). Als je ditzelfde zou willen doen met XML zou je gebruik moeten gaan maken van unbuffered I/O omdat je realtime wilt checken of er een XML sluitings tag tussen staat. Hierdoor verlies je het grote voordeel van buffered I/O en dus ook een stuk snelheid. Vergelijk het maar met een telnet verbinding waarbij elk karakter wordt verstuurt of per hele regel.

Je zou natuurlijk wel een soort van buffered I/O kunnen maken gebaseerd op XML tags. Maar dan zouden de I/O routines ineens een stuk meer moeten weten van het XML formaat.

Gewoon volgens standaarden werken lijkt mij al een hele oplossing. Zomaar van protocol omschakelen omdat het minder gevoelig zou zijn voor fouten is geen manier om dit soort problemen op te lossen. Ook XML parsers kunnen naar mijn idee wat 'gemakkelijk' met constructie fouten omgaan. Het feit dat browsers zich al niet aan de HTTP standaard met betrekking tot de tags houden zegt eigenlijk al genoeg.

Mwah, het HTTP protocol gebruikt bijvoorbeeld \r\n als afsluiting van een header. Terwijl de afsluiting van een regel op Unix/Linux slechts \n is. Op MS Windows is hij weer \r\n. Dat zijn dus best wel verwarrende dingen . (als je de term newline gebruikt zijn er uiteraard geen verschillen. De term newline is helaas overloaded in dit geval ).

Toevallig had ik zelf een keer een implementatie gemaakt die met \n werkte. Deze moest tegen .NET aanpraten. In beta 1 werkte dit nog goed, in beta 2 ontdekte ik de vergissing pas.

Verder zie ik het probleem van de gebufferde IO niet zo. Dit is typisch weer een component probleem. Als je een goede XML parser gebruikt met bijvoorbeeld een SAX interface kan deze volgens mij nog steeds gebruik maken van gebufferde IO. Deze parser zal toch al deze routines moeten hebben om op een efficiente manier met het parsen van XML om te gaan. Pak maar eens een SAX parser erbij: als een document nog niet helemaal binnen is, heb je toch al een groot deel van het document wat al wel binnen is, binnen gekregen via je ContentHandler.

Het grote verschil tussen een parser die een HTTP message moet parsen en een parser die een XML message moet parsen is dat de eerste kennis heeft van de toepassing van de syntax. Je kant deze dus in feite alleen gebruiken voor een HTTP protocol (of iets wat daar sterk op lijkt). Een XML parser kan je voor ontzettend veel doeleinden gebruiken en daarom kan er extra veel aandacht besteed worden aan dat component. Ook kan je standaard validatie gebruiken tegen bijvoorbeeld een DTD of een XML Schema.

Uiteraard kan die nog steeds bugs bevatten, maar omdat het een generieke implementatie is, is het de moeite waard om te investeren in de kwaliteit van de implementatie. Vanwege de generieke toepassing zullen fouten waarschijnlijk ook sneller worden gevonden.

Ik gebruik al heel lang geen OUTLOOK meer,
het zo onveilig als de pest, daarnaast zit ik niet achter een computer of erzijn meerderen die aan mijn computer mogen zitten.
Web-based mail server komt bij mij goed uit, maar ik weet dat sommige daar inderdaad veel last van heeft.

Was niet flame bedoeld hoor, was gewoon een uitting, misschien dat er ook anderen zijn die net als ik niet vast op een PC werken...

OutLook? Look Out

Ik vind dat MS weer misbruik heeft gemaakt van zijn machtpositie. Een mail reader/organiser moet zorgen dat die de mail weergeeft of opslaat en verder gewoon van het SYSTEEM afblijft!
Maarja MS zou MS niet zijn als die niet in je OS intergreert
Je systeem gaat toch ook niet plat als je een mp3 hebt gedraaid? Niet soms?!
* Eh, niet vanuit WMP dan...

foutje in mijn tekst?...

Tja ... misschien is Netscape-mail een alternatief voor je? Of een web-based mailbox?

Ik ben het niet met je stelling...
Microsoft levert windows gewoon standaard met een e-mail client welke weer gebruikt maakt van gedeelten van het OS gebruikt maakt..ik vind dat echt geen misbruik van de machts postitie dat noem ik gewoon effiicientie want doordat ze delen van het OS gebruiken hoeven ze die code niet weer opnieuw in Outlook Express te schrijven of te copy-en....volgens mij heet dat ook wel object georienteerd programmeren..(gebruik maken van classen)!

En word je soms door microsoft verplicht om Outlook Express te gebruiken..?? Nou ik dacht het even niet.. je bent vrij om elke mail client te gebruiken die er is...dus ik vraag me af wat je zit te ..... over misbruik van de machts positie!

Een mail reader/organiser moet zorgen dat die de mail weergeeft of opslaat en verder gewoon van DE SYSTEEM afblijft!

ikke niet begrijp
jij bedoelen HET SYSTEEM... ??

waarom houden die eikels zich in godsnaam bezig met die f*cking virussen
kunnen ze niet iets nuttig doen zoals een mooie site maken hebben we tenminste geen last van!

Maar dit kan je ook als nuttig zien. Zolang die virii niet gevaarlijk zijn, is het enkel een hulp om de beveiliging beter te maken. Maar lekken in de beveiliging zullen er altijd blijven, de perfecte beveiliging bestaat niet.

AAAAAh had ik maar naar mijn moeder geluisterd leer een vak (putjesschepper!!!!!!!1) en blijf van die computers af niets dan ellende (ben zelf een systeem beheerder) vanaf morgen alleeen nog maar netwerkloze omgevingen en geen elec mal)