Ubuntu Sverige

"Stealthy Botnet Bug Infects Macs, PCs, Linux Machines"

Ju mer komplext programvaran blir, desto mer komplext är den skadlig koden, som en ny trojan som infekterar Windows-PC, Mac och Linux-boxar ingen är säker längre. Linux har varit relativt förskonad i många år. Men nu konstaterar många oberoende experter att den här bekymmersfri tillvaron är över.

"Even machines with rock-solid defenses fall prey to Java malware. In January 2013, Apple, Facebook and Microsoft had their corporate systems penetrated"

Om du har behov av en Java-aktiverad webbläsare för ett specifikt ändamål, installera endast Java-plugin på en utvald webbläsare. Du använder den här webbläsaren bara för just det ändamålet - ingen email, inga sociala medier, ingen slumpmässig surfa runt mentalitet.

Annars kommer du att be om problem.

Av: Paul Wagenseil för Tom's Guide US.

Källa: http://www.tomsguide.com/us/java-botnet ... 18260.html

Sårbarheten som trojanen utnyttjar åtgärdades för över ett halvår sedan, så det ska inte drabba ett Ubuntu-system om man har kört in alla uppdateringar.
Sedan förstår jag inte hur init.d kan uppdateras utan root-behörighet.

HakanS skrev:Sedan förstår jag inte hur init.d kan uppdateras utan root-behörighet.

Det bygger antagligen på att om root (eller en sudo-användare) kör ett infekterat program så är även init.d skrivbart...

Det är ju så korkat att Oracle har tagit bort möljligeten för distributionerna att ha deras java i repot. Så folk som kör oracles verison av java (tidigare sun-java) updaterar inte java på samma sätt som om det hade funnits i repot.

Jag vet en som inte har uppdaterat sina version ...

Java är ett ständigt säkerhetsproblem på alla OS det kan installeras på.

Skräpet måste utrotas.

JoWa skrev:Java är ett ständigt säkerhetsproblem på alla OS det kan installeras på.

Skräpet måste utrotas.

Och du rekommenderar istället?

JoWa skrev:Java är ett ständigt säkerhetsproblem på alla OS det kan installeras på.

Skräpet måste utrotas.

Nåväl, problemet är väl i första hand att Java fortfarande körs som webbläsare-plugin, och förväntas kunna sandlåda godtycklig främmande Java-kod? Jag menar, vetisjutton ifall jag skulle känna mig bekväm med att låta valfri webbplats köra säg python-kod i min webbläsare.

Ser inte nödvändigtvis med att använda Java för att köra fristående klient- alt. serverapplikationer.

Hur är det med open java? Det är väl det vanligaste på ubuntudatorer antar jag, själv använder jag i alla fall inget annat och den uppdateras ju ihop med övriga uppdateringar. Är det samma säkerhetsproblem med den ändå?

Både Firefox och Google Chrome har webbläsare-plugin för java delvis inaktiverat idag. Vill du vara helt säker kan du manuellt inaktivera din webbläsare-plugin för java helt och hållit. De allra flest webbplatserna fungerar utan din webbläsare-plugin aktiverad för java. De gånger du behöver funktionen, aktivera webbläsare-plugin tillfälligt. En omstart av webbläsaren kan vara nödvändig.

vulfgar skrev:Hur är det med open java? Det är väl det vanligaste på ubuntudatorer antar jag, själv använder jag i alla fall inget annat och den uppdateras ju ihop med övriga uppdateringar. Är det samma säkerhetsproblem med den ändå?

Är det detta du menar?

http://openjdk.java.net/

vulfgar skrev:Hur är det med open java? Det är väl det vanligaste på ubuntudatorer antar jag, själv använder jag i alla fall inget annat och den uppdateras ju ihop med övriga uppdateringar. Är det samma säkerhetsproblem med den ändå?

OpenJDK kan distribueras och uppdateras från förråden. Men javabuggarna kan ju finnas där ändå... Läs andols kommentar.

Personligen gillar jag java för att användas på servern, tomcat, jboss mm. Men swing-program uch

andol skrev:Nåväl, problemet är väl i första hand att Java fortfarande körs som webbläsare-plugin, och förväntas kunna sandlåda godtycklig främmande Java-kod? Jag menar, vetisjutton ifall jag skulle känna mig bekväm med att låta valfri webbplats köra säg python-kod i min webbläsare.

Chrome kommer snart inte att stödja NPAPI, Chrome för Linux redan i M34, som nu är i Dev-kanalen. (Linux-Aura stöder inte NPAPI.) Chrome OS, Windows RT, Android, iOS m.fl. stöder inte Java, så Java för webben hör tveklöst till det förgångna.

andol skrev:Ser inte nödvändigtvis med att använda Java för att köra fristående klient- alt. serverapplikationer.

Java-beroende program. Varför? Bättre att eliminera allt onödigt och osäkert skräp. Kommentaren gäller klienter. Hur och varför Java används på servrar vet jag inget om.

Vill man skapa program som inte är nativa, och som kan köras på olika system, är NaCl ett säkert alternativ.

Omg, activeX v2 native kod i browsern .
Jag såg inget om licenser eller om tekniken kan användas i andra browsers...

Om du med ”activeX v2” avser Native Client, är licensen BSD. Kan implementeras i andra webbläsare, men för närvarande är Chromium den enda implementeringen.

Att köra nativ kod (C/C++) i Chromium är mycket säkrare än att köra den utanför Chromium. Inte ens med AppArmor eller SELinux kan du komma i närheten.

Wikipedia: Google Native Client

JoWa skrev: Att köra nativ kod (C/C++) i Chromium är mycket säkrare än att köra den utanför Chromium. Inte ens med AppArmor eller SELinux kan du komma i närheten.

Bah!

Vilken säkerhet kan du få genom att sandlåda koden i Chromium som du inte även kan få genom att låsa ner ett program med AppArmor/SELinux?

Det sagt så kräver ju AppArmor/SELinux individuella regler, varpå Chromiums sandlåda i många fall säkert kan vara ett mycket mera realistiskt alternativ. Känns på det hela taget lite som att du jämför äpplen med päron.

Min avsikt var inte att jämföra Chromiums sandlåda med AppArmor/SELinux, som är ”äpplen” och ”päron”.

Poängen var att lugna den som är orolig för säkerhetseländet ActiveX i repris, med att ”nativ” kod i form av Native Client i Chromium är säkrare än den nativa kod som körs nativt, och även med generella sandlådor som är tillgängliga i olika Linux-distributioner, och vars användning är undantag snarare än regel. I Ubuntu är inte ens Firefox isolerat med AppArmor.¹

Chromiums sandlåda är mycket olik AppArmor/SELinux, och dess regler är mycket enkla: inget tillåts, något förenklat. Processerna i sandlådan har inte tillgång till filsystem och nätverk. Detta hanteras av mäklarprocessen. Via SeccompBPF blockeras alla systemanrop som inte är vitlistade. Det blir därmed omöjligt att utnyttja en sårbarhet i kärnan.

Native Client har en extra sandlåda, som kortfattat beskrivs här: https://developers.google.com/native-cl ... w#security

Mer om Software Fault Isolation för x86-64 och ARM här: https://research.google.com/pubs/pub35649.html och för x86 här: https://research.google.com/pubs/pub34913.html

¹ “Will be disabled by default and be opt-in for advanced users”

Svar till "mcNisse"

"Det är ju så korkat att Oracle har tagit bort möjligheten för distributionerna att ha deras java i repot."

"oracle-java7-installer"

Om du har behov av "Oracle (ex Sun) Java" så finns en möjlighet att använda följande "webupd8.org" egna förråd http://www.webupd8.org/2012/01/install- ... u-via.html. Jag har tidigare använt mig av deras förråd. Jag har endast bra erfarenheter vad berör skötsel av förråden. Andrew och medarbetare utför ett förträffligt arbete lika bra som Ubuntu. Så fort "Oracle (ex Sun) Java" släpper en uppdatering tar det oftast max 2 timmar sedan har du uppdateringen i din dator. Jag har idag inte behov av "Oracle (ex Sun) Java" så jag nöjer mig med Ubuntu Linux, open java.

Det här är ett privatägt förråd inte ett Ubuntu Linux kontrollerat förråd. Så beslutet är endast ditt eget.

@Pink Panther

Jag är mycket medveten att det finns sådana paket.
Det paketet innehåller ett skript som laddar ner och installerar java, allt annat är otillåtet om man ska följa Oracles licensregler.

Vad händer när någon bryter sig igenom sandlådorna? Då har nästa stora säkerhetshål.

Att någon med mycken möda och stort besvär bryter sig ut ur en sandlåda är inte ett större säkerhetsproblem än alternativet, att inte ha någon sandlåda. Det handlar om att minimera attackytan och göra det svårt att åstadkomma något. Att det är svårt men inte omöjligt visade Pinkie Pie hösten 2012: Exploiting 64-bit Linux like a boss. Att snabbt få ut uppdateringar är förstås viktigt.

Snart är det dags för nästa prövning: Show off your security skills: announcing Pwnium 4 targeting Chrome OS