Den ultimata säkerhetstråden

[L-L]

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

Vad menar du med att den fungerar klockrent?

[JoWa]

Vad menar du med att den fungerar klockrent?

Att den inte kraschade, som då al6 testade. Se resultat tidigare i tråden.

[L-L]

OK

Jag har försökt få Comodos uppmärksamhet, hittills utan resultat. Låt mig återkomma om jag får veta mer.

[Gäst al6]

Alltså den funkar felfritt med CIS, men själva utseendet av testen (det glasiga) kraschade innan jag ändrat lite i testern eftersom CIS såg till att den inte fick köra "BO-tester-modulen", utan stoppade det. Har fixat det i den senaste versionen så det står bara "Error" om CIS vägrar låta den köra testet. Jag hade iofs min på "extrem säkerhet" eller vad dom kallar det. Om ni insisterar kan jag byta texten till "Designed for Comodo Internet Security".

Men det enda som är kvar som är intressant i denna tråden är nu vad snubbarna har för någon info angående den uppenbarliga säkerhetsmissen i både CIS och CMF (att den tillåter system-anrop), jag har skapat en ny tråd i deras forum "Security flaws, please respond!" tror jag ja döpte den till.

[JoWa]

Okej, drar man upp säkerheten maximalt är det risk att man drunknar i varningar. Det kan ta ett tag att bli helt klok på alla inställningar. Jag har hållit på sedan september. Det är dock endast en inställning som avgör om buffertöverskridningsskyddet är aktiverat eller inte:

Plus att Systemskydd/Defense+ måste vara aktivt.

Det du märkte var att ett okänt program (al6's BO Tester.exe) inte obemärkt kan exekvera en annan process (tmp1.exe då jag testade).

Såg att LA flyttade din tråd till Feedback/Comments/Announcements/News - CIS.

Designed for Comodo Internet Security blir ju helflott.

[Gäst al6]

Alltså man borde kunna göra ett skydd som totalt stoppar dessa attacker, direkt. DEP sätter ju en "no execute"-bit på alla data, vilket hindrar data från att köras, men det hade varit bra om man kunde sätta allt minne som är utanför esp (stack-pekaren) till "read only", vilket gör det omöjligt att skriva över returneringsadressen (ligger på stacken) och därmed sätta ett absolut stopp för dessa tre attacker. Kom ihåg att om programmeraren sätter en kontroll av längden av sina buffrar är programmet ohackbart - nu tänker jag alltså att man skulle göra så operativsystemet sätter en sån gräns på alla program, så om programmet skriver utanför sina buffrar kommer programmet krascha eftersom programmet aldrig får skriva utanför esp, detta är bara något jag tänkte på lite och behöver inte vara helt genomtänkt men med tanke på att exakt alla dom här tre attackerna börjar som en buffer overflow och blir sen allt mer "mäktiga" i datorn hade det ju varit bra om man direkt satsade all kraft på att hindra buffer overflow.

"Min" lösning med esp är faktiskt inte så dålig, eftersom en BO attack är vanlig data och alltså inte körbar kod, förrän man returnerat till den, men för att nå returneringsadressen måste esp-registret ökas så processen får tillgång till returneringsadressen, vilket endast kan göras med kod, vilket en BO-attack inte är

Lösningen blir att kärnan alltid kontrollerar om adressen som en process skriver till är större än esp får processen inte lov att skriva där och hindras alltså

Nåja, jag är inte helt säker på att detta går men jag tror det, iaf bör man kunna göra något liknande.

Ska nog forska lite om detta För CMF / DEP / ASLR verkar först efter en lyckad BO-attack, men det hade alltså varit bra att stoppa skiten direkt.

[Gäst al6]

A return-to-libc attack is a computer security attack usually starting with a buffer overflow in which the return address on the stack is replaced by the address of another instruction and an additional portion of the stack is overwritten to provide arguments to this function. This allows attackers to call preexisting functions without the need to inject malicious code into a program.

Det är den här nedrans returneringsadressen som är boven till allt, kanske man kunde göra en lösning som arbetar helt från CPUn, precis som DEP.

Man skulle kunna göra så CPUn sätter en "read-only"-bit på returneringsadressen, och att endast instuktionerna ret och call kan skriva den.

Det är "call" som skriver returneringsadressen och "ret" som använder den för att returnera, då kunde ju som sagt "call" sätta en speciell bit på returneringsadressen som gör att ingen annan instuktion kan skriva över returneringsadressen, men att "ret" kan läsa och ta bort den, typ något sådant. Detta tar ju dessutom absolut 0 på prestandan.

[JoWa]

Kan det göras oberoende av vilken typ av processor man använder? Det är ju främst vi med ”dåliga” processorer som har nytta av extra buffertöverskridningsskydd.

Comodo vill nog undvika programkrasch. Vid en attack skall användaren få en varning, jämförbar med andra varningar programmet ger, och kunna välja att avsluta processen eller ignorera varningen och låta processen vara igång.

[Gäst al6]

Ooooh

Hittade en sjukt bra lösning som är ganska lik "min": ShadowStack.

Den funkar så att man har en extra, lite mindre stack, för varje process. När instruktionen "call" exekveras läggs returneringsadressen på den vanliga stacken (som alltid) men även på den lilla extra-stacken. När sen "ret" exekveras tas returneringsadressen från den vanliga stacken (som alltid) men även från den lilla extra-stacken och nu utförs testet om dessa båda adresser pekar på samma ställe eller inte. Tada!!

Håller på att läsa lite om det och ska säga mer senare. Det här med att programmen kraschar och att de inte är bra är ju en väldigt simpel sak att rätta till om man så vill, men jag tycker att programmet direkt ska stängas av när något sånt här händer.

Aja, det finns massor av ideér ute och ASLR och DEP får väl duga just nu men fram i tiden lär det komma bättre lösningar.

[Gäst al6]

Varför är comodos forum sämst? Min första tråd verkar vara låst av någon jävla moderator så jag kan inte säga att han som svarade på tråden har helt jävla fel, även på min andra tråd får jag inget svar, vad är det för påhittat skräp? Frustrerande...

[L-L]

Varför är comodos forum sämst? Min första tråd verkar vara låst av någon jävla moderator så jag kan inte säga att han som svarade på tråden har helt jävla fel, även på min andra tråd får jag inget svar, vad är det för påhittat skräp? Frustrerande...

Din första tråd är inte låst, men moderatorn 3xist har - alldeles för förhastat - flyttat hela CMF-tavlan till arkivet. När jag testar att svara så får jag dock ingen indikation på att den är låst.

Vad gäller din andra tråd så har både jag och en annan moderator kontaktat chefsutvecklaren. Om inget svar kommer... så är det nog inte mycket att göra.

[JoWa]

Din första tråd är inte låst, men moderatorn 3xist har - alldeles för förhastat - flyttat hela CMF-tavlan till arkivet. När jag testar att svara så får jag dock ingen indikation på att den är låst.

Det är nog endast moderatorer och administratörer som kan svara i arkivet. Ingen Reply-knapp för oss andra.

Vad gäller din andra tråd så har både jag och en annan moderator kontaktat chefsutvecklaren. Om inget svar kommer... så är det nog inte mycket att göra.

egemen har vaknat…

[Gäst al6]

Har fått svar angående "system" nu. Det är en säkerhetsmiss, men den är medveten och kommer inte att fixas. Min tråd ska tydligen tas bort från deras forum eftersom dom inte vill att virusmakarna ska veta att CMF och CSI ger absolut inget skydd vid användning av "system"-shellcode. Med andra ord är en upplyst virusmakare inte alls hindrad av CSI eller CMF när det gäller BO. DEP och ASLR är definitivt att föredra...

[L-L]

Med all respekt al6 så har jag generellt störst förtroende, i professionell mening, för Comodos chefsprogrammerare. Jag tycker att Comodo har bevisat mycket med Defense+. Och jag håller med honom i hans svar "Ok first of all, if you want me to continue this discussion further, please try to be civilized while writing messages.".

Det är dock en del av Egemens filosofi som jag inte förstår: Han erkänner problemet bara som ett problem om det börjar utnyttjas, och med detta som motiv är han beredd att ta bort din tråd. Detta känns verkligen inte som en preventiv åtgärd och jag hade gärna sett en större öppenhet inför din upptäckt av potentiell sårbarhet.

[Gäst al6]

Med all respekt al6 så har jag generellt störst förtroende, i professionell mening, för Comodos chefsprogrammerare. Jag tycker att Comodo har bevisat mycket med Defense+. Och jag håller med honom i hans svar "Ok first of all, if you want me to continue this discussion further, please try to be civilized while writing messages.".

Det är dock en del av Egemens filosofi som jag inte förstår: Han erkänner problemet bara som ett problem om det börjar utnyttjas, och med detta som motiv är han beredd att ta bort din tråd. Detta känns verkligen inte som en preventiv åtgärd och jag hade gärna sett en större öppenhet inför din upptäckt av potentiell sårbarhet.

Haha, blev lite frustread för att ingen tog till sig infon utan bara behandlade mig som ett skämt Men dom verkar ju arbeta på ett ganska avslappnat sätt: "bygg skydd först efter man blivit dödad"

Nåja, de kommer väl bättre skydd i framtiden

[JoWa]

En sak förstår jag inte: Egemen ger möjliga kompatibilitetsproblem som anledning till att CIS inte skyddar mot alla buffertöverskridningsattacker:

Then why dont we just add more hooks and make every single person on this planet happy? Because, adding hooks, although techically very simple, means additonal and unknown incompatibility problems. So we have to care for USER experience as well as security. A balanced approach has to be followed when you are a software vendor.

Om DEP/ASLR ger ett mer komplett skydd, måste det vara med risk för kompatibilitetsproblem? Är det därför DEP inte som standard är aktiverat för alla program och tjänster?

[Gäst al6]

En sak förstår jag inte: Egemen ger möjliga kompatibilitetsproblem som anledning till att CIS inte skyddar mot alla buffertöverskridningsattacker:

Om DEP/ASLR ger ett mer komplett skydd, måste det vara med risk för kompatibilitetsproblem? Är det därför DEP inte som standard är aktiverat för alla program och tjänster?

Du glömmer variabeln "bullshit" i din uträkning. Det är alltid lätt att skylla på kompatibilitet eller något sådant när man inte har en lösning. Det hade inte blivit ett enda problem i form av inkompatibilitet eftersom det finns en "undantagslista" i deras skydd, och även för att ett program som är uppbyggt att fungera genom att hela tiden köra shellcodes är så fruktansvärt sämst gjort att det inte ens förtjänar att köras på någon dator. Om man gör ett BO skydd som inte skyddar mot BO och ens försvar är "jo men vi vill inte stoppa alla BO's för då fungerar inte alla program" har man ju inte följt sin första idé; att skydda mot BO.

Jag tror snarare det rör sig om att dom har problem att hooka "system"-anrop för dessa inte tillhör Win32 och det då kanske inte är möjligt, det är vad jag tror.

[L-L]

Antingen så är det "bullshit" eller så är det en bedömning utifrån Egemens erfarenhet och kompetens. Det kanske är så att Egemen gör en bra bedömning här, på liknande sätt som man bedömer att 100% resultat i Matousec's läcktest är ointressant då något eller några test inte motsvarar verkliga hot. Kanske brist på verkliga hot kombinerat med funktionalitet och stabilitet är just vad som motiverar Egemens val.

Det enda jag inte riktigt gillar i allt detta är just att han vill sopa detta under mattan. Om sårbarheten finns, så är det väl bara en tidsfråga innan smarta virusmakare upptäcker sätt att utnyttja det. Så även om Egemen bedömer hotet som litet eller obefintligt idag, så kan det ju fortfarande bli aktuellt när som helst, oavsett om han tar bort din tråd på forumet eller inte.

[Gäst al6]

Alltså mina kunskaper om säkerhet är typ en månad gamla och knappast något att hänga i granen, men jag har en jävla kunskap om vanlig programmering och jag kan direkt säga att det inte hade varit det minsta lilla kompatibilitetsproblem om dom laggt in skydd mot "system". Och om det trots allt skulle ge massa falsklarm är det ju bara o trycka på "kom ihåg mitt val".

[Gäst al6]

På Channel9 kan man nu höra lite om vad för säkerhet Microsoft har laggt in i nya Visual Studio 2010.

http://mschnlnine.wmod.llnwd.net/a1809/d1/...sNext_s_ch9.wmv

Visual Studio 2010 borde vara en bra julklapp till grabbarna på Adobe Reader-teamet

[JoWa]

Hoppas att Apple får samma julklapp.

Om säkerhetsinnehållet i QuickTime 7.6.2

Notera att (heap) buffer overflow nu översätts till (heap-)buffertspill (tidigare buffertöverskridning). Men vad står heap för?

Notera också att Apple fixat problem med buffertspill i åtskilliga tidigare uppdateringar av QT Player: http://www.alltomxp.se/forum/index.php?s=&...st&p=118880

[Gäst al6]

Lite svårt o förklara utan o gå in på djupet. Heap är som en balja med minne som programmen kan ta från och allokera. Man kan egentligen ta bort ordet "heap" från alla meningar för det enda som är intressant är egentligen att det är en buffertöverskridning.

Heap-minnet används för o allokera dynamiskt minne medan stacken används för o allokera statiskt minne.

[JoWa]

Tack. Klarnade något.

[JoWa]

Detta ser ju inte så dumt ut.

Windows 7 offers numerous defensive enhancements designed to protect customers from malware. Applications that run on the platform should take full advantage of these defenses, as they are essentially free and could transform a coding error from what could be a serious vulnerability into a crashing bug. Windows 7 incorporates numerous defensive strategies to protect customers from exploits. Some of these defenses are in the core operating system, and the Microsoft Visual C++ compiler offers others. The defenses include:

• /GS Stack buffer overrun detection
  
• /SafeSEH exception handling protection
  
• No eXecute (NX) / Data Execution Prevention (DEP) / eXecute Disable (XD)
  
• Address space layout randomization (ASLR)
  
• Heap randomization
  
• Stack randomization
  
• Heap corruption detection
  

Källa: Logo Program Technical Requirements Doc (xps)