Titkosítás, biztonság, privát szféra

Biztonság: titkolózás vagy nyilvánosságra hozás?

``No security through obscurity''

Mikor szolgálja tulajdonképpen a hibák nyilvánoságra hozása a biztonságot? Amikor a biztonság szóba kerül általában két ellentábor két különböző megközelítésből vizsgálja a problémát. A nyílt forrású közösség a ``nincs biztonság a titkolózással'' nézetet vallja. Ez azt jelenti, hogy szerintük minden hibát azonnal és teljes terjedelemben nyilvánosságra kell hozni. Ennek megfelelően számos full disclosure lista érhető el az Interneten, ahol tájékozódni lehet az éppen aktuális bugokról, hibákról.Ezzel éles ellentétben áll a Második Világháború ismert mondása a ``loose lips sink ships'' (beszédes ajkak hajókat süllyesztenek el). A legtöbb katonai és hírszerzési szakértő szerint a titkosság kritikus eszköz a biztonság megőrzésében.

Peter P. Swire az Ohio State University munkatársa készített egy tanulmányt ``A Model for When Disclosure Helps Security: What is Different About Computer and Network Security?'' címmel. Ebben a munkában a szerző arra keresi a választ, hogy vajon melyik megközelítés áll legközelebb a valósághoz. A munka megvizsgálja, hogy mi az hátránya és mi az előnye a teljes közlésnek.

A munkát megtalálod itt.

Komoly Kerberos(5) hibák

Az Eweek szerint a Massachusetts Institute of Technology (MIT) kutatói komoly hibákat találtak a Kerberos Key Distribution Center-ben (KDC).

A javítások még váratnak magukra, de a Cisco egyes Kerberost használó VPN routereihez már napvilágot láttak a javítások.Az hibákat komolynak jelzik a szakemberek. Az egyik ilyen hiba a ``double free''-nek nevezett bug, amelyben a tisztítást végző kód kétszer próbálja meg ugyanazt a puffert kiüríteni. Mikor ez történik, a rosszindulatú felhasználónak lehetősége van a Kerberost támadni (tetszőleges kódfuttatás). A másik hiba az ASN.1 bug, amelyet kihasználva a modul ``fennakad'' és ez a Kerberos leállásához vezethet.

MIT hibajegyek:

MITKRB5-SA-2004-002-dblfree.txt

MITKRB5-SA-2004-003-asn1.txt

A cikk itt.

SSHD / AnonCVS Port Bouncing támadás

Idén novemberben (11-12) rendezik Japán fővárosában a már hagyományosanak mondható PacSec/core4 (Pacific Security Japan) konferenciát.

A konferencia honlapja már elérhető, és rajta az ``advisories'' szekcióban olvasható egy biztonsági figyelmeztető, amely szerint minden olyan SSHD-t futtattó szerver támadható egy bizonyos port bouncing technikával, amelyen engedélyezve van a AllowTcpForwarding opció (alapértelmezés szerint engedélyezve) és emellett valamilyen publikus hozzáférést is biztosít.A publikus hozzáférés lehet akár egy népszerű AnonCVS hozzáférés, vagy bármilyen más ``publikus'' hozzáférés. A figyelmeztetést kiadók erősen javasolják az AllowTcpForwarding opció tiltását olyan gépeket, amelyek ilyen vagy ehhez hasonló publikus szolgáltatást biztosítnak. Ellenkező esetben a gép könnyen lehet mondjuk spammerek áldozata.

Az érintett SSH verziók:

- az összes újabb OpenSSH-t futtató szerver, amelynek van publikus szolgáltatása

- bármilyen egyéb SSH daemon, amely támogatja a TCP port forwarding-ot

Javítás:

echo "AllowTcpForwarding no" >> /etc/ssh/sshd_config

A figyelmeztető itt.

Ütközéseket találtak jópár hash függvényben

Fránya gépek. Minden jól kezdődött, amikor augusztus elején pár kriptoanalízissel foglalkozó tudós úgy döntött, hogy elmegy valahová nyaralni, mert a gépteremben sosem lesznek elég barnák, a csajok meg nem csípik a falfehér pasikat.

De hogy ne egye hiába az a 256 Itanium 2-es processzorral felszerelt desktop PC a drága áramot, adtak hát neki valami egyszerű feladatot. Nem volt más dolga, mint végigszámolni egy képletet, más-más bemenő adatokkal, egymás után 2251799813685248 alkalommal. Ezen egy kicsit elgondolkozott, majd 13 nap múlva küldött egy SM-et a tengerparton lubickoló egyik gazdájának.

Mivel a szóban forgó PC Unix szerű oprendszert futtatott, az üzenet ez volt:

"$ diff fic1.bin fic2.bin

Binary files fic1.bin and fic2.bin differ

$ openssl sha fic1.bin

SHA(fic1.bin)= c9f160777d4086fe8095fba58b7e20c228a4006b

$ openssl sha fic2.bin

SHA(fic2.bin)= c9f160777d4086fe8095fba58b7e20c228a4006b"

Szerencsére hősünknek olyan mobilja volt, amely képes egyben megjeleníteni a 160 karakternél hosszabb üzeneteket, így észrevette a nagy hírt: ütközést találtak egy kriptográf hash függvényben.A fenti sztori kitaláció, a bejelentés viszont úgy tűnik, hogy nem.

Kicsit kusza még a dolog, így egyelőre csak annyi látszik biztosnak, hogy lassan érdemes lesz elkezdeni felhagyni az MD5 (és talán az SHA) alkalmazásával és átállni valami komolyabbra. Hogy mi lesz az a komolyabb, egyelőre nem világos, mint ahogy az sem, hogy pontosan mit is találtak a kutatók és azt milyen széles körben tudják használni.

A fő szenzáció mindenesetre biztosan nem az, hogy ütközést (azaz két olyan, egymástól eltérő bemenetet, amely a függvényből ugyanolyan kimenetet hoz elő) találtak, hanem az, hogy ezt sokkal gyorsabban meg tudják tenni, mint azt eddig egyesek hitték.

Linkek a további olvasgatáshoz:

http://www.tcs.hut.fi/~mjos/md5/
http://www.mail-archive.com/cryptography@metzdowd.com/msg02554.html
http://www.freedom-to-tinker.com/archives/000664.html

Újabb rendkívül kritikus hibák az Internet Explorerben

Azt hittem, hogy az Internet Explorer már nem tud meglepni... Meg tud. A Secunia mai figyelmeztetője szerint négy új, rendkívül kritikus hibát találtak a Microsoft böngészőjében. A hibák között találunk spoofing, system access, security bypass hibákat is.... Az érintett verziók: Microsoft Internet Explorer 5.01, Microsoft Internet Explorer 5.5, Microsoft Internet Explorer 6

A Secunia a hiba orvoslására a következőket javasolja: tiltsuk le az Active Scripting-et, használjunk más terméket....

A Secunia figyelmeztetője itt.

Előzzük meg a Denial of Service típusú támadásokat

Szolgáltatás-megtagadás típusú támadás. Kedvenc eszköze a script kiddieknek, akiknek tudásuk kevés ahhoz, hogy egy rendszert feltörjenek, de ahhoz elegendő, hogy ismert programokkal olyan támadásokat indítsanak a célszerverek ellen, amelyek ezen támadások következtében felhagynak normális működésükkel, és többnyire teljesen elérhetetlenné válnak.Alattomos fajtája a támadásoknak, és meglehetősen kellemetlen is egyben, mert egyes fajtái ellen meglehetősen nehéz védekezni.

A DoS támadás irányulhat erőforrások ellen. Például a sikeres támadás felemésztheti a szerverek, routerek CPU idejét, memóriáját, a file handler-eket, a hálózati sávszélességet, stb.

De irányulhat egy szolgáltatásban jelen levő programozási hiba ellen is, amelyet kihasználva a szolgáltatás felfüggeszti működését, vagy éppen az egész szerver omlik össze tőle.

De mit lehet ellene tenni? És hogy jön képbe a FreeBSD?

A DoS támadásokat és az ellenük használható ellenlépéseket tárgyalja az O'Reilly Network BSD DevCenter rovatának ezen cikke.

RSBAC v1.2.3

Megjelent az RSBAC 1.2.3-as verziója. Az RSBAC jelentése Rule Set Based Access Control. A név egy gyors, flexibilis, nyílt forrású (GPL) hozzáférés szabályzási keretrendszert (access control framework) takar napjaink Linux kerneleihez.

Az anyag 2000. januárja óta gyakorlatilag stabilan használható. A fejlesztése nem függ egyetlen kormánytól vagy nagy cégtől sem, és nem tartalmaz újrafelhasznált kódokat más hasonló munkákból.AZ RSBAC támogatja a 2.4-es és 2.6-os Linux kerneleket, amelyekhez mint biztonsági kiegészítés használható. Számos jól ismert és új biztonsági modellt alkalmaz (pl. MAC, ACL, RC).

Újdonságok az RSBAC 1.2.3-ban:

New features in RSBAC v1.2.3:

General:

* Port to 2.6 kernel series with many internal changes

* Full log separation between system and RSBAC log

* Improved hiding of unaccessible processes

AUTH:

* Learning mode, global and per-process

RC:

* System boot role, now separate from root's role

* Extra process type for kernel threads for explicit access control

* Types for user objects

DAZ:

* New 100% compatible Dazuko (www.dazuko.org) module

* On-access scanning through user space antivirus daemons

* In-kernel scanning result cache, speeding it all up significantly

ACL:

* Global learning mode

PAX:

* New PaX support module

JAIL:

* Several security related and other bugfixes (it is strongly

recommended to update)

* Linux capability restrictions for jailed processes

MAC:

* Trusted-for-user list instead of single value

Amon Ott bejelentése itt. A projekt honlapja itt.