mboost-dp1
unknown
if Netscape exist then del c:\program files\netscape\*.*
Jeg troede ellers at Microsoft havde nok i de monopolsager der har jagtet dem de sidste mange år.
Men på den anden side set - jeg kan godt se den umiddelbare begrundelse for at lukke af så andre programmer ikke kan rode i kernen. Det må unægteligt højne sikkerheden (givet at det ikke kan crackes, hvilket så ikke er tilfældet).
Men på den anden side set, så kan det heller ikke nægtes at Microsoft dermed står stærkere med deres eget udviklede software, såfremt det har adgang til kernellen - uanset hvilken type software vi som sådan snakker om. Hvis det altså er tilfældet at kernen skal kunne tilgås fra MS' egne programmer, det har jeg ikke lige kunne se at der stod noget om i linket...
Som Toulouse siger:
"It is more important to prevent the installation of malicious software than it is to allow third-party vendors, no matter what the software, to extend the kernel"
Ja, men nu er det jo desværre sådan at det ikke er lykkedes MS at holde de stygge drenge for døren.
Men PatchGuard er jo stadigvæk ret nyt, og mon ikke Vista-versionen af PatchGuard bliver noget mere effektiv end WindowsXP x64'erens?
En af de gode ting man skal huske på, er jo iøvrigt også at rootkits bliver aflivet, hvis PatchGuard kommer til at fungere helt tiptop.
Jeg troede ellers at Microsoft havde nok i de monopolsager der har jagtet dem de sidste mange år.
Men på den anden side set - jeg kan godt se den umiddelbare begrundelse for at lukke af så andre programmer ikke kan rode i kernen. Det må unægteligt højne sikkerheden (givet at det ikke kan crackes, hvilket så ikke er tilfældet).
Men på den anden side set, så kan det heller ikke nægtes at Microsoft dermed står stærkere med deres eget udviklede software, såfremt det har adgang til kernellen - uanset hvilken type software vi som sådan snakker om. Hvis det altså er tilfældet at kernen skal kunne tilgås fra MS' egne programmer, det har jeg ikke lige kunne se at der stod noget om i linket...
Som Toulouse siger:
"It is more important to prevent the installation of malicious software than it is to allow third-party vendors, no matter what the software, to extend the kernel"
Ja, men nu er det jo desværre sådan at det ikke er lykkedes MS at holde de stygge drenge for døren.
Men PatchGuard er jo stadigvæk ret nyt, og mon ikke Vista-versionen af PatchGuard bliver noget mere effektiv end WindowsXP x64'erens?
En af de gode ting man skal huske på, er jo iøvrigt også at rootkits bliver aflivet, hvis PatchGuard kommer til at fungere helt tiptop.
#3 du har ikke læst nyheden der var her for ikke så længe siden om Blue Pill rootkitten der lægger sig i virtualiseringens laget under OS'et ?
se http://newz.dk/forum/item/65415/ og http://newz.dk/forum/item/66132/
se http://newz.dk/forum/item/65415/ og http://newz.dk/forum/item/66132/
Det lyder som en fin måde at sige:
"Tak for alt jeres hårde arbejde med at holde vores skude oven vande, uden jer var vi helt sikkert synket, men denne her gang tror vi at vi har en bedre løsning, så vi har ikke brug for jeres arbejde mere."
"Tak for alt jeres hårde arbejde med at holde vores skude oven vande, uden jer var vi helt sikkert synket, men denne her gang tror vi at vi har en bedre løsning, så vi har ikke brug for jeres arbejde mere."
Det er da for latterligt. Først er Windows for usikkert, nu er det for sikkert - de kan satme næsten ikke gøre noget mere, uden at andre kommer efter dem for at have monopol.
Hvis de mener de har lavet en funktion som kan holde "ondt" ude af kernen, men som så samtidigt kommer til at holde "de gode" ud også, så lade dem dog det. Måske er det ikke 100% sikkert endnu, måske bliver det det aldrig, men det er da bedre end ingenting.
Hvis bil fabrikanterne fandt en måde hvorpå man kunne gøre biler mere sikre og dermed undgå bilulykker, skulle lægerne så også sagsøge dem for tabt fortjeneste? Nu må de altså styre sig.
Hvis de mener de har lavet en funktion som kan holde "ondt" ude af kernen, men som så samtidigt kommer til at holde "de gode" ud også, så lade dem dog det. Måske er det ikke 100% sikkert endnu, måske bliver det det aldrig, men det er da bedre end ingenting.
Hvis bil fabrikanterne fandt en måde hvorpå man kunne gøre biler mere sikre og dermed undgå bilulykker, skulle lægerne så også sagsøge dem for tabt fortjeneste? Nu må de altså styre sig.
hurra for en omvendt pandora's æske.... Man kan altid finde en måde at komme ind på... Så hellere have noget sikkerhedssoftware som kan beskytte, hvis man alligevel ikke kan forhindre... og helt ærligt er det en umulig opgave at lave noget som ikke kan crackes... Det er bare endnu en af MS' "halv-røvet" ideer til sikkerhed...I stil med windows firewall og det der anti-spyware program de havde gang i... Ingen af delene virker jo... Så hurra for et skib fyldt med huller...
#7
Hvis det er en umulig opgave at lave noget der ikke kan crackes, kan det så ikke være ligegyldigt om det er Microsoft eller Symantec der har lavet det software der skal crackes? Man må da under alle omstændigheder regne med at Microsoft ved mere om hvordan deres kerne er bygget op da de har adgang til dens kode, så jeg vil nu mene at de burde være bedre til at lukke for deres egen kerne, end et tredjepartssoftware er.
Desuden synes jeg også at Windows i forvejen er så dyrt at jeg ville have det helt fint hvis jeg ikke var nødsaget til at købe en sindssygt dyr sikkerhedsløsning ved siden af, det vil da kun være bedre for forbrugeren. :)
Hvis det er en umulig opgave at lave noget der ikke kan crackes, kan det så ikke være ligegyldigt om det er Microsoft eller Symantec der har lavet det software der skal crackes? Man må da under alle omstændigheder regne med at Microsoft ved mere om hvordan deres kerne er bygget op da de har adgang til dens kode, så jeg vil nu mene at de burde være bedre til at lukke for deres egen kerne, end et tredjepartssoftware er.
Desuden synes jeg også at Windows i forvejen er så dyrt at jeg ville have det helt fint hvis jeg ikke var nødsaget til at købe en sindssygt dyr sikkerhedsløsning ved siden af, det vil da kun være bedre for forbrugeren. :)
8# MS og sikkerhedsløsninger har jo ikke ligefrem gået hånd i hånd? Sådan som jeg forstår det, lukker patchguard bare af for kernen, men hvis noget kommer derind er man fucked, hvorimod Symantec er aktiv beskyttelse. Og her snakker vi om at komme forbi patchguard og ikke symantec's produkt. Jeg siger ikke at symantec's produkter er perfekte, men jeg tror mere på at de ved hvad de laver frem for ms... Og nu har ms jo ikke ligefrem været så hurtige til at lave sikkerhedsopdateringer, hvorimod symantec tit har en opdatering klar i løbet af et døgn. Bare se på windows firewall og IE6? MS' u-crackbare ting overlever aldrig mere end et døgn før de bliver cracked...Se winxp? tog hvad...under 12 timer at få det ordnet, og ifølge MS var det ikke til at cracke...
Det kommer netop ikke forbrugeren til gode, når MS laver noget sikkerhedssoftware. Det giver folk en falsk fornemmelse af tryghed og usårlighed, og når uheldet er ude og man bliver angrebet af vira, så er det bare surt...
Det kommer netop ikke forbrugeren til gode, når MS laver noget sikkerhedssoftware. Det giver folk en falsk fornemmelse af tryghed og usårlighed, og når uheldet er ude og man bliver angrebet af vira, så er det bare surt...
Jeg synes ikke rigtigt man kan være i tvivl om at vi står med et stykke misbrug her. Ikke nødvendigvis monopol misbrug overhovedet, jeg synes egentligt ikke det her er relevant i forhold til monopolisering, ikke mht. sikkerhedssoftware ihvertfald.
Der hvor problemet måske kommer frem er konkurrence på andre områder, f.eks. webservere, der har stor fordel af at kunne lave et par kernel hooks, især på et os som windows der har så sløv en thread implementation som det nu har.
Såvidt jeg husker bruger IIS kernel hooks, sig endelig til hvis jeg tager fejl, men hvis den gør det, så har vi i høj grad at gøre med et stykke alvorligt monopol misbrug.
(Update)
Jeps, tjekkede wikipedia, IIS bruger en kernel baseret http daemon (der tager request of forwarder dem til userspace applikationen.)
Jeg synes ikke rigtigt der kan være nogen tvivl om at MS er gået for langt.
Der hvor problemet måske kommer frem er konkurrence på andre områder, f.eks. webservere, der har stor fordel af at kunne lave et par kernel hooks, især på et os som windows der har så sløv en thread implementation som det nu har.
Såvidt jeg husker bruger IIS kernel hooks, sig endelig til hvis jeg tager fejl, men hvis den gør det, så har vi i høj grad at gøre med et stykke alvorligt monopol misbrug.
(Update)
Jeps, tjekkede wikipedia, IIS bruger en kernel baseret http daemon (der tager request of forwarder dem til userspace applikationen.)
Jeg synes ikke rigtigt der kan være nogen tvivl om at MS er gået for langt.
#9
Fedt at give dårlig rating for at have en anden mening end dig.
Bare fordi MS ikke altid har været lige så heldige med deres sikkerhed betyder det vel ikke at de aldrig nogensinde vil kunne lave et nogenlunde sikkert produkt. De lærer vel af deres fejl ligesom alle andtre?
Folk brokker sig evig og altid over den lave sikkerhed, men når de så prøver at lukke af for en enorm sikkerhedsrisiko, så prøver de bare at holde konkurrenterne ude? Det er da også noget af en balancegang hvis de skal sørge for at lukke nogle bestemte godsindede programmer ind, samtidig med at de skal sørge for at holde ondsindede programmer ude, det lyder hverken muligt, eller rimeligt i mine ører må jeg sige. Det vil jo kræve at alle godsindede programmer får et form for sikkerhedscertifikat, og det må så ikke komme videre til dem der skriver ondsindet kode, jeg tror ikke på det.
Jeg må nok indrømme at jeg ikke på nogen måde har ondt af Symantec i den her sag. Det svarer da til at have ondt af forsikringsfirmaerne hvis de mistede alle kunderne til deres bilforsikringer fordi alle folk holdt op med at køre galt... ?
Fedt at give dårlig rating for at have en anden mening end dig.
Bare fordi MS ikke altid har været lige så heldige med deres sikkerhed betyder det vel ikke at de aldrig nogensinde vil kunne lave et nogenlunde sikkert produkt. De lærer vel af deres fejl ligesom alle andtre?
Folk brokker sig evig og altid over den lave sikkerhed, men når de så prøver at lukke af for en enorm sikkerhedsrisiko, så prøver de bare at holde konkurrenterne ude? Det er da også noget af en balancegang hvis de skal sørge for at lukke nogle bestemte godsindede programmer ind, samtidig med at de skal sørge for at holde ondsindede programmer ude, det lyder hverken muligt, eller rimeligt i mine ører må jeg sige. Det vil jo kræve at alle godsindede programmer får et form for sikkerhedscertifikat, og det må så ikke komme videre til dem der skriver ondsindet kode, jeg tror ikke på det.
Jeg må nok indrømme at jeg ikke på nogen måde har ondt af Symantec i den her sag. Det svarer da til at have ondt af forsikringsfirmaerne hvis de mistede alle kunderne til deres bilforsikringer fordi alle folk holdt op med at køre galt... ?
Jeg synes, det er helt fint, hvad MS gør. De skal jo trods alt have en chance for at gøre deres system sikkert. Dog synes jeg, de skal åbne for muligheden for, at brugeren selv kan slå det patchgard fra og installere sin 3dje-parts-løsning. Det ville gøre default-windows ude i verden sikrere, og Hr. Jensen ville stadig kunne bruge sin Symantec-løsning.
Så længe man kan patche sig ud af det, ser jeg ingen fare eller monopol-misbrug.
Så længe man kan patche sig ud af det, ser jeg ingen fare eller monopol-misbrug.
#12
Hvis man kan patche sig ud af det er man vel lige langt?! Og hvis man ikke kan vil jeg klart kalde det misbrug, jeg kan slet ikke se pointen her. Microsoft har masser af kernel moduler (eller ms ækvivalenten) som de jo også af og til bliver nødt til at opdatere af sikkerhedshensyn.
Dvs. de bliver selv nødt til at kunne have et hul i det her, så jeg har lidt svært ved at forstå hvordan det her gør det mindste ved sikkerheden. Det generer de legitime virksomheder, og alle blackhats omgår jo bare løsningen, på den samme måde som Microsoft installerer stads.
I bedste fald har Microsoft bare forstærket sit eget arsenal, og næste kapitel i våbenkapløbet er begyndt.
#4
Blue Pill er varm luft, det er absolut ikke muligt at gøre det umuligt at detektere at dit OS kører oven på en VM. Det er en god ide, og den vil helt sikkert trække tænder ud, men det er på ingen måde muligt at skjule det.
Hvis man kan patche sig ud af det er man vel lige langt?! Og hvis man ikke kan vil jeg klart kalde det misbrug, jeg kan slet ikke se pointen her. Microsoft har masser af kernel moduler (eller ms ækvivalenten) som de jo også af og til bliver nødt til at opdatere af sikkerhedshensyn.
Dvs. de bliver selv nødt til at kunne have et hul i det her, så jeg har lidt svært ved at forstå hvordan det her gør det mindste ved sikkerheden. Det generer de legitime virksomheder, og alle blackhats omgår jo bare løsningen, på den samme måde som Microsoft installerer stads.
I bedste fald har Microsoft bare forstærket sit eget arsenal, og næste kapitel i våbenkapløbet er begyndt.
#4
Blue Pill er varm luft, det er absolut ikke muligt at gøre det umuligt at detektere at dit OS kører oven på en VM. Det er en god ide, og den vil helt sikkert trække tænder ud, men det er på ingen måde muligt at skjule det.
Er det her ikke en gammel historie? Jeg tror det er mere end et halvt år siden jeg første gang hørte om, at Microsoft begrænsede muligheden for at patche 64 bits udgaven af deres kerne.
En lignende ændring skete i Linux mellem 2.4 og 2.6, hvor sys_call_table ikke længere bliver eksporteret. Det var en designfejl, hvis et modul læste fra tabellen. Det var ikke meningen, at der skulle skrives til tabellen, så der var ingen beskyttelse imod race conditions. Og moduler, som ændrede den, ville ud over race conditions også rende ind i problemer, hvis flere moduler pillede ved samme indgang, eller koden blot var i brug, når man fjernede modulet. Endeligt blev muligheden for at ændre i tabllen brugt af nogle rootkits. Så ved at fjerne muligheden blokerede man for en del dårlig kode og rootkits.
Man kunne godt have designet et system, der tillod sikker hookning af system kald på runtime. Men det ville koste performance ved hvert eneste systemkald, også for det store flertal af brugerne, der ikke havde brug for det.
Hvis man vil tillade, at tredjepartssoftware skal kunne overvåge systemet og implementere policies for, hvad programmer må, så skulle man hellere lave hooks designet til det specifikke formål. Det kan gøres, så tredjepartssoftwaren slet ikke behøver køre i kernen.
At ville beskytte sin kerne fuldstændigt mod modifikationer på runtime er et fornuftigt design set fra et sikkerhedsmæssigt synspunkt. Om man vil tillade en administrator at modificere kernen er et valg, der skal træffes. Der er gode argumenter både for og imod. Så den her ændring giver altså ikke i sig selv nogen grund til at mistænke Microsoft for noget.
Egentlig kan sikkerhedsbranchen i stor udstrækning takke Microsoft for, at de overhovedet har et marked. Jeg har til tider sagt, at hvis Microsoft strammede op omkring sikkerheden, så ville sikkerhedssoftware blive overflødiggjort. (Indrømmet, det er en anelse overdrevet). Men jeg havde nu ikke forestillet mig, at det ville foregå helt på den her måde.
Andre har gættet på, at sikkerhedssoftware fint ville kunne overleve, for folk er blevet vænnet til en tankegang, der siger, at man skal installere et hav af tredjepartsprogrammer for at opnå sikkerhed. Og så længe folk gør det, vil de ikke opdage, om deres system var sikkert uden.
En virkelig interessant drejning på den her sag ville være, hvis alle de ramte firmaer arbejdede sammen om at lave en alternativ kerne med de relevante hooks. Måske kan kernen fra reactos være et brugbart udgangspunkt. (Desværre tror jeg ikke det er en sandsynlig udgang på den her sag).
[url=#3]#3[/url] jakobdam
[url=#4]#4[/url] fallen_dk
En lignende ændring skete i Linux mellem 2.4 og 2.6, hvor sys_call_table ikke længere bliver eksporteret. Det var en designfejl, hvis et modul læste fra tabellen. Det var ikke meningen, at der skulle skrives til tabellen, så der var ingen beskyttelse imod race conditions. Og moduler, som ændrede den, ville ud over race conditions også rende ind i problemer, hvis flere moduler pillede ved samme indgang, eller koden blot var i brug, når man fjernede modulet. Endeligt blev muligheden for at ændre i tabllen brugt af nogle rootkits. Så ved at fjerne muligheden blokerede man for en del dårlig kode og rootkits.
Man kunne godt have designet et system, der tillod sikker hookning af system kald på runtime. Men det ville koste performance ved hvert eneste systemkald, også for det store flertal af brugerne, der ikke havde brug for det.
Hvis man vil tillade, at tredjepartssoftware skal kunne overvåge systemet og implementere policies for, hvad programmer må, så skulle man hellere lave hooks designet til det specifikke formål. Det kan gøres, så tredjepartssoftwaren slet ikke behøver køre i kernen.
At ville beskytte sin kerne fuldstændigt mod modifikationer på runtime er et fornuftigt design set fra et sikkerhedsmæssigt synspunkt. Om man vil tillade en administrator at modificere kernen er et valg, der skal træffes. Der er gode argumenter både for og imod. Så den her ændring giver altså ikke i sig selv nogen grund til at mistænke Microsoft for noget.
Egentlig kan sikkerhedsbranchen i stor udstrækning takke Microsoft for, at de overhovedet har et marked. Jeg har til tider sagt, at hvis Microsoft strammede op omkring sikkerheden, så ville sikkerhedssoftware blive overflødiggjort. (Indrømmet, det er en anelse overdrevet). Men jeg havde nu ikke forestillet mig, at det ville foregå helt på den her måde.
Andre har gættet på, at sikkerhedssoftware fint ville kunne overleve, for folk er blevet vænnet til en tankegang, der siger, at man skal installere et hav af tredjepartsprogrammer for at opnå sikkerhed. Og så længe folk gør det, vil de ikke opdage, om deres system var sikkert uden.
En virkelig interessant drejning på den her sag ville være, hvis alle de ramte firmaer arbejdede sammen om at lave en alternativ kerne med de relevante hooks. Måske kan kernen fra reactos være et brugbart udgangspunkt. (Desværre tror jeg ikke det er en sandsynlig udgang på den her sag).
[url=#3]#3[/url] jakobdam
Men på den anden side set, så kan det heller ikke nægtes at Microsoft dermed står stærkere med deres eget udviklede software, såfremt det har adgang til kernellenDet er der ikke noget nyt i. Selv uden at ændre kernen står de stærkere ved blot at vide mere om, hvordan den fungerer internt. Den eneste måde at undgå det er ved at have et åbent design og uafhængige leverandører til hver eneste komponent i systemet. Som et eksempel på et system, der stort set lever op til det kan nævnes GNU/Linux, BSD, Unix, mfl.
[url=#4]#4[/url] fallen_dk
du har ikke læst nyheden der var her for ikke så længe siden om Blue Pill rootkitten der lægger sig i virtualiseringens laget under OS'et ?Det kan jo kun lade sig gøre, hvis man allerede er nået ind i kernen. Hvis Microsoft er konsekvente og lukker kernen af for al kode udefra, så vil den trussel slet ikke eksistere. Men det er selvfølgelig et stort arbejde, og der kan være mange små sikkerhedshuller, der skal findes og lukkes.
#14 http://it.slashdot.org/it/06/08/12/130204.shtml
...a virtualization professional (Anthony Liguori of the Xen project) has now voiced his opinion to state this is bunkum. There are two parts two this — the ability to take over the machine and seamlessly drop the OS into a VM (which is very difficult, but possible) and the ability to have windows run in the VM undetectably (which is impossible). In fact, Rutkowska's prototype is VERY detectable.
#14
Indlæg 16 er svaret, processkaldene bliver langsommere når du kører oven på et vm, fordi du er tvunget til at fange kaldene og emulere den effekt de ellers ville have. Resultatet er målbart, så du kan ganske enkelt bare tage tid på alle systemkald, som alle tager et meget specifikt stykke tid at ekserkvere, der kun varierer meget minimalt.
En fordobling eller tredobling i ekserkveringstiden for et systemkald er meget let at detektere. Jeg kunne skrive en Blue Pill detektor (til linux, har ikke en windows compiler) på 2-3 minutter.
Og alt det bliver først muligt når du er istand til at overføre hele os'et til et vm mens det kører, hvilket jeg virkelig ikke har lyst til at kode, medmindre jeg har overset noget, vil det kræve ihvertfald en delvis reverse engineering af windows. Specifikt hvordan windows allokerer hukommelse.
Indlæg 16 er svaret, processkaldene bliver langsommere når du kører oven på et vm, fordi du er tvunget til at fange kaldene og emulere den effekt de ellers ville have. Resultatet er målbart, så du kan ganske enkelt bare tage tid på alle systemkald, som alle tager et meget specifikt stykke tid at ekserkvere, der kun varierer meget minimalt.
En fordobling eller tredobling i ekserkveringstiden for et systemkald er meget let at detektere. Jeg kunne skrive en Blue Pill detektor (til linux, har ikke en windows compiler) på 2-3 minutter.
Og alt det bliver først muligt når du er istand til at overføre hele os'et til et vm mens det kører, hvilket jeg virkelig ikke har lyst til at kode, medmindre jeg har overset noget, vil det kræve ihvertfald en delvis reverse engineering af windows. Specifikt hvordan windows allokerer hukommelse.
Jeg synes folk glemmer at lægge mærke til en ting:
Microsoft blokerer for at både god- og ond-sindet software får adgang til kernen, hvilket umiddelbart er fint nok(!)
Men når nu der maks er gået en uge og de først proof of concept viruser kommer som kan "slippe forbi" denne blokade, hvad skal sikkerhedsfirmaerne så gøre for at forhindre det?
I og med at de ikke har direkte adgang, så er de jo nødt til at benytte de samme svagheder i blokeringen til at omgåes det på som virus og lign. vil gøre.
Ellers har sikkerhedsfirmaerne ingen chance overhovedet for at fjerne og evt. blokere de pågældende virus og lign.
Microsoft blokerer for at både god- og ond-sindet software får adgang til kernen, hvilket umiddelbart er fint nok(!)
Men når nu der maks er gået en uge og de først proof of concept viruser kommer som kan "slippe forbi" denne blokade, hvad skal sikkerhedsfirmaerne så gøre for at forhindre det?
I og med at de ikke har direkte adgang, så er de jo nødt til at benytte de samme svagheder i blokeringen til at omgåes det på som virus og lign. vil gøre.
Ellers har sikkerhedsfirmaerne ingen chance overhovedet for at fjerne og evt. blokere de pågældende virus og lign.
#18
Hehe, jeg vil ikke til at skrive koden, men et hurtigt eksempel. Lad os sige du ekserkverer et hardwarekald der opretter en tråd under windows linux mm., givet at du ved præcist hvor hurtigt din cpu kører, kan du ved at time enten antal clockcykler (om muligt) eller aflæsningen af systemuret (som iøvrigt også vil variere i forsinkelse imellem VM og ren hardware, omend den muligvis kan være hurtigere, og dermed er det ikke et godt valg).
Tricket ligger i at finde en funktion som er langsommere når den kører under et VM end uden. Den eneste måde det her ikke ville kunne gøres på, er hvis hardwaren er istand til at ekserkvere et vm i samme hastighed som på ren hardware. Hvis de opnår det, jamen så er det korrekt, så vil det kunne skjules, men det sker næppe.
Andre simple eksempler kunne være opdateringstiden for cpu'ens temperatursensor, den faktiske temperatur af cpu'en når den laver noget og ikke laver noget. (for at se om der er et vm i baggrunden, det kan selvfølgelig forfalskes.)
Hvis jeg ikke overbeviser folk om at det her er umuligt, så håber jeg i det mindste jeg overbeviser folk om at der er lettere måder at gøre det her. Hvem ved, måske har NSA en chance.
Hehe, jeg vil ikke til at skrive koden, men et hurtigt eksempel. Lad os sige du ekserkverer et hardwarekald der opretter en tråd under windows linux mm., givet at du ved præcist hvor hurtigt din cpu kører, kan du ved at time enten antal clockcykler (om muligt) eller aflæsningen af systemuret (som iøvrigt også vil variere i forsinkelse imellem VM og ren hardware, omend den muligvis kan være hurtigere, og dermed er det ikke et godt valg).
Tricket ligger i at finde en funktion som er langsommere når den kører under et VM end uden. Den eneste måde det her ikke ville kunne gøres på, er hvis hardwaren er istand til at ekserkvere et vm i samme hastighed som på ren hardware. Hvis de opnår det, jamen så er det korrekt, så vil det kunne skjules, men det sker næppe.
Andre simple eksempler kunne være opdateringstiden for cpu'ens temperatursensor, den faktiske temperatur af cpu'en når den laver noget og ikke laver noget. (for at se om der er et vm i baggrunden, det kan selvfølgelig forfalskes.)
Hvis jeg ikke overbeviser folk om at det her er umuligt, så håber jeg i det mindste jeg overbeviser folk om at der er lettere måder at gøre det her. Hvem ved, måske har NSA en chance.
#24
Hehe, kunne ikke nære mig.
Dine ideer lyder ganske interessante, om de kan implementeres så alle kan bruge dem skal jeg ikke kunne svare på.
Men jeg tror heller ikke de lige kan skjule sig så det ikke kan opdages, men igen ville det da ikke undre mig der sidder nogen derude der er gode nok.
Men hvad pokker vi lever jo alle i 'The Matrix' alligevel :)
Hehe, kunne ikke nære mig.
Dine ideer lyder ganske interessante, om de kan implementeres så alle kan bruge dem skal jeg ikke kunne svare på.
Men jeg tror heller ikke de lige kan skjule sig så det ikke kan opdages, men igen ville det da ikke undre mig der sidder nogen derude der er gode nok.
Men hvad pokker vi lever jo alle i 'The Matrix' alligevel :)
#24 og #25
Kom virkelig til at tænke på noget i stil med Matrix..
Det er et spørgsmål om at finde punkter hvor den simulerede verden varier fra den virkelige.. hvor lang tid det tager at udføre nogle bestemte ting, som der normalt tager et givent stykke tid, og ellers finde andre afvigelser..;)..
Ligesom nogen mener at dejavu i den virkelige verden er når der sker fejl i mainframen..:P
Kom virkelig til at tænke på noget i stil med Matrix..
Det er et spørgsmål om at finde punkter hvor den simulerede verden varier fra den virkelige.. hvor lang tid det tager at udføre nogle bestemte ting, som der normalt tager et givent stykke tid, og ellers finde andre afvigelser..;)..
Ligesom nogen mener at dejavu i den virkelige verden er når der sker fejl i mainframen..:P
Jeg synes nu også det virker som en underlig måde at lukke adgangen på nu jeg tænker over det. Det er vel lidt en nødløsning at lukke adgang til kernen med et stykke ekstra software, skulle det ikke lukkes et stykke tættere på kilden, altså i selve kernens kode eller lignende (det er ikke lige mit speciale :P), i stedet for med en ekstern patch, hvis man vil lukke sådan et hul ordentligt?
selvom dette er en god ting, tror jeg microsoft bliver upopulære, da dette også vil sætte en stopper for nogle "copy protection" systemer, som bliver brugt på spil og sådan.
27#
I mine øjne er det en lappe løsning, som alligevel ikke er sikker nok.
For det første kræver det at kernen bliver patched jævnligt hvis det skal bare skal virke nogenlunde, samtidig betyder det jo at et downloaded program (patchen/updaten) skal forbi patchguard for at kunne patche den. Så selvom Microsoft siger de ikke vil lave undtagelser, så er de jo nødt til at kunne opdatere den, og lige nøjagtig der, vil der IMHO være en stor sikkerhedsrisiko.
I mine øjne er det en lappe løsning, som alligevel ikke er sikker nok.
For det første kræver det at kernen bliver patched jævnligt hvis det skal bare skal virke nogenlunde, samtidig betyder det jo at et downloaded program (patchen/updaten) skal forbi patchguard for at kunne patche den. Så selvom Microsoft siger de ikke vil lave undtagelser, så er de jo nødt til at kunne opdatere den, og lige nøjagtig der, vil der IMHO være en stor sikkerhedsrisiko.
#7 mgX:
Windows Firewall fungerer *langt* bedre end mange andre 3. parts firewalls (læs: ZoneAlarm, BitDefender Firewall, McAfee Firewall, etc.) - At sige det ikke fungerer, er noget fis.
Jeg kan ikke lade være med at undre mig over, at man i dag ikke har lov til at lave sit software *som man har lyst* - fordi folk bruger det, og andre firmaer afhænger af dit software. Det svarer til (for at bruge bileksemplet fra tidligere) at Mercedes laver en ny model mX9000, den er elektronisk fartcapped på 280km/t. Et firma, ElectroniX vælger at udgive et kit, hvormed du kan fjerne denne fartcap og derved kan køre 350km/t, som reelt er bilens max hastighed. Mercedes synes ikke, at man skal køre 350km/t i bilen, af sikkerheds- samt slitageårsager, så de fjerner muligheden for i fremtidige mX9000 biler at bryde den elektroniske fartgrænse. ElectroniX går neden om og hjem, og sagsøger Mercedes for monopolmisbrug. Er jeg den ENESTE der kan se hvor galt det egentlig er? En ting er, at man bliver påtvunget brugen af MS Windows (hvilket vi jo kan blive enige om, ikke er tilfældet) - i så fald ville jeg kunne forstå, at det ikke var tilladt - men valget af OS er _dit_ og ingen andres.
Windows Firewall fungerer *langt* bedre end mange andre 3. parts firewalls (læs: ZoneAlarm, BitDefender Firewall, McAfee Firewall, etc.) - At sige det ikke fungerer, er noget fis.
Jeg kan ikke lade være med at undre mig over, at man i dag ikke har lov til at lave sit software *som man har lyst* - fordi folk bruger det, og andre firmaer afhænger af dit software. Det svarer til (for at bruge bileksemplet fra tidligere) at Mercedes laver en ny model mX9000, den er elektronisk fartcapped på 280km/t. Et firma, ElectroniX vælger at udgive et kit, hvormed du kan fjerne denne fartcap og derved kan køre 350km/t, som reelt er bilens max hastighed. Mercedes synes ikke, at man skal køre 350km/t i bilen, af sikkerheds- samt slitageårsager, så de fjerner muligheden for i fremtidige mX9000 biler at bryde den elektroniske fartgrænse. ElectroniX går neden om og hjem, og sagsøger Mercedes for monopolmisbrug. Er jeg den ENESTE der kan se hvor galt det egentlig er? En ting er, at man bliver påtvunget brugen af MS Windows (hvilket vi jo kan blive enige om, ikke er tilfældet) - i så fald ville jeg kunne forstå, at det ikke var tilladt - men valget af OS er _dit_ og ingen andres.
33#
Jeg er bange for at du ikke helt har forstået hvad det handler om.
For at fortsætte i dit bil eksempel:
Mercedes laver en fed ny bil. Men beslutter at ændre den således at rat og handskerum er indrettet således at det ikke længere er muligt at montere airbag i hverken rat eller ved handskerum, som der normalt er kutyme ved biler i dag. Derimod ændre de kofanger og lign. således at bilen ikke burde kunne smadres, og hvis den gør det.. så gør den det langsomt..(eller noget i den retning..;)..
Men efterfølgende viser det sig at det stadig kan lade sig gøre at smadre bilen så man bliver mast flad mod rattet eller handskerummet.. med dertil hørende skavanker.
Dermed falder sikkerheden i bilen, fordi hverken mercedes selv eller andre tredje parts producenter kan lave en airbag der kan monteres forsvarligt i bilen så den stadigvæk beskytter, mod hvad sådan en nu normalt beskytter imod..
Men Mercedes har dog mulighed for at kalde bilen på værksted for at tilpasse, således at de kan gøre den mere sikker. (ifølge deres egne sikkerhedsfolk.)
Ok.. eksemplet er nok lidt langt ude.. men jeg håber du kunne forstå hvad der er ment med det.
Jeg er bange for at du ikke helt har forstået hvad det handler om.
For at fortsætte i dit bil eksempel:
Mercedes laver en fed ny bil. Men beslutter at ændre den således at rat og handskerum er indrettet således at det ikke længere er muligt at montere airbag i hverken rat eller ved handskerum, som der normalt er kutyme ved biler i dag. Derimod ændre de kofanger og lign. således at bilen ikke burde kunne smadres, og hvis den gør det.. så gør den det langsomt..(eller noget i den retning..;)..
Men efterfølgende viser det sig at det stadig kan lade sig gøre at smadre bilen så man bliver mast flad mod rattet eller handskerummet.. med dertil hørende skavanker.
Dermed falder sikkerheden i bilen, fordi hverken mercedes selv eller andre tredje parts producenter kan lave en airbag der kan monteres forsvarligt i bilen så den stadigvæk beskytter, mod hvad sådan en nu normalt beskytter imod..
Men Mercedes har dog mulighed for at kalde bilen på værksted for at tilpasse, således at de kan gøre den mere sikker. (ifølge deres egne sikkerhedsfolk.)
Ok.. eksemplet er nok lidt langt ude.. men jeg håber du kunne forstå hvad der er ment med det.
#33 + 34:
Jaja, bilen ville pludselig gå død, nægte at starte, pludseligt skifte i bakgear ved høje hastigheder, nægte at tænde for radioen før du kørte med vinduerne, airbag systemet ville spørge "are you sure?", sikkerhedsselen ville låse tilfældigt hvilket umuliggør at komme ud af bilen, startspærren ville nægte brugeren at tænde bilen før han fløjtede MS hymnen korrekt, men dog tillade evt. tyve at tage bilen idet de bare kan benytte bagdørene...
Please folkens: Sammenlign ikke windows med biler :)
Jaja, bilen ville pludselig gå død, nægte at starte, pludseligt skifte i bakgear ved høje hastigheder, nægte at tænde for radioen før du kørte med vinduerne, airbag systemet ville spørge "are you sure?", sikkerhedsselen ville låse tilfældigt hvilket umuliggør at komme ud af bilen, startspærren ville nægte brugeren at tænde bilen før han fløjtede MS hymnen korrekt, men dog tillade evt. tyve at tage bilen idet de bare kan benytte bagdørene...
Please folkens: Sammenlign ikke windows med biler :)
Jeg synes det er helt fint, at Patchguard holder 3. parts programmer ude af kernen, men som themuss skriver i et tidligere indlæg, så bør der være mulighed for at slå det fra.
Jeg aner ikke en ski' om hvordan det fungerer. Men det må da være muligt at isolere kernen fra alt mulig andet så det ikke er muligt for udefra kommende processer at lave hooks dertil?
Jeg aner ikke en ski' om hvordan det fungerer. Men det må da være muligt at isolere kernen fra alt mulig andet så det ikke er muligt for udefra kommende processer at lave hooks dertil?
Symantec har bestemt heller ikke vaeret heldig med deres software :( kan huske at en af deres suits havde en bug der blev ved med at nulstille hvilken version man havde liggende, sa hver dag 10 mb update
Helt ærligt.
MS er blevet punket i 10 år p.g.a. dårlig sikkerhed.
Nu vil de gøre noget ved det. Og ikke bare noget lapperi, men
nogle strukturelle ting.
Og så bliver de også kritiseret.
For mig er det ret logisk at:
hvis white hat software kan hooke sig ind i kernen, så
kan black hat software også
Så selvfølgelig skal der lukkes.
Man kan da ikke kræve at MS holder sikkerhedshuller åbne
for at give Symantec et marked for sikkerheds software.
Og ja - det er ikke sikkert at MS får det effektivt lukket i første
omgang. Men det er da bedre at få det lukket i anden omgang end
aldrig at få det lukket.
MS er blevet punket i 10 år p.g.a. dårlig sikkerhed.
Nu vil de gøre noget ved det. Og ikke bare noget lapperi, men
nogle strukturelle ting.
Og så bliver de også kritiseret.
For mig er det ret logisk at:
hvis white hat software kan hooke sig ind i kernen, så
kan black hat software også
Så selvfølgelig skal der lukkes.
Man kan da ikke kræve at MS holder sikkerhedshuller åbne
for at give Symantec et marked for sikkerheds software.
Og ja - det er ikke sikkert at MS får det effektivt lukket i første
omgang. Men det er da bedre at få det lukket i anden omgang end
aldrig at få det lukket.
#42
Du er ude på dybt vand, som det er blevet nævnt masser af gange, kan det her ikke lukkes. Det her er falsk tryghed når det er værst.
Du er ude på dybt vand, som det er blevet nævnt masser af gange, kan det her ikke lukkes. Det her er falsk tryghed når det er værst.
Det eneste jeg kan se er, at forsøger man ikke at lukke det, så bliver
det ihvertfald aldrig lukket.
Det er nævnt masser af gange i denne tråd at folk ikke tror
på at det kan laves sikkert og at der altid vil være huller.
Men der er ikke nogen som har været specielt specifikke om
hvorfor det ikke kan gøres. Det lyder mest som almindelig
"jeg kan ikke lide MS".
Beskyttelse af software mod modifikation er et teknisk problem
og et teknisk problem der mig bekendt er løsninger på.
det ihvertfald aldrig lukket.
Det er nævnt masser af gange i denne tråd at folk ikke tror
på at det kan laves sikkert og at der altid vil være huller.
Men der er ikke nogen som har været specielt specifikke om
hvorfor det ikke kan gøres. Det lyder mest som almindelig
"jeg kan ikke lide MS".
Beskyttelse af software mod modifikation er et teknisk problem
og et teknisk problem der mig bekendt er løsninger på.
#44
Ikke hvis du selv skal have adgang til det, så er det netop ikke et teknisk problem. I værste fald er det et krypteringsproblem.
Ikke hvis du selv skal have adgang til det, så er det netop ikke et teknisk problem. I værste fald er det et krypteringsproblem.
#46
Det har de da netop brug for til deres virtualiseringssoftware, så nej det kan jeg ikke være enig i.
Det har de da netop brug for til deres virtualiseringssoftware, så nej det kan jeg ikke være enig i.
[url=#47]#47[/url] SmackedFly
Hvis omvendt der er tale om, at Windows skal køre som guest systemet, så er der igen ikke tale om nogen form for runtime patchinng. Virtualiseringen startes op før den virtualiserede Windows. Og laves der en komplet virtualisering, så vil kernen, som kører derunder, være en umodificeret kerne. Der kan selvfølgelig også være tale om en delvis virtualisering, som kræver en kerne, der er designet til at fungere sammen med virtualiseringen. Igen er der ikke tale om nogen form for runtime patching, men blot en anden kerne.
Det har de da netop brug for til deres virtualiseringssoftware, så nej det kan jeg ikke være enig i.Hvis virtualiseringen er fornuftigt designet vil der ikke være brug for at patche noget system på runtime. Hvis Windows skal fungere som hostsystemet, så er guest systemet bare et program, der kører under Windows, og i princippet ikke væsentligt forskelligt fra alle andre. Det kan selvfølgelig godt tænkes, at sådan som arkitekturen er ud vil det være nødvendigt med specielle systemkald for at understøtte virtualiseringssoftwaren. Den slags skal i så fald stilles til rådighed af kernen lige fra start af uden nogen form for patching.
Hvis omvendt der er tale om, at Windows skal køre som guest systemet, så er der igen ikke tale om nogen form for runtime patchinng. Virtualiseringen startes op før den virtualiserede Windows. Og laves der en komplet virtualisering, så vil kernen, som kører derunder, være en umodificeret kerne. Der kan selvfølgelig også være tale om en delvis virtualisering, som kræver en kerne, der er designet til at fungere sammen med virtualiseringen. Igen er der ikke tale om nogen form for runtime patching, men blot en anden kerne.
kasperd>>> prøv at læse denne artikel http://www.securityfocus.com/columnists/402 og http://theinvisiblethings.blogspot.com/2006/06/int...
det er ganske nemt med disse teknikker selv at escape fra enhver vm, og få ring 0, og derved kan man gøre sine ugerninger over kernellen
det er ganske nemt med disse teknikker selv at escape fra enhver vm, og få ring 0, og derved kan man gøre sine ugerninger over kernellen
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund