A Symantec azt tanácsolja ügyfeleinek, hogy (ideiglenesen) álljanak le a pcAnywhere használatával

 ( trey | 2012. január 27., péntek - 12:00 )

Mint az ismert, a Symantec egyes termékeinek forráskódja publikus lett. Na nem azért, mert a cég azt nyílt forrásúvá tette, hanem azért, mert ahhoz illetéktelenek fértek hozzá. Ezt a cég a Facebookon elismerte. De nem csak hozzáfértek a kódokhoz, hanem azok egy részét publikálták is az interneten. A vállalat szerint nem a saját hálózatára törtek be, hanem egy 3rd party-tól szerezték meg illetéktelenek a forráskódokat. Eleinte a Symantec igyekezett nyugtatni az ügyfeleit, állítva, hogy régi - több éves - kódokról van szó és ráadásul az egyik érintett termék már nyugdíjazásra került. Viszont most arról ír a ComputerWorld, hogy a cég azt javasolja ügyfeleinek, hogy a álljanak le a pcAnywhere szoftver használatával addig, amíg ahhoz frissítés nem érkezik. A Metasploit mögött álló H.D. Moore, meglepődött azon, hogy egy Symantec kaliberű cég ilyesmire kéri ügyfeleit.

A részletek itt olvashatók.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"A vállalat szerint nem a saját hálózatára törtek be, hanem egy 3rd party-tól szerezték meg illetéktelenek a forráskódokat."

Ki az a barom aki kiadja egy ilyen szoftnak a kódját 3rd party-nak?

Es ha az a 3rd party irta a szoban forgo kodot?


Sic Transit Gloria Mundi

Gondolom az indiai katonaság úgy volt vele, hogy szeretné tudni, hogy igazából mit is vállal a Symantec.

----------------
Lvl86 Troll

Korábban a Symantec hazudott, amikor azt állította, hogy 3rd party-tól szerezték meg a forráskódokat.

Íme.

-------------------------
Trust is a weakness...

href=? :)

que?

-------------------------
Trust is a weakness...

Hoppá. Valamiért nem hozta be nekem a link célját, csak egy üres link tag volt ott, href nélkül. Már jó nálam is. Bocsi, csak azt hittem, hogy te hagytad ki.

Úgy is volt, amíg ki nem javítottam.

--
trey @ gépház

Köszönöm (ámbátor érdekelne, miből találtad ki, mit akartam linkelni). Előnézetben is megnéztem, működött, csak azután küldtem be a hsz-t.

-------------------------
Trust is a weakness...

Ott volt a link, csak lemaradt egy " a href-ből.

--
trey @ gépház

Köszi.

-------------------------
Trust is a weakness...

Ezzel el is astak magukat; vegervenyesen...

Most kellene GPL alá tenni a kódokat. Ha már úgy is kileakelték.

--
trey @ gépház

Hehe, meg a vegen joceg lenne.

Es akkor ehhez mit szolsz? :)

--
"You're NOT paranoid, we really are out to get you!"

Komolyan, orulok, hogy nem talalkozom ilyen termekekkel nap-mint-nap...

nocsak. a legujabb security auditjuk hibat talalt az eddig tokeletesnek eladott termekben ? :D)

openssh forrasa is elerheto, megis sokan hasznaljak. nem ertem en ezt :-)

--
NetBSD - Simplicity is prerequisite for reliability

closedsource-éknál nem értik ezt :)

Nem is értem, miért probléma ez? Rengeteg ismert forráskódú szoftvert használnak, magas biztonságot igénylő célokra is. Vagy netán a zárt kódú program lehet slendrián forráskódú, úgyis megfizetik a birkák?

Most azt akkarod mondani ,hogy az opensource termkek biztonsagosabbak mint a zart forraskodu termekek?
--
1 leszel vagy 0 élő vagy hulla!

Szerintem inkább a kód minőségére akart utalni.

es ha igen, akkor a symantec cuccok mostmar atleptek az uberbiztonsagos kategoriaba :D)

ez most flamebait vagy nem tudsz mondatot értelmezni?
mindkét eset rossz :-)

Majd most kiderül, bár úgy is megmagyarázzák, hogy ez azért van mert kikerült a kód.

Én szeretem a pcAnywhere terméket. Szerintem nagyon jó és üdvözlöm azt a lépést, hogy nyílt forrásúvá tették. Jó érzés, hogy meghallgatják a vevőik kívánságát. Szeretem a nyílt forrású alkalmazásokat, mert általában sokkal gyorsabban fejlesztik őket, mint a zártakat.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

[placeholder]

wtf did i just read :)

lol

Aham! BASH.hu szintu megszolalas :D

--
1 leszel vagy 0 élő vagy hulla!

Funkcionalis diszlexias vagy, vagy csak provokalod magad?

Vagy csak jobb a humorerzeke, mint egy 44-es cipotalpnak.

--
Pool is all luck, the more you play, the luckier you get.

egyik nem zarja ki a masikat

ellenben funkcionalis analfabeta helyett funkcionalis diszlexiat irni megintcsak nem kicsit fail :D

van a sima diszlexia, ami csak úgy van. és van a funkcionális diszlexia, ami funkcionál is :-)

Mi a baj a nyílt forrással?

if( !"fd!Pk".equals(passwd) ) throw new Exception();

A zárt forráskód önmagában semmilyen biztonsági védelmet nem jelent. Ha erre építette a vállalat a biztonságot, akkor cseszhetik a júzerek.

Gondolom viccnek szántad, de már találkoztam ilyen sorral kereskedelmi, zárt termékben.
Valahogy így nézett ki:

if(md5.ComputeHash(GetBytes("p*ssword")).Equals(md5.ComputeHash(GetBytes(input))))

Szóval a srácok már hallottak valamit a biztonságról :)

Mentségére legyen mondva, minimális felelősségű software volt.

looool, ezt ok se gondolhattak komolyan :D:D

Meglehetősen sok cuccban van ilyen. Viszonylag legitim módon lehet teszt kódban (pl unit teszt futás közben nincs LDAP, de mégis kell valami dummy authenticator). Normális körülmények között a teszt kód nem fordul bele a végleges binárisba. Ha valamiért mégis belekerül, akkor ott egyéb komoly bajok is lehetnek.

Aztán előfordul, hogy a telepítés utáni, még az elés jelszó beállítása előtti bootstap folyamat részeként szerepel ilyen kód. Ez már nagyobb antipattern, mert nehéz ellenőrizni, hogy nincs-e olyan támadási vektor, hogy valahogy utólag be lehessen kapcsolni ezt a bootstrap üzemmódot, vagy esetleg valami return to libc-szerű stack manipulációval ráfuttatni a végrehajtást.

Ha meg az éles autentikátor kódban van ilyen, arra nincs mentség.
---
Internet Memetikai Tanszék

Ha az eles kodban van ilyen, az disasm kodbol is latszik, szoval ha egy ilyen remote desktop alkalmazas kodjaban van ilyen, az mar reg rossz.

--
Pool is all luck, the more you play, the luckier you get.

Egyrészt nem feltétlenül látszik, mert kereskedelmi termékeknél ma már eléggé jellemző, hogy valami obfuscatort rázavarnak. Más kérdés, hogy ez csak arra jó, hogy "megszűrje" a próbálkozókat, így csak azok fogják tudni visszafejteni, akik eléggé értenek a témához. Az ilyenek pedig már tudnak exploitot is írni.

Egyébként pedig ha nem csak ilyen remote desktopban gondlkodsz, akkor elég sok olyan szerver-oldali alkalmazás juthat eszedbe, aminél az első használatkor tipikusan "admin/admin"-nal kell belépni (utána persze rögtön meg kell változtatni). Na szerinted ezt hogy szokták implementálni?!
---
Internet Memetikai Tanszék

nyelvtol es forditotol fuggoen, akar a text-be is kerulhet.
talaltam mar master passwordot .exe-ben, notepaddal...

A jelszó hashben "illik" tárolni, mert abból a jelszó nem állítható vissza.

Az "illik" azért van zárójelben, mert ritka kretén az, aki a kódba beleégeti a jelszót.

A probléma ezzel sem oldódik meg, mert ha mindenki látja a letárolt jelszó hasht, ahhoz rohadt erős jelszavak kellenek, nem 8 betűsök.

Az a baj, hogy gyorsulnak a gépek, de 25-50 karakteres jelszavakat az emberi agy már nem képes rendesen kezelni. Szóval a probléma nem egyszerű.

"A probléma ezzel sem oldódik meg, mert ha mindenki látja a letárolt jelszó hasht" akkor egy szivárványtáblával megfejthető a jelszó.

ugyanakkor meg szokta'k so'zni, onnantol kezdve mar ugy nagyjabol nyugi van.

Remélem tiszta, hogy mi az a hash.
- fogod a jelszót
- előállítasz belőle egy bájtsort valamilyen kódolással, ezt letárolod
- a felhasználó beírja a jelszót
- előállítod ugyanazzal a kódolással belőle a bájtsort
- összehasonlítod a bájtsorokat

A bájtsorból a jelszót bizonyos kódoló algoritmusoknál csak brute force kereséssel lehet visszaállítani. Magyarul egyesével mindent végigpróbálni.

Remélem tiszta, mi az a szivárványtábla. Csak mert ha trivialitásokat írsz valós érvek helyett (végy példát apal-ról), akkor az ennek ellenkezőjét bizonyítja.

Főleg, hogy md5 önmagában végképp nem túl biztonságos megoldás, amiről fent szó volt.

Én azt nem értem, miért válaszolgatnak itt kioktató stílusban még akkor is, amikor fogalmuk sincs mire válaszolnak :) Mindenesetre én már nem várom el azt sem, hogy olvasson utána, mivel tőle tudjuk, hogy "a C rossz szerkezetű nyelv". :)
--
HUPbeszolas FF extension

Azért írtam 25-50 karakteres jelszavakat. Az lenne biztonságos, mert nem tudsz akkora táblát már eltárolni, csak ahogy kifejtettem, az emberi agy limitál.

Elvekről beszéltem, az MD5-öt szóba sem hoztam.

Egy 50 karakteres táblához 1e+99 jelszót kell tárolni. Nem hiszem, hogy van ekkora kapacitás jelenleg a földön.

Abban igazad van, hogy a szivárványtáblának nem olvastam utána, bocs. Igazából azért mellőztem az utánaolvasást, mert 25-50 karakteres jelszónál már minden trükközés felesleges. Ha egy jelszó feltörése 3-5000 év, akkor szivárvány tábla ide, vagy oda cseszheted az egészet. Elvi síkon közelítettem meg a problémát, nem a gyakorlati ma létező oldalról.

A 8-10 karakteres jelszavak semmi védelmet nem jelentenek.

Remélem, tudod mi az a kulcsütközés.

Tudom, de felesleges a securitybe belebonyolódni.

Készítek egy 10000 karakteres jelszót, amit 10k-s hash-ben tárolok el (matematikailag bizonyítottan jó algoritmussal). Ugorj neki, azt törd fel.
Ha minden századik ütközik egy másikkal, az sem segít rajtad sokat.

A hash önmagában alkalmas a jelszavak tárolására, csak a jelszó hosszával van a gond.

Ekkora baromsagot mi koze a hashnek a jelszo hosszahoz?

Ketto kozul melyik a hosszabb a jelszo?

cbd20675bd47820695b3757667ebde91
vagy
608b7859b0c6db6ef2aaecb79006a27b
--
1 leszel vagy 0 élő vagy hulla!

Hát, van köze.

1000 betűs jelszót tárolj 2 byte-os hash-ben. Magadtól is rá fogsz jönni, hogy nem tuti.

"A hash önmagában alkalmas a jelszavak tárolására, csak a jelszó hosszával van a gond."
Te nem tudod, mi az a hash es mire jo. Osszekevered a csapoajtofuggvenyekkel. A hasheknek soha nem celja bijektivnek lennie, ezt nem vetted figyelembe eddig. Amit te szeretnel, az egy bijektiv csapoajtofuggveny, ilyen is letezik, lasd RSA, illetve Diffie-Hellman . Amirol viszont tudni lehet, hogy rendkivul koltseges kiszamitani egy hashhez kepest.

Nem írtam, hogy kölcsönösen egyértelműnek kell lenni a jelszó hashnek sehol. Vagy ha igen, kérlek mutasd meg.

Akkor miért növeltem meg a hash méretét 10k-ra?

Valószínűleg azért, mert ha 32 bites hash-t választok, akkor az 10000 hosszú jelszó teljességgel felesleges, mert az első 32 karakteren nagy valószínűséggel lesz ütközés egy ennél rövidebb jelszóval.

Magyarul: ha 10000 hosszú jelszót akarsz biztonságosan hash-elni, minimalizálva az ütközést, ahhoz legalább 10000 hosszú hash kell, ha nem több.

Hiába használsz 10000-es jelszót, ha 256 bájtos a hashed. Mert akkor az első 256 jelszónál nagy valószínűséggel lesz ütközés és az idő tört része alatt bejutnak.

Miért ennyire nehéz ezt megérteni??? Őrülten fárasztó.

Ha 10k hosszu a hash egy 10k-s jelszonal, es van kulcsutkozes, akkor sokat nem nyertel vele. Ha meg nincs kulcsutkozes, akkor az bijekcio.
"Valószínűleg azért, mert ha 32 bites hash-t választok, akkor az 10000 hosszú jelszó teljességgel felesleges, mert az első 32 karakteren nagy valószínűséggel lesz ütközés egy ennél rövidebb jelszóval."
A jo hashfuggvenyek peldaul ugy vannak megcsinalva, hogy 1 bit valtozas a bemeneten a kimenet bitjeinek legalabb felet megvaltoztatja.
Abban igazad van, hogy 32 karakteres jelszavakkal van kulcsutkozes, de lesz olyan 32 karakteres jelszo, amivel nincs kulcsutkozes (pont az elobbi miatt).

jelszavaknal ez pont nem (olyan nagy) problema, mert a specialis karakterek (jo esetben) ki vannak zarva, igy joval nehezebb utkozest talalni.

Amugy en igy csinaltam egy protokolban:
1. A szerver ismeri az SHA-1 hash-t a jelszorol es general egy random 64 karakteres stringet, amit atkuld a csatlakozni kivano kliensnek.
2. A user beuti a jelszot es a kliens program legeneralja az SHA-1 hash-t.
3. Az elobb generalt hash-hez hozzadobja a random stringet ES az egeszrol keszit egy MD5 hash-t. A szerver is elvegzi ugyanezt.
4. A kliens atkuldi az MD5 hash-t a szervernek.
5. A szerver osszeveti a ket hash-t es ha egyeznek akkor beenged.

Nem tul egyszeru es valoszinuleg nem is tokeletes, viszont a bejelentkezes mehet titkositatlanul, a jelszavak sehol sincsenek letarolva, es a replay tamadasok sem fognak rajta.

Quakenet CHALLENGEAUTH

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Igen, hasonloan volt megoldva, de egeszen mas felhasznalasra. :)

Mondjuk azt nem ertem, hogy miert vagjak le a jelszot...

Arrogans FAIL :) Amugy meg subscribe, ebbol jo thread lesz. :)
---
Review Home

en kodolas helyett transzformaciot irtam volna, amugy igaza van.
a salt nem a hash eljaras resze szigoruan veve.

Illetve kerlek osszad meg velunk, miben nem egyezik a velemenyetek.

Az, hogy a forum kollega (BaT) egy teljesen legitim modszert irt hashelt jelszok megfejtesere, erre arrogans stilusban erkezett a valasz, mikozben fogalma sem volt rola hogy mire valaszol, hogy mi az a szivarvany tabla, milyen fajta relevanciaval bir az adott temahoz es ennek elleneres is a valasz hozzaszolasbol sugarzik a kioktato hangvetel es arrogancia.
---
Review Home

Egyáltalán nem akartam kioktatni, sőt arrogáns sem akartam lenni. Sajnálom, ha ez jött le a dologból.

Persze, csak miután leírták, hogy miért hülyeség, amit mondtál, jöttél egy "Remélem tiszta, hogy mi az a hash." kezdetű hozzászólással, mintha BaT-nak fingja nem lett volna, hogy mi az a hash. ;)

----------------
Lvl86 Troll

Szerintem ülj be valami biztonságtechnika alapjaival foglalkozó előadásra egy egyetemen. Egyrészt _senki_ nem fog megjegyezni 50 karakteres random krix-krax jelszót. Az nagy valószínűséggel szimpla szavak egymás után esetleg cifrázva a kis/nagybetűt, itt-ott számot + egy kis zavart, és mindjárt máris lecsökken egy egész kezelhető mennyiségre a szivárványtábla, ha szótárral indulsz neki.

Másrészt jellemzően MD5-t használnak, aminek az értékkészlete már kisebb, mint az 50 alfanumerikus karakter önmagában (Csak laza 51 nagyságrenddel ;). Hiszen 32 db és csak 16 féle van belőle (ha hexastringként írjuk ki).

----------------
Lvl86 Troll

Bocs saxus,

a hozzászólásom azzal kezdem, hogy az emberi agy limitálja a jelszavak hosszát. Leírtam idáig kétszer, de most megteszem harmadszor is.

Az MD5-ről véletlenül sem beszéltem, mert ugye a hash != MD5.

Kérlek állj le és ne izélgess azzal, hogy üljek be egy informatika kezdő tanfolyamra, mert azt mondtam, hogy a számítógép pedállal működik.

Nem mondtam, kösz.

Mondjuk én előadást mondtam egy egyetemen, nem egy kezdő tanfolyamot, sebaj.

----------------
Lvl86 Troll

Nem mondtam, hogy nem értesz hozzá, max. azt nem érted, amit mondtam.

Az egész sztoriról nekem a Gyaloggalopp jut leginkább az eszembe.

- Minden amit látsz itt, a tiéd fiam!
- Az ablak papa?
- Nem
- Akkor az ablakkeret
- Nem fiam
- Megvan, a függöny papa!

Körülbelül erről szólt az elmúlt 10 hozzászólás.

:)))

Troll: Quote fail. :-(

Gondolom az egyszer kiszámolt hasheket szigorúan tilos tárolni és egyből az NSA rohamkommandósai fogják rádrúgni az ajtót, ha ezáltal megpróbálod picit meggyorsítani a törést.

De semmi gond, ismerünk még 1-2 olyan titkosító eljárást, ami elvileg törhetetlen, aztán gyakorlatban mégis van rá trükk.

----------------
Lvl86 Troll

Kar ezen kapalozni, a beegetett konstans jelszavaknak megvan az a tulajdonsaguk, hogy eloszeretettel szivarognak ki a gyartotol. :)

--
"You're NOT paranoid, we really are out to get you!"

Hát, igen.

Sokkal olcsóbb adni egy csokit Mariskának, mint 100.000 géppel brute force nekiesni a kódtörésnek.

:)

Viszont a Certificate Authority-k például megőrzik a privát kulcsukat.
Mondjuk a Verisign cég csődbe is menne azonnal, ha a feltört privát kulcsukkal elkezdenének weblapokat aláírni.

Ha érték számukra a jelszó/privátkulcs, mert a megélhetésük függ tőle, akkor vigyáznak rá.

Attól hogy kereskedelmi és zárt forrású a termék, még bőven van helye a hakkolásnak.

a) kereskedelmi, zárt termék esetén a megrendelő veri az asztalt minimális késésnél is
b) ha a ficsőr megvan, senkit sem érdekel a kód hatékonysága és tisztasága, főleg hogy zárt forrásról beszélünk (maximum a következő szerencsétlent akinek karban kell tartania)

A b) pont miatt szokták emlegetni az opensource cuccokat mint rosszul tervezett, silány minőségű kódot. Naná, hiszen ott van a public repóban, és mindenki láthatja.

--
http://neurogadget.com/

Azért ez nem egészen így van. Én inkább úgy látom, hogy bár alapvetően mind open, mind closed source szoftverek esetén vannak jól, és rosszul megírt szoftverek, más az oka a minőségnek (vagy annak hiányának).

Open source* szoftverek esetén leginkább a fejlesztők igényességén múlik a szoftver minősége. Nincs megrendelő, aki visszautasíthatná a szoftvert, a felhasználóknak pedig hiába rossz a véleménye, bevételkiesés nem fog emiatt történni. Persze ha megfelelő emberek vezetnek egy projectet, ők visszautasíthatnak kódokat az igényesség hiányára hivatkozva, csak ennek a project szenvedheti kárát az érintett fejlesztők elpártolása miatt (lásd ffmpeg). Viszont nincsenek szigorúan vett határidők, ezért van idő jól átgondolt kódot írni.

Closed source esetén a fejlesztők érdeke az igényesség. Ha rossz minőségű szoftvert készítenek, azt visszautasíthatja a megrendelő, vagy nem fogják megvásárolni a felhasználók. Ráadásul ha egy fejlesztő nem képes betartani a minőségi irányelveket, bármikor elbocsátható és pótolható (abba most ne menjünk bele, hogy ez azért ennyire nem egyszerű). A minőség érdekében a fejlesztés során software review-k során ellenőrzik a forráskódot. Viszont vannak határidők, a fejlesztőket a fejlesztés során fizetni kell, ezért a késés nagyobb költséggel járhat, mint egy kevésbé jól megírt szoftver kiadása. Főleg, ha az adott szoftver a maga területén monopolhelyzetben van. (Jó példa erre a xilinx ise, ami (amennyire én tudom) a xilinx fpga-k kizárólagos fejlesztői környezete. Mivel egy fpga kiválasztásában a fejlesztői környezet sokadrangú szempont, ezért elég, ha a szoftver csak azt a szintet üti meg, ami miatt még nem lesznek a cég termékei kerülendőek.)

*: itt elsősorban azon szoftverekre gondolok, amiket közösségi alapon, profitszerzés célja nélkül fejlesztenek

Idézet:
Closed source esetén a fejlesztők érdeke az igényesség.

Ööö... izé... én több helyen is részt vettem kódátvételben - az utóbbi pár évben a megrendelői oldalon, és a zárt forrású cuccok kódminősége mindig messze rosszabb volt, mint az átlagos open source projektek kódminősége. Tapasztalataim szerint a kódminőség az utolsó utáni szempont, közvetlenül a tesztelésre hagyott elegendő idő előtt. A határidő vége felé pedig megjelennek olyan workaroundok, amelyekről az igényesség jut legutoljára az ember eszébe.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"a zárt forrású cuccok kódminősége mindig messze rosszabb volt, mint az átlagos open source projektek kódminősége"

Elhiszem, hogy a te esetedben ez így volt, de ebből még nem érdemes általánosítani.

"Tapasztalataim szerint a kódminőség az utolsó utáni szempont, közvetlenül a tesztelésre hagyott elegendő idő előtt. A határidő vége felé pedig megjelennek olyan workaroundok, amelyekről az igényesség jut legutoljára az ember eszébe."

Ezt próbáltam leírni ebben a mondatban, igaz kicsit homályosan fogalmaztam: "Viszont vannak határidők, a fejlesztőket a fejlesztés során fizetni kell, ezért a késés nagyobb költséggel járhat, mint egy kevésbé jól megírt szoftver kiadása."

Nyilván nem minden projecttel tegnapra kell végezni, illetve adott esetben a késés miatti többletköltséget kompenzálhatja a magasabb minőségi követelményeknek megfelelő szoftver alacsonyabb üzemeltetési igénye. Tehát itt több, egymásnak ellentmondó szempont van, és sok esetben sajnos bizonyos szempontok csak a kódminőség rovására érvényesülhetnek. De ez még nem zárja ki, hogy sok esetben jobban megéri jobb minőségű kódra, ezáltal jobb minőségű szoftverre törekedni még az emiatt megnövő fejlesztési költségek és időigény miatt sem.

Értem én, de akárhány hasonló munkakörben tevékenykedő emberrel beszéltem, mind erre panaszkodott: a gyenge kódminőségre és a tesztelés hiányára. Megkérdezhetem, hogy hány zárt forráskódú termék átvételénél voltál jelen? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mint minden virusirto gyarto, ez is csak szemetet tud gyartani, gondolom ez latszodik most a kod minosegen is.

A biztonsagtechnika ott kezdodik, hogy grsec/PaX, vagy valamelyik BSD kernel, szerintem egy BSD dev beleolvasna akarmelyik virusirto forraskodjaba, hulyere rohogne magat.

Hamarabb röhögnek az ilyen hozzászólásokon, mint e tied :)
--
HUPbeszolas FF extension

Ezt most olvasd el megegyszer.

Mi köze a BSD _kernel_ -nek a vírusvédelemhez? Szerintem semmi. Linuxra is szokták mondani hogy immunis a vírusokra, a tény viszont az hogy nem szeretnek rá vírust írni, így viszonylag kevés készült rá eddig. A BSD -kre ez valószínűleg fokozottan igaz. De ez könnyen megváltozhat, az elméleten semmit sem ront.

"Mint minden virusirto gyarto, ez is csak szemetet tud gyartani"

Gondolom a világ összes jelentősebb security cégénél dolgoztál, így megalapozott a kijelentésed.

--
http://neurogadget.com/