Falsk virus-advarsel skaber kaos i it-danmark
I en tid hvor Downadup-ormens hærgen har givet it-sikkerhedsansvarlige dårlige nerver, giver en advarsel om farlig malware på en række websider ekstra meget sved på panden.
Men advarslen skyldes en fejl, og der er ingen fare på færde, lyder det fra sikkerhedsfirmaet CSIS.
Hos alle virksomheder, der bruger antivirus-produktet Etrust fra CA, popper advarsler om farlig kode op på stribe i disse timer, for eksempel ved et besøg hos Version2.dk eller Ekstrabladet.dk, der er Danmarks mest besøgte nyhedsside.
»Problemet skyldes, at CA har sjusket med opdatering af deres signaturer til exploit-modulet. Så det bliver for generelt, hvad den reagerer på af obfuskeret javascript-kode, og dermed bliver fuldstændigt harmløse javascripts hængt ud som farlige,« forklarer Peter Kruse fra CSIS.
Med andre ord ser Etrust-antivirus rødt, når den falder over helt gængse og meget populære javascripts, som for eksempel mootools-release-1.11.js, AC_RunActiveContent.js og jquery-1-2-6-pack.js.
»Vi er blevet kontaktet af rigtig mange virksomheder i Danmark, og mange af dem store virksomheder, som reagerede på advarslen. De websider, der bliver hængt ud, har også fået mange henvendelser fra bekymrede læsere,« siger Peter Kruse.
Politiken.dk og Ekstrabladet.dk er blandt dem, der udløser den falske advarsel, men mange andre websider vil også være ramt, mener sikkerhedskonsulenten.
»Det er populært at bruge disse typer af javascripts til at vise indhold dynamisk, så det inkluderer sandsynligvis en masse andre websider, som vi ikke har kendskab til endnu,« siger han.
CA har lovet hurtigst muligt at rette fejlen med en opdatering. Virksomheder med Etrust Antivirus skal således ikke selv gøre noget for at løse problemet, udover eventuelt at informere medarbejderne om sagen.
Kommentarer (16)
Personligt mener jeg fejlen ligger hos dem, der bruger det hjemmestrikkede 'packer', frem for den anerkendte gzip standard.
Det hjemmestrikkede 'packer', er jo stærkt obfuskeret, se f.eks. Version2's brug:
http://www.version2.dk/modules/util/include/mootools-release-1.11-compre...
Det er de samme metoder der bliver brugt i forbindelse med udbredelse af malware.
Det giver, i mine øjne, et problem at skelne hvornår det er lovlig obfuskering, og hvornår det er malware.
Jeg er ikke overrasket over det (false positives) måtte komme, men jeg vil mene at løsningen er at bruge ikke obfuskeret javascript, frem for at indbygge mere og mere problematiske algoritmer i antivirus programmerne.
Derudover giver dette unødige overforbrug af javascript performanceproblemer (=anti grøn IT) på ældre maskiner, herunder min, men jeg kan heldigvis køre uden javascript.
-
0 -
0
Jeg må indrømme, at jeg har svært ved at forstå, hvorfor det skulle være nødvendigt at obfuskere JavaScript på et legitimt websted. Men det kan være, at der er webdesignere, som kan forklare det?
Der kan næppe være en stor ydelsesgevinst ved at pakke nogle få kilobyte scriptkode?
-
0
-
0
Jeg må indrømme, at jeg har svært ved at forstå, hvorfor det skulle være nødvendigt at obfuskere JavaScript på et legitimt websted
Jeg har gentagne gange spurgt om det samme i dk.edb.webdesign.clientside gruppen.
Det eneste svar jeg får er at det 'fylder mindre' (båndbredde).
I mine øjne er der en god betragtning hvis man har dial-up modem ;)
Af diplomatiske årsager tror jeg ikke jeg vil udtale mig om det generelle vidensniveau (i DK).
-
0
-
0
Ideen med kode obfuscation er oftest, at man ikke er interesseret i at andre umiddelbart kan læse og forstå koden. Intet forhindre folk i at kopiere koden og bruge den - den virker jo fint selv om den er obfuscated, men det er bestemt meget besværligt at genbruge dele af koden, eller bygge videre på den.
Udvikler man i Java, .NET eller som ovenstående eksempel i JavaScript, er det utroligt nemt at få adgang til kildekoden. JavaScript er direkte læsbart, og Java samt .NET bliver ved kompilering til ByteCode/MSIL kode, som nemt kan reverse-engineeres. Dérfor er det nødvendigt at benytte obfuscation - det er en simpel form for beskyttelse af den kode man har produceret. En dygtig koder/hacker kan nok sagtens genskabe koden til noget der kan genbruges, men det tager meget længere tid, og man vil ikke være i tvivl om, at virksomheden der har produceret koden, ikke er interesseret i at andre ændre på den.
-
0
-
0
Ideen med kode obfuscation er oftest, at man ikke er interesseret i at andre umiddelbart kan læse og forstå koden
Hvorfor er alle kommercielle virksomheder panisk bange for, at 3. part kan læse med over skulderen? Er det ikke mere et spørgsmål om, at man ikke ønsker, at udstille sine manglende evner til offentligt skue!?
På mit arbejde ville det ikke gøre nogen forskel, om vi havde adgang til koden eller ej; vi ville stadigvæk lave en service aftale med leverandøren, med den ekstra sikkerhed det giver os. Skulle man vælge mellem to identiske produkter, kan det ikke afvises, at det ville være et plus for den leverandør, hvis tilbud omfattede adgang til koden.
-
0
-
0
Jeg har gentagne gange spurgt om det samme i dk.edb.webdesign.clientside gruppen. Det eneste svar jeg får er at det 'fylder mindre' (båndbredde). I mine øjne er der en god betragtning hvis man har dial-up modem ;)
Du har ikke overvejet at se det fra serversiden? Det er nok der det er mest interessant at spare båndbredde. Douglas Crockford (og jeg håber vi kan være enige om at hans vidensniveau når vi snakker javascript er ok) anslår at hans minifier halverer størrelsen af filerne.
Google Maps serverer lige omkring 100 KB javascript (og det bliver brugt både på maps.google.com og på alle de sider der har et indlejret google-kort). Hvis de sparer 100 KB per besøgende, og vi pessimistisk anslår at 10 millioner mennesker dagligt ser et google-kort på nettet bliver det da til en terabyte om dagen.
-
0
-
0
Responstiden betyder også meget, der er lidt information om det på.
http://developer.yahoo.com/yui/compressor/
At der bliver lagt en gzip ovenpå er fint, men iflg. HTTP spec kan man ikke gå ud fra at alle har adgang til dette.
De fleste moderne browserer kan håndterer gzip, men der kan være proxy'er indimellem som fjerner Accept-Encoding header fra HTTP requests, hvorfor gzip ikke nødvendigvis kan bruges. Derfor kan det give mening af komprimerer kilden ved at 'compress' den; da modtageren ellers vil modtage JavaScript filer der indeholder kommentarer og komplette variabel/funktions navne.
-
0
-
0
I det aktuelle tilfælde med mootools er obfuskeringen udelukkende af pladshensyn, da det leveres med en open source licens og er frit tilgængeligt på http://mootools.net/download.
På ovennævnte side kan vi så også se, at man sparer 32 KB med den komprimerede udgave i forhold til den letlæselige version.
Med Javascript har jeg personligt altid haft det sådan lidt ambivalent mht. at spare på pladsen - filen bliver jo cachet i langt de fleste tilfælde og det er således kun ved første besøg på sitet, at den hentes - og så er 32 KB ekstra jo ikke alverden.
På den anden side kan man - med det publikum Version2 har - ikke afvise, at nogen faktisk ville synes om dette hensyn til brugernes båndbredde (og brokke sig, hvis det ikke blev taget).
Mht. obfuskering for obfuskeringens skyld, så synes jeg, det er enormt irriterende. Jeg har været ude for at få leveret noget Javascript kode, som ikke fungerede med vores site - og når man så kigger i koden er den ikke blot obfuskeret med variabelnavne, men også url-encoded og andre ting, som skulle eval'es - dvs. man påfører klienten mere processering end nødvendigt, blot så det bliver mere besværligt (men så sandelig langt fra umuligt) at reverse-engineer'e.
Sidstnævnte type er nu forment adgang til sites, jeg administrerer.
-
0
-
0
Jeg kan ikke sige andet end jeg er enig nærmest helt igennem. Man gør scriptet ulæseligt, og sparer noget plads. Derefter bruger man et andet script, som bruger plads ...hm... og hukommelse...? til at pakke det ud. det virker ikke specielt genialt. Der er en del flere kodelinjer i HTMLen, end designet berettiger til, bl.a. sjovt nok inline JS. Så forstår ikke, man starter helt oppe i tredje lag med at ville spare plads (og lader det gå ud over hastigheden). Det er da uendelig dårlig kodeskik. At en obsfucater er mistænksom, er jeg også enig i, det skjuler kode, som skal køres hos mig, man er da dum, hvis ikke man finder det mistænkeligt. Det er helkler ikke standard, og vil bestemt aldrig blive det. Mit princip er, aldrig lægge noget ud, som man i virkeligheden gerne vil skjule for andre. En hjemmeside skal kunne stå inde for alt indhold - også koden.
-
0
-
0
Man gør scriptet ulæseligt, og sparer noget plads. Derefter bruger man et andet script, som bruger plads ...hm... og hukommelse...? til at pakke det ud.
Øh, nej. Javascriptet kører normalt selv om det er minificeret.
-
0
-
0
Du har ikke overvejet at se det fra serversiden?
Jeg er inkarneret servermand :)
Min egen løsning er at lægge .js filer i gzippet stand på min server.
Det sparer mere plads end det hjemmestrikkede, koster ikke ekstra server ressourcer for klineter, der understøtter gzip - selv Lynx understøtter gzip.
På brugersiden er der stort set ingen performance penalty, da g(un)zip er 'wired ind' i browseren.
Brugen af obfuscated javascript implecerer netop det problem som bla. Version2 har oplevet.
Hvis et antivirusprogram skal tjekke skidtet on the fly, skal det i virkeligheden 'dekomponere' scriptet i de niveauer, der nu måtte være.
Hvis man generelt 'ser bort fra' packer i antivirus sammenhæng, åbner man en god mulighed for malwareproducenter til at benytte packer som indkapsling til deres skrammel.
Som du kan udlede af min løsning, er der tale om grøn IT med besparelser på alle fronter/server,klient,båndbredde) , uden at obfuskere javascript.
Det samme princip med 'for zippede filer' gælder i øvrigt også .html og .css - osv - filer.
At man ikke evner at udnytte gzip, som er en standard siden sidste årtusinde, synes jeg er et ringe argument for at hjemmestrikke en javascript 'packer'.
Men som de siger, når jeg brokker mig over hastigheden - Køb dig en nyere og kraftigere PC.
Gu vil jeg da ej købe en ny PC, blot for at læse Version2.
Version2 er komplemt umulig for mig med javascript enabled, men så længe jeg kan læse den uden javascript, går det nok.
Hvis den bliver umulig at læse, bliver udfaldet ikke en ny PC, men at Version2 mister en læser.
-
0
-
0
"Øh, nej. Javascriptet kører normalt selv om det er minificeret."
Jeg er ikke helt med. Tales der ikke om en obfuscating, altså sløring af koden, og ikke kun at fjerne white-spaces?
Hvis du har optimeret dit script, og her mener jeg selve koden, så vil en ny kode, som lægges ovenpå for at sløre det, vel også bruge ekstra ressourcer, og det kommer alene den, som har lavet scriptet til gavn, ikke brugeren, som skal køre scriptet.
Hvis man ønsker at skjule koden, så er fremgangsmåden forkert, for har man først lagt noget op, er det ikke skjult mere.
Er meningen at øge hastigheden af download, så vil GZIP virke for alle de browsere, vi har testet, her indbefattet Lynx i 2-3 forskellige versioner. Derudover er der jo det med HTMLen, hvor der er en del fyldkode. Det vil være mere logisk at rette det først.
Ydermere, så er GZIP en standard, det er en stacker ikke. Jeg vil sige, har man brug for at indsætte en stacker/packer aht. hastighed, så har man kodet forkert fra start.
V2s hjemmeside er så ikke blandt de værste, måske endda langtfra når man ser, hvordan andre indlejrer reklamer fra 3.part, så der skal mega-kommunikeres imellem 2 servere, og har de dér tænderskærende irriterende grønne links i selve teksten. V2-designet er stadig clean, og ikke mindst uden invaderende reklamer, det batter en del hos mig. Men hver gang man indfører en ting, som er "mistænkelig" eller ikke brugbar for brugeren, så tager det jo noget af imaget. Eller man kan sige, det virker sådan lidt klodset rent kodemæssigt.
-
0
-
0
Jeg er ikke helt med. Tales der ikke om en obfuscating, altså sløring af koden, og ikke kun at fjerne white-spaces?
Der er tale om en komprimering af selve koden, forstået på den måde, at ikke nok med, at whitespaces er fjernede, variabel- og funktions-navne er også forkortede i en sådan grad, at koden er gevaldigt svær at læse.
f.eks.
[code=javascript]
function getThisVeryLongDescriptionFunction() {
var variablename = 25;
}
[/code]
bliver til
[code=javascript]
function a(){var b=25;}
[/code]
For browseren er det det samme, men for en menneskelæser er det ikke. Det er altså ikke - i vores tilfælde - obfuskering for obfuskeringens skyld, men udelukkende pga. størrelsen af script-filen.
Ydermere, så er GZIP en standard, det er en stacker ikke. Jeg vil sige, har man brug for at indsætte en stacker/packer aht. hastighed, så har man kodet forkert fra start.
Det kan der være noget om, men vi på Version2 har ikke selv kodet mootools og når mootools leverer to versioner - udviklingsversionen og den komprimerede - så vælger vi naturligvis at lægge den mindste op.
Det kunne være, at vi ville få yderligere gevinst af at gzippe, men umiddelbart ser vi ikke en grund til at ændre på noget, vi ved fungerer, når det ikke er skriger-til-himlen dumt :)
/Jan
Projektleder, Version2
-
0
-
0
==
På den anden side kan man - med det publikum Version2 har - ikke afvise, at nogen faktisk ville synes om dette hensyn til brugernes båndbredde (og brokke sig, hvis det ikke blev taget).
==
Det har du helt ret i. Jeg skriver fx dette fra en lounge i Toronto lufthavn. Båndbredden til Version2 er ikke overvældende.
-
0
-
0
Der er tale om en komprimering af selve koden
Der er ikke kun tale om 'komprimering af koden', som du skriver.
Der også tale om at det 'komprimerede kode' skal køres 2 gange.
Hvis man kigger på 'packer' kontruktionen, så ser den sådab her ud:
eval(function(p,a,c,k,e,d)+en helvedes masse skrammel.
Det betyder, at klienten først kører en eval af hele skidtet, og denne eval danner så det rigtige javascript, og først DERFTER kan det køres (hvis det virker).
Der er med andre ord tale om et script, der danner et script, der køres.
Det er denne 'sourcekode generering', der er årsagen til overforbrug af ressource på klienten.
Jeg har en lille javascript evaluator kørende her:
http://w-o-p-r.dk/wopr.tools/wopr.javascript.eval.asp
Her kan man indsætte koden inde i den første eval, og få vist det 'dekomponerede' javascript.
Det kunne være, at vi ville få yderligere gevinst af at gzippe
Man vil ikke få særlig fordel ved yderligere af gzip'e, da koden i forvejen er 'randomificeret'.
når det ikke er skriger-til-himlen dumt
Det er nok et lidt hårdt udtryk.
Hvis man vender den om, og angriber den ud fra 'faglig stolthed', så er der i det hele taget en kedelig tendens til at sub-optimere vha disse monster 'frameworks', som også jQuery.
Det svarer til at finde en 'all-mighty-all-functions-in-one-swiss-army-knife' selvom man kun har brug for en neglefil.
Med sub-optimering mener jeg, at man påtvinger en download af op mod 200KB for at spare et par bogstaver.
Her er f.eks. et svar ovre fra .clienside gruppen, hvor der er en der spørger om at skifte farve:
<a href="#" onmouseover="$(this).addClass('selected')" onmouseout="$(this).removeClass('selected')" > uden jquery, så skal du have fat i document.getElementById(this).className = 'selected'
Bemærk her, at for at undgå at kende til/bruge document.getElementById, anbefaler posteren at benytte jQuery som udgangspunkt.
Jeg lavede i øvrigt en test af jQuery, med zip ctr. packer.
Jeg fjernede kommentarerne, og gzippede skidtet, og her fyldte gzip versionen mindre end den 'packede' verseion.
Nå, men det med overforbrug.
Man kan spare [b]væsentlig[/b] mere plads/båndbredde, ved kun at benytte den delmængde af disse 'frameworks', som man rent faktisk [b]bruger[/b]
Nu kan det godt være jeg lyder lidt hård, men baggrunden er netop Version2's slogan:
IT for professionelle.
I mine øjne er disse overforbrug ikke 'professionelle'.
Jeg glemte at komme ind på malware problemstillingen med brug af eval, men jeg går ud fra, at man kan udlede, at antivirusfirmaer bliver nødt til at implementere en fuld javascript parser, hvis man skal undersøge hvad der ligger inde i eval (her = packer).
Eventuelle <script>/<iframe> attacks, kan ikke direkte udeledes af den indledende javascriptkode.
Som tidligere nævnt, vil jeg ikke skyde skylden på antivirusfirmaer ved disse problemer, som nævnt i artiklen, men web-høkerne.
Hvis man kunne oplære folk til at kode uden eval, og får browserproducenterne til helt af fjende denne funktion, ville malware folket få meget sværere ved at lave phishingsites m.v.
Hvis man samtidig fjernede eval funktionen i PHP, ville man effektivt 'disable' en helvedes masse PHP-bot'er, og så ville verdenen se endnu bedre ud.
-
0
-
0
Hvis man kigger på 'packer' kontruktionen, så ser den sådab her ud: eval(function(p,a,c,k,e,d)+en helvedes masse skrammel.
Det er også rigtigt. Beklager mine hidtidige udtalelser - jeg kiggede på mootools' forskellige komprimerede udgaver direkte fra mootools.net og ikke den, vi faktisk bruger her på sitet, som ganske rigtigt er PACKER-komprimeret.
Jeg får nogen til at kigge på det og udskifte med en bedre løsning.
/Jan
Projektleder, Version2
-
0
-
0
Tilføj kommentar
