- A hozzászóláshoz be kell jelentkezni
Hozzászólások
# ls -la $(which sudo)
-rwsr-xr-x 1 root root 120168 2007-05-04 13:36 /usr/bin/sudo
De látom pont ehhez nem kívánnak nyúlni. :)
--
2e845cb4c3a5b5bd6508455b1739a8a2
- A hozzászóláshoz be kell jelentkezni
Le van írva miért.
- A hozzászóláshoz be kell jelentkezni
Ezt most kivételesen elolvastam, mielőtt beküldtem. Nem szokásom.
--
2e845cb4c3a5b5bd6508455b1739a8a2
- A hozzászóláshoz be kell jelentkezni
Vegre, valaki eszre vette, hogy van File Capabilities.
Hany ev kellett hoza ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Naponta kerülnek nyilvánosságra biztonsági hibák a Linux kernelben, így aztán a setuid binárisokkal kapcsolatos problémák kihasználása maximum nosztalgiázásra vannak.
Mondhatnám úgy is, hogy 1992AD... :)
- A hozzászóláshoz be kell jelentkezni
A naponta eros tulzas.
De ilyen erovel minden biztonsagi megoldas folosleges, ugy is admin hiba miatt megy a levesbe leggyakrabban.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
A naponta eros tulzas
Valóban, jószándékú alulbecslés, mert van amikor naponta több is jön ki.
De ilyen erovel minden biztonsagi megoldas folosleges
Ha számodra ez következik abból amit írtam, akkor erősen rosszul gondolkodsz.
- A hozzászóláshoz be kell jelentkezni
Hol lehet ezekről hibákról olvasni?
Lehet érdeklődés hiányában távolítják el a setuid -okat.
Úgy néz ki már a nosztalgia sem a régi ;-)
- A hozzászóláshoz be kell jelentkezni
http://secunia.com/advisories/product/2719/?task=statistics_2010 (a nem patchelt-nek jelzett mar patchelt regen a bugzilla szerint)
Valaki esetleg ettol tobbet mondot ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Lehet nem Secunia statisztikákat kellene nézegetni, hanem a valóságot. :)
Ezen a diagramon annyira röhögtem konkrétan, hogy be is kopiztam egyik linux security csatira. Dan Rosenberg (aki épp a minap kapta meg pont 1 hónap késés után az általa jelentett - grep segítségével pár perc alatt talált - 16+(!) kernel hibára a CVE-t) is erősen kérdőjelezett, hogy ezt hogyan számolták ki. Ráadásul nemhogy "extremely", de még "highly critical" besorolást se kapott egy sebezhetőség se egész évben? Kac-kac... :)
- A hozzászóláshoz be kell jelentkezni
ennek a "16+ kernel hibának" utánanéztem.
Arról van szó, hogy pl. 16 byte-nyi stack területet nem inicializálnak nullával, így ez a memóriarészlet visszakerül a felhasználóhoz.
Szerintem ennek a hibának valós jelentősége közelít a nullához. Milyen törésre alkalmas adatot lehet megszerezni 16byte-ból?
- A hozzászóláshoz be kell jelentkezni
Ha a jelszavad van benne (vagy épp a root jelszó akkor már :)), akkor kb. bármilyenre. :)
De az a baj, hogy a lényeget nem sikerült megragadni. Pont a legcikisebb és persze legsúlyosabb hibák nincsenek felsorolva az oldalon.
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
"Pont a legcikisebb és persze legsúlyosabb hibák nincsenek felsorolva az oldalon."
#define Criticality_HIGH "Typically used for remotely exploitable vulnerabilities that can lead to system compromise. "
Mondj ilyet.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
2009 -es, es egy alig hasznalt protokol, azert inkabb helyileg lehett vele jatszani, hasonloan az AppleTalk -hoz.
Es mindeketto olyan elhallgatott hiba volt, hogy mindenki olvashatott rola itt is.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Ne terelj, remote kernel vuln vagy nem? Volt ezen a konkrét SCTP-n kívül is sok más - további SCTP-s és egyéb protokollt érintő - távolról kihasználható bug, csak erről leírás és exploit is került ki a nyilvánosság elé, így egyszerűbb rá hivatkozni (főleg, mert ezt is DoS-nek akarták beállítani, mint sok más kernel sebezhetőséget).
Mellesleg ez a - szerinted - alig használt protokoll egy rakás nagy telco céget érintett szerte a világon. Az hogy te nem használod a desktop linuxodon, vajmi kevéssé releváns az elterjedtségét illetően.
- A hozzászóláshoz be kell jelentkezni
Ne terelj, a 2010 -es statisztika volt a tema.
Meg az allandoan elokerulo elhallgatott HIGH sebezhetosegek tema. (neha naponta akkar 2 is)
SCTP -es exploitod igenyel egy bejelentkezett felhasznalot, igy nem remote, de anyit bizonyit, hogy nem LOW hanem MODERATE.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
1. Semmiféle bejelentkezett felhasználót nem igényel, faszságokat beszélsz. Egy remote kernel privesc pedig se nem low, se nem "moderate", ha a besorolás ennél a kettőnél több lehetőséget ad.
2. Mint írtam van egy jópár 2010-es remote vuln is, újabb SCTP bugok és mást érintő sebezhetőségek is, de ha azokat hoztam volna példának, akkor jöttél volna azzal a hülyeségeddel, hogy nincs rájuk publikus exploit, úgyhogy nem is léteznek, vagy legalábbis nem kihasználhatók...
3. Az általad oly pontosnak tartott Secunia "34 advisories from 2010" statisztikája annyira hiteles, hogy még a CVE adatbázisban is 80 találat van a linux+kernel+2010 keresésre. Erről mellesleg még LWN cikk is született nem rég, amelyben szintén szerepel, hogy ez a 80 db CVE bejegyzés is csak a "known security vulnerabilities".
Mellesleg az LWN cikknél ilyen Linux security szempontból senkik, mint Kees Cook az Ubuntu Security Team-ből is megerősíti, hogy ezek csak a "known issues" és ennél jóval több sebezhetőség van valójában. De te, turul16, az NI portása ezt nyilván jobban tudod...
- A hozzászóláshoz be kell jelentkezni
1. Hunger, rossz cikket linkeltel, a blog elozo bejegyzese szol a remote exploitrol.
2. Azert nem mind arany ami fenylik, attol meg hogy messzirol nezve kihasznalhatonak latszik kozelrol nezve meg nem biztos hogy az.
Ha valamire azt mondanam, hogy nem kihasznalhato akkor meg te jossz azzal hogy vak vagyok.
3. secunia -mar akkor gyanus volt, amikor egy nem patchelt-nek jelzett egy patcheltet. Kosz a pontosabb szamot.
Ha tobb local DoS -tol komolyabb letezik, akkor miert lusta mindenki azt jelezni ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Lusta jelezni? LOL, egy csomó alkalommal lett jelezve, de mindig ment a terelés és a mellébeszélés (ahogy te is teszed épp), csak akkor volt észbe kapás, ha exploit is publikálásra került.
- A hozzászóláshoz be kell jelentkezni
> Mint írtam van egy jópár 2010-es remote vuln is,
Hűha, akkor ez komoly. Távolról leterít egy frissiben telepített 2009.x Ubuntut?
- A hozzászóláshoz be kell jelentkezni
vagy hozzáférést biztosít a csodaforráskódjaidhoz, a "naprakész" fedorádon
- A hozzászóláshoz be kell jelentkezni
Hűha, akkor ez nagyon komoly. Gyorsan le is húzom a gépet a ne
- A hozzászóláshoz be kell jelentkezni
Az, hogy mennyi mindenre használható akár 4 byte infoleak (te meg még 16 byte-nyit se értesz, huh?!) hozzáértőnek nem kell taglalni... Neked meg ezek szerint nem érdemes.
- A hozzászóláshoz be kell jelentkezni
stílus -1
- A hozzászóláshoz be kell jelentkezni
Hogy is mondják, amilyen a fogadj Isten?
Ha nem okoskodtál volna tudatlanul a témában, én se így válaszolok.
"utánanéztem" ... "valós jelentősége közelít a nullához"
- A hozzászóláshoz be kell jelentkezni
problémáid vannak, fordulj szakemberhez.
- A hozzászóláshoz be kell jelentkezni
Ééés bedobtad az ultimate hup-os aduászt, nyertél.
- A hozzászóláshoz be kell jelentkezni
Nem, nem úgy mondják :))
- A hozzászóláshoz be kell jelentkezni
kommutatív
- A hozzászóláshoz be kell jelentkezni
> Ha nem okoskodtál volna tudatlanul a témában, én se így válaszolok.
A többi olvasó nyilván nem számít neked.
- A hozzászóláshoz be kell jelentkezni
te legalábbis semmiképp
- A hozzászóláshoz be kell jelentkezni
Egyes szakertok szerint a hup.hu -n levo "Információ" doboz mar eleg sulyos info leak.
Az info leak jelegu hibak nehol kulon vannak osztalyozva a tobbitol. (Leven valahol nem fer bele a normal skala legaljaba..)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Melyik intervallumra gondolsz?
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni