Den ultimata säkerhetstråden

[JoWa]

Låter bra! Den kommer att bli en kioskvältare.

Gonatt!

[Gäst al6]

Jag vill tycka till lite nu.

Jag har gjort en ordentlig djupdykning i Memory Firewall och mitt omdöme om den har ändrats hela tiden. Men alltså seriöst, den verkar faktiskt vara riktigt onödig, seriöst.

(Jag snackar nu bara om x64)

DEP stoppar "heap execution" och "stack execution" redan på cpu-nivå, det är vad jag förstår helt omöjligt att komma genom DEP. Memory Firewall stoppar dock extremt långt senare, och den har enorma missar enligt mig. DEP stoppar exakt all sorts kod, medan Memory Firewall endast stoppar utvalda anrop såsom ShellExecute, WinExec och ShellExecuteEx. MEN DEN STOPPAR INTE system!!! anropet "system" är till och med en standard och stödjs av alla OS och kan göra exakt samma saker som ShellExecute. Dessutom måste Memory Firewall uppdateras efter varje ny Windowsutgåva eftersom Microsoft kan lägga till nya anrop som måste stoppas. Helt enkelt tycker jag att DEP äger skiten ur Memory Firewall.

Men då till ret2libc; samma sak här, Memory Firewall tillåter mig att göra ret2libc utan att reagera, men när jag gör ret2libc med ShellExecute så stoppar den det, men även här har dom missat "system" anropet!! Jag har lärt mig nu att göra heap execution, stack execution och ret2libc attacker, och nu läste jag detta på wikipedia:

Address Space Layout Randomization (ASLR) makes this type of attack extremely unlikely to succeed on 64-bit machines as the memory locations of functions are random; however Shacham et al show that on 32-bit machines ASLR provides little benefit.

Med andra ord betyder det att om man har en cpu (ja det verkar inte vara Windows som måste vara x64, utan endast cpu:n) så har man (om programmet frågar efter det, vilket moderna webbläsare och hela windows och andra viktiga saker gör) ett sinnessjukt bra skydd mot alla sorters attacker som utnyttjar BO. Även om man hela tiden läser att till exempel Adobes läsare hela tiden har säkerhetshål eller att Java har det så betyder ju inte det att man kommer få Virus så fort man använder dessa saker.

Windows Vista har en säkrare minneshantering än Mac OS X Leopard faktiskt, Leopard har inte fullt implementerat ASLR än. Jag anser helt klart att Windows är ett säkrare OS än Mac OS X.

Slutsatsen blir väl då att Memory Firewall mest är ett ballt program, men egentligen inte fyller någon funktion på moderna maskiner då det redan finns bättre skydd inbyggt. Jag tror att jag kommer att sluta med min BO tester nu för det redan finns en elegant och helt fungerande och dessutom tycker jag att jag nu vet en del om säkerhet.

Windows x64 är ett sjukt säkert OS (eftersom man då vet att man kör på en x64 CPU)

[Gäst al6]

Tänker aldrig mer använda ett virusskydd, det är ju löjligt hur säker man faktiskt är

[JoWa]

För att sammanfatta:

I ett 64-bitarssystem med DEP aktiverat, helst för alla program och tjänster, är behovet av extra buffertöverskridningsskydd minimalt.

I ett 32-bitarssystem (med 32-bitars-CPU), oavsett om DEP är aktiverat eller inte, ger Memory Firewall eller motsvarande ett värdefullt skydd.

Har jag uppfattat det rätt då?

Tänker aldrig mer använda ett virusskydd, det är ju löjligt hur säker man faktiskt är

Så länge användaren inte gör/tillåter något onyttigt. En och annan tycks ha svårt att undvika det.

[Gäst al6]

För att sammanfatta:

I ett 64-bitarssystem med DEP aktiverat, helst för alla program och tjänster, är behovet av extra buffertöverskridningsskydd minimalt.

I ett 32-bitarssystem (med 32-bitars-CPU), oavsett om DEP är aktiverat eller inte, ger Memory Firewall eller motsvarande ett värdefullt skydd.

Har jag uppfattat det rätt då?

Så länge användaren inte gör/tillåter något onyttigt. En och annan tycks ha svårt att undvika det.

Alltså det är ju skitsvårt att fatta om dom menar Windows x64 eller en x64 CPU. För att vara säker kan man väl säga att Windows x64 är mycket säkert medan Windows x86 är mindre säkert. Jag är övertygad om att man gjort en miss i Memory Firewall eftersom anrop till "system" (som är en "skalfunktion") inte alls detekteras. Efter man fixat detta är väl Memory Firewall helt ok för dom som endast har Windows x86.

Vad som är kvar att lära sig är väl om dom menar Windows eller CPU:n

[Gäst al6]

Jag var tvungen...

Testar stack execution, heap execution samt ret2libc. Körs helt portabelt på Windows Vista och Windows 7 samt kräver inte UAC. På Windows XP behöver man .NET 2.0 eller senare och får då inte glasutseende, så klart

Helt onödig pryl, men har lärt mig fett mycket om säkerhet när jag fipplat fram den.

[JoWa]

Ser ju helcool ut!

Jag har dock inte .Net…

[JoWa]

Testade i en annan dator (inte min), med .Net och CIS 3.8.

Den datorn har en 64-bitarsprocessor (men XP x32), så jag skall testa om DEP (aktiverat för alla program) ger något skydd.

[JoWa]

Stängde av buffertöverskridningsskyddet i CIS och upprepade testet, med DEP aktiverat för alla program. 64-bitars AMD-processor, Windows XP SP3, x32.

[Gäst al6]

Testet är utformat till fördel för comodos skydd, så egentligen är ret2libc-testet missvisande för ASLR, men ändå har du ju inte Vista så där är inte ens ASLR, nåja. Jag tror faktiskt att Windows 7 RC har felaktig DEP, för i betan av 7an står det uttryckligen att DEP stänger ett program men i RC står det bara att programmet kraschat. På din XP står det ju också att DEP stoppat programmet.

Det borde vara ett fel i 7an RC då...

Men vi har ju nu lärt oss att Microsoft faktiskt har koll på den här tekniken att stoppa sånt här

[Gäst al6]

Stängde av buffertöverskridningsskyddet i CIS och upprepade testet, med DEP aktiverat för alla program. 64-bitars AMD-processor, Windows XP SP3, x32.

Då är det bara kvar att testa det hela på en 32-bitars CPU med DEP på, så får vi ju reda på det här med säkerheten i DEP på x86 vs x64

[JoWa]

Och vi har lärt oss att vilken processor man använder är avgörande för DEP:s effektivitet. I min dator, med 32-bitarsprocessor (Pentium 4) skyddade inte DEP alls, men i en dator med 64-bitarsprosessor skyddade DEP, utom mot return-to-libc-attacker. Windows XP SP3 x32 i båda fallen.

Tillägg: Hehe, du ställde frågan medan jag skrev svaret.

[Gäst al6]

Och vi har lärt oss att vilken processor man använder är avgörande för DEP:s effektivitet. I min dator, med 32-bitarsprocessor (Pentium 4) skyddade inte DEP alls, men i en dator med 64-bitarsprosessor skyddade DEP, utom mot return-to-libc-attacker. Windows XP SP3 x32 i båda fallen.

Tillägg: Hehe, du ställde frågan medan jag skrev svaret.

Exakt, jag testade precis på en Windows XP x86 med DEP för alla program på, och denna gav absolut 0 skydd.

Dock är jag osäker angående ASLR, kanske måste man ha Windows x64 där.. återstår att testa

Denna tråden kan ju faktiskt bidra med lite info trots allt

Även har vi kvar att få ett svar angående missen i Memory Firewall, jag skrev om den på deras forum för några dagar sedan...

Alltså två frågor kvar

[Gäst al6]

A security whitepaper from Symantec noted that ASLR in 32-bit Windows Vista may not be as robust as expected, and Microsoft has acknowledged a weakness in its implementation.[6]

Här har vi svaret; ASLR är en teknik som implementeras i Windows kärna. Det är alltså själva Windows som står för skyddet här, och är då beroende av om det är 64-bitarsimplementationen (Windows x64) eller 32-bitarsimplementationen (Windows x86). DEP är istället något som sköts helt av processorn och då kan Windows 32-bitar bara delegera vidare till processorn om den är x64.

Läste att x86-ASLR har en slumpmässighet på 1 av 256 - en attack har alltså 0,4% chans att lyckas under Windows x86, medan x64 hade ca 1 av 1000000000, alltså 0,0000001% chans att lyckas med ret2libc.

Windows x64 är alltså fruktansvärt mycket säkrare än Windows x86; dels för att man är säker att man har x64 DEP och dels för att ASLR gör det praktiskt taget omöjligt att lyckas med ret2libc. Jag tänker definitivt byta till x64 Windows när RC kommer från Microsoft.

[JoWa]

Så den största svagheten med dataexekveringsskyddet i ett modernt system (64-bitars CPU, Vista eller 7) är att det inte som standard är aktiverat för alla program och tjänster…

[JoWa]

Man bör dock se till att skydda registret mot oönskade ändringar:

A registry setting is available to forcibly enable or disable ASLR for all executables and libraries.

http://en.wikipedia.org/wiki/Address_space...t_randomization

Mer läsning: Bypassing Browser Memory Protections (pdf)

[Gäst al6]

Man bör dock se till att skydda registret mot oönskade ändringar:

http://en.wikipedia.org/wiki/Address_space...t_randomization

Mer läsning: Bypassing Browser Memory Protections (pdf)

Jo dom här länkarna har jag mycket väl läst den senaste tiden. DEP och ASLR är ju värdelösa när man väl fått in ett virus genom sin "mur", så att man kan stänga av både DEP och ASLR är egentligen inget att haka upp sig på, lika så kan ju UAC och allt annat stängas av när man väl blivit smittad.

Den här PDF-en verkar vara rätt gammal, man snackar om att Visual Studio 2005 är ny och sånt. Sen så är ju DEP omöjlig att penetrera, dock skyddar ju den endast mot stack/heap execution (stacken och heapen är data, vilket faller in på namnet Data Execution Prevention), så om man använder ret2libc har man om man så vill "kringgått DEP" (fast att man egentligen inte alls kommit i kontakt med DEP). Vad som är kvar är ASLR som inte är 100% bullet proof, men vad jag förstått en jävla stoppkloss. Det är väl implementationen av ASLR som skulle kunna förbättras, men det framgår inte om det rör sig om x86 eller x64. Nåja, dom här skydden är iaf allt annat än värdelösa.

Det känns som att virusmakarna kommer få det svårt i framtiden, dom här skydden har redan kapat av tre välanvända ingångar. Förmodligen därför man mer och mer hör "Social engineering" eftersom människan är lättare att "hacka" än själva datorn nuförtiden

[Gäst al6]

Färdig nu, bör kunna användas istället för Comodo BO Tester, inte för jag vet varför men det kan vara kul...

[JoWa]

Färdig nu, bör kunna användas istället för Comodo BO Tester, inte för jag vet varför men det kan vara kul...

Visst är det kul. Och du skall väl ha en applåd för ansträngningarna och resultatet, både programmet och det de som har följt tråden har lärt sig.

Inte så kul för mig dock att det kräver .Net. Känns inte helt rätt att installera flera hundra mb för att köra ett portabelt program som väger 69,5 kb… Får låna en annan dator för test.

[Gäst bäver]

Imponerande arbete av al6 och JoWa. En säkerhetstråd i den högre skolan.

Måste väl erkänna att jag inte alla gånger hängde med, antagligen pga bristande kompetens.

[JoWa]

al6, du får nog ändra texten i programmet…

Helt nyss kom beskedet att Comodo Memory Firewall läggs ned som fristående program. En uppdaterad version av det är integrerad i Comodo Internet Security (fr.o.m. version 3.8).

Källa

Din tråd om Memory Firewall borde flyttas till Defense+ Bugs. Kontakta LeoniAquila.

[Gäst al6]

al6, du får nog ändra texten i programmet…

Helt nyss kom beskedet att Comodo Memory Firewall läggs ned som fristående program. En uppdaterad version av det är integrerad i Comodo Internet Security (fr.o.m. version 3.8).

Källa

Din tråd om Memory Firewall borde flyttas till Defense+ Bugs. Kontakta LeoniAquila.

Okej, jag borde kanske göra en ny tråd där jag helt enkelt lägger upp korten på bordet och berättar hur det är, men först vil jag testa så dom inte redan fixat det. Vad ska jag göra för att få den nyaste "memory firewall" fast utan o fixa massa andra saker?

Får ändra texten i programmet, och kanske göra ev version utan .NET, men jag tänkte att jag skulle göra den till Vista och 7 och då med glas, eftersom Vista och 7 redan kommer med .NET så den är ju egentligen portabel där... får se.

[JoWa]

Okej, jag borde kanske göra en ny tråd där jag helt enkelt lägger upp korten på bordet och berättar hur det är, men först vil jag testa så dom inte redan fixat det. Vad ska jag göra för att få den nyaste "memory firewall" fast utan o fixa massa andra saker?

Senaste utgåvan av Comodo Internet Security är 3.9.75615.498 RC2. Nedladdningslänkar här. I någon av betaversionerna vet jag att ett av buffertöverskridningsskydden var inaktiverade i x64-versionen. Vet inte om det problemet är löst och alla skydd nu är aktiverade.

Du kan inte installera endast minnesbrandväggen. Vid installation kan du dock välja bort antivirus om du vill. Markera då endast brandväggen. Glöm inte att inaktivera Windows-brandväggen, så att brandväggarna inte ”krockar”.

[Gäst al6]

Installerade den här säkerhetssviten från Comodo och min BO tester fungerade riktigt uselt med den. Kom upp 800 rutor hela tiden och min BO kraschade ibland. Fixade ytterst lite i BO testern och ändrade inte texten (eftersom den uppenbarligen inte är designad för CIS) ändrade dock ikonen till en snyggare. Är riktigt trött på allt som har med Comodo nu faktiskt, jag testade system-anropet på CIS och den släppte genom det - en totalmiss...

Sen så frågade ju CIS mig om typ exakt allt - det frågade mig om jag ville tillåta explorer.exe starta ett program när jag precis dubbelklickat på det, herre gud ^^

Ae, knappast att jag tänker använda något sådant, speciellt inte när mina tester visar att dom gjort gigantiska missar i säkerheten...

Denn tråden börjar väl ta slut nu; BO testern är helt klar nu och jag har tappat intresset lite nu. Resten av diskussionen lär väl vara om CIS och missarna i säkerheten.

[JoWa]

Hm, tydligen har något gått väldigt snett i ditt system.

explorer.exe behandlas normalt som ”Windows systemprogram”, med rätt att exekvera program… Det finns dock en mängd inställningar som påverkar hur CIS beter sig.

Din BO Tester funkade klockrent då jag testade den med CIS 3.8 i Win XP.