(via sekurity_matters) Az RSA OTP token bizonyos körökben státusszimbólumnak számít. Matt Walker találmánya mögött nincs felsőbb matematika, nem merül le, nincs gond az óraszinkronnal, de a hülye is tudja használni, és akár nagy felhasználószám mellett is olcsó. A PassWindow nem más, mint egy kilyuggatott kártyalap, amely egyszerű de nagyszerű birtoklás-alapú védelmet biztosít alkalmazásai számára:

A kártyákon a hétszegmenses kijelzők LED-jeinek megfelelő lyukacskák vannak vágva bizonyos helyeken. A hitelesítést kérő szoftverek szintén ilyen személyre szóló, szegmensekből álló képeket generálnak beléptetéskor. A kártyát a generált kép elé helyezve előtűnik az egyszer használatos számsorozat, amivel beléphetünk. 

A PassWindow legnagyobb hibája talán az, hogy az "ablakok" könnyen és gyorsan lemásolhatók, ezért a komolyabb helyekről valószínűleg nem fogja kiütni a bevált eszközöket, de kisebb biztonságot igénylő alkalmazások esetén nagy fantáziát látok a megoldásban. 

Ez nem egy marketingposzt, egyszerűen tetszik az ötlet :)

PS: Aki nem látta volna, ezt a szokatlan, fapados jelszómenedzsment eszközt is mindenképpen érdemes szemügyre venni!

Aki figyeli a Twittert (vagy a FD-t), az már néhány napja értesülhetett róla, hogy Kingcope távoli kódfuttatásra alkalmas exploitot publikált a Microsoft IIS 5-ös verziójának FTP kiszolgáló komponensére. A probléma elvileg az IIS 6-ot is érinti, de ott a megfelelő stackvédelem miatt csak szolgáltatásmetagadásra adhat lehetőséget. A sebezhetőség a hosszú könyvtárnevek helytelen feldolgozásából adódó veremtúlcsordulás, emiatt a legnagyobb veszélyben azok a kiszolgálók vannak, melyeken engedélyezett a könyvtárlétrehozás anonymous felhasználók számára. 

Az Offensive-Security videója szemlélteti a támadást IIS 5-ön.

A Microsoft elismerte a problémát, és dolgozik a javításon.

Frissítés: Úgy tűnik, IIS 5 esetében előidézhető DoS írási jog nélkül is.

Mikor megjelent az Apple legújabb operációs rendszere, az OS X Snow Leopard, első gondolatom az volt, hogy vajon teljesültek-e a

Dino A. Dai Zovi által is emlegetett kernel szintű biztonsági intézkedések, mint pl. az Address Space Layout Randomization vagy a Data Execution Prevention?

Első körben persze a hivatalos oldalon néztem körül, de csak halvány utalásokat találtam ezekre a funkciókra. Ez persze már gyanúra adott okot, de konkrétumokat csak ma olvastam a Registeren: a Zovi, és munkatársa, Charlie Miller által végzett tesztek azt mutatják, hogy sem a stackre, sem a heapre, sem a dinamikusan linkelt könyvtárak címtartományára nem alkalmazták az ASLR-t (hülye kérdés: akkor mire?). A DEP esetében már jobb a helyzet, de a támadók egyik legvonzóbb célpontja, a Safari álltólag még mindig nincs felvértezve a nem-futtatható memóriaterületek által nyújtott védelemmel.

A kutatók hangsúlyozzák, hogy ez a kiadás remek alkalmat biztosított volna az Apple-nek, hogy - több korszerű operációsrendszerhez hasonlóan - végre foganatosítsák ezeket a védelmi intézkedéseket, ezt a lehetőséget azonban úgy tűnik, eljátszotta a cég. 

Mindennek különösen kellemetlen következményei lehetnek manapság, mikor a kedves feketekalapos kollegák lassanként rákapnak az egyszeri Mac felhasználók adatainak leszipkázására is. Ugyanis szép dolog az áttekinthetőbb felhasználói felület, meg a beépített víruskergető, de ezek eddig sem jelentettek túlzottan nagy kihívást a rosszfiúk számára. Utóbbi úgyis leginkább a vicc kategóriát ékesíti.  

Már eddig is sok levelet kaptam, melyek feladói arról érdeklődtek, hogy hogyan kellene felvenniük a kapcsolatot egy-egy céggel miután különböző biztonsági hibákat fedeztek fel a szolgáltatásaikban. Az utóbbi idők egyik flame-je megadta a végső lökést egy kis GYIK összeállításához, melyet itt olvashattok el:

Kis útikalauz szürkekalaposoknak

Remélem hasznát veszitek!

Ma reggel a leginkább HTTP szerver megoldásairól híres Apache Software Foundation szakemberei szokatlan tevékenységre lettek figyelmesek a szervezet egyik éles webszerverén, ezért rövid utánajárás után úgy döntöttek, hogy elővigyázatosságból lekapcsolják az infrastruktúrát.

Mint kiderült, egy külső hoszting szolgáltatónál elhelyezett, backup célokra használt SSH kulcsok segítségével rosszindulatú támadók sikeresen bejelentkeztek a minotaur.apache.org szerverre, ahová különböző fájlokat, többek között CGI szkripteket helyeztek el. Ezeket a szkripteket automatikus mechanizmusok később feltöltötték a www.apache.org-ot kiszolgáló számítógépre, ahol le is futtatták őket. Ez után nem sokkal lettek figyelmesek a helyi rendszergazdák a rendkívüli eseményekre, és a megfelelő óvintézkedések megtétele után a weboldalra érkező kéréseket átirányították egy nem érintett, európai szerverükre. A kiadott közlemény szerint a végfelhasználókat nem érinti a támadás.

A támadás körülményeit még vizsgálják, bővebb tájékoztatást későbbre ígérnek.

James Slater olyan problémát fedezett fel a Twitter szolgáltatásban, melynek kihasználásával tetszőleges JavaScript kód szúrható a szolgáltatás webes felületére, így pofonegyszerűen összehozható egy aranyos kis Twitter-féreg, amely pusztán egy-egy mikroposzt megtekintésekor képes megfertőzni a gyanútlan felhasználókat. 

A problémát az okozza, hogy az új, külső alkalmazások (amilyen pl. a Twitterfeed vagy a TweetDeck) regisztrálására szolgáló űrlapon nem szűrik megfelelően az alkalmazás weboldalának megadására szolgáló beviteli mezőt, melynek tartalma minden, az adott alkalmazással küldött csirip alatt megjelenik. Ebbe a mezőbe kártékony JavaScriptet illesztve az összes, minket követő felhasználó böngészőjében lefut a kis kódunk, mellyel hozzáférhetünk az illető profiljához, új posztokat küldhetünk, vagy egyszerűen csinálhatunk egy átirányítást valamilyen trükkös kódokkal teletűzdelt weboldalra. 

A szolgáltatót természetesen értesítették a problémáról, és született is egy javítás: azt azonban mindenki tudja, hogy egy élelmes programozót nem állítanak meg olyan apró akadályok, mint az, hogy nem lehet szóközt használni a kódban. Egyelőre nem érkezett hír arról, hogy ennél jobb védelmet alakítottak volna ki, óvatosan böngésszük hát a webes felületet!

Sikerült átfutnom a múltkor sietve belinkelt, WPA támadásról szóló tanulmányt, remélem sikerül helyretenni a dolgokat:

• Emlékeztetőül: az új módszer a Beck-Tews támadás továbbfejlesztése, amely eredetileg 802.11e QoS képességekkel rendelkező szolgáltatások esetén tudja visszaállítani a hálózaton küldött csomagok integritásellenőrzéséhez használt MIC kulcsot, és ezzel csomaghamisítást (valamint rövid, pl. ARP csomagok esetén nyílt- szöveg-visszaállítást) tesz lehetővé 12-15 percen belül (sokat kell várni a hibajelzésekre, tehát a nagyobb számítási kapacitás önmagában nem segít)
• Remélem ezek után egyértelmű, hogy a támadás az "egyszerű" WEP+TKIP=WPA protokollal szemben érvényes, a WPA2-AES még mindig jól tartja magát
• A B-T támadás a WEP-es chopchop támadás kiterjesztése, amely kihasználja, hogy 802.11e esetén több adatcsatornán kommunikálhatunk, és minden adatcsatornán más TKIP szekvenciát használunk.
• Az új, Ohigashi-Morii-féle támadás megszünteti a 802.11e-re vonatkozó követelményt ezzel kiszélesítve a sebezhető infrastruktúrák halmazát...
• ...feltételezi ugyanakkor, hogy közbeékelődéses támadást lehet végrehajtani a hálózaton. Ez pl. úgy lehetséges, ha a vezetéknélküli hozzáférési pont a kliens hatókörén kívül esik, a támadó viszont mindkét végpontot eléri, és így képes ismétlőként a két legitim fél közé állni, valamint módosítani a rajta keresztülhaladó csomagokat.
• Az egész játék arra megy ki, hogy olyan helyzetet idézzünk elő, hogy olyan csomagokat tudjunk az AP felé továbbítani, melynek TKIP szekvenciaszáma kisebb, mint az aktuális IV - ezt úgy érjük el, hogy nem továbbítjuk a klienstől érkező csomagokat azonnal az AP felé.
• A közbeékelődéses elrendezés lehetővé teszi, hogy különböző típusú forgalmak esetén különböző csomagtovábbítási stratégiákat válasszunk, ezzel csökkentve a chopchop támadásból adódó hálózati kiesés érzékelhető hatását. Pl.: nagyszámú ARP csomag érkezése esetén nekiállhatunk a kulcsvisszaállításnak, míg kvázi-valósidejű, interaktív forgalom esetén késleltetés nélkül engedhetjük tovább a csomagokat. Így az érzékelhető hálózati kiesés ideje 1-4 perc közé szorítható.
• Habár egy fent vázolt közbeékelődéses szituáció csak viszonylag ritkán valósul meg, a szakértők - amennyiben lehetséges - a WPA(-TKIP) használatának mellőzését, helyette a WPA2-AES bevezetését javasolják.

A Google biztonsági csapata frissítést adott ki a Chrome böngészőhöz. Javításra került egy sandboxon belüli kódfuttatásra és egy illetéktelen memóriaolvasásra lehetőséget adó probléma, de ami sokkal érdekesebb az az, hogy a Chrome ezentúl nem lesz hajlandó kapcsolódni azokhoz a hitelesítést használó (HTTPS) weboldalakhoz, melyek tanúsítványában a rég óta gyengének tartott MD2 vagy MD4 üzenetpecsét-algoritmusokat alkalmazzák. Éljen!

Egyelőre kommentár nélkül, a most megjelent tanulmány bevezetője:

2008-ban Beck és Tews közzétett egy gyakorlati támadást a WPA ellen. Ez a támadás (melyet Beck-Tews támadásnak neveznek) vissza képes állítani a nyílt szöveget egy titkosított rövid üzenetből, majd meghamisítani azt. A Beck-Tews támadás futási ideje nagyjából 12-15 perc. Ugyanakkor a támadásnak megvan az a korlátja, hogy csak azokat a WPA megoldásokat érini, melyben megvalósítják a IEEE 802.11e QoS szabványt. Ebben a tanulmányban gyakorlati üzenethamisításos támadást mutatunk be az összes WPA megvalósítással szemben. Hogy a célpontokra vonatkozó korlátozásokat enyhítsük, a Beck-Tews támadást közbeékelődéssel [MitM] együtt alkalmazzuk. Egy közbeékelődéses támadás során a felhasználó kommunikációját elfogja egy támadó amíg a támadás tart. Ez azt jelenti, hogy a felhasználó észlelheti a támadást, ha az elég sok ideig tart. Emiatt olyan módszereket mutatunk be, mellyel a támadás futási ideje csökkenthető. Ennek eredményeként az általunk bemutatott támadás futási ideje legjobb esetben egy percre csökkenhet.

Néhány európai konferencia a hideg évszakokra:

• CONfidence, Varsó: még nincsenek a hivatalos oldalon  infók a 6., varsói rendezvényről, de az időpont november 19-20. lesz, és a CfP már ki van írva.
• SOURCE, Barcelona: Megjelent a beosztás. Az időpont szeptember 21-22, ütközik a Hacktivity-vel...
• Sicamp, Pozsony: Kevésbé biztonsági témájú rendezvény, szeptember 16-18. között, de ide is kellenek a gondolkodó koponyák

A Hotmail ideiglenesen beszüntette a közvetlen képbeágyazási lehetőséget webes levelezőrendszerében, mivel egy Internet Explorerrel történő használat esetén előkerülő biztonsági problémát fedeztek fel a szolgáltatásban. Részleteket ugyan nem tudni, de a Coimputerworld információi szerint ismét egy hibás ActiveX vezérlő állhat a háttérben, melynek megfoltozását a cég a szeptemberi frissítőkeddre igyekszik időzíteni. Ez már talán elég támpontot adhat az elegendő felfedezőkedvvel megáldottaknak, hogy versenyezzenek kicsit a Microsoft hibajavítási ciklusával...

Tegnap egy másik érdekesség is landolt a postaládámban: secretworld hívta fel a figyelmem, hogy Benszi posztolt egyet a - bizonyos körökben egyébként állatorvosi lónak számító - Citromail néhány hibájáról. Bár természetesen remegve várjuk a javítást, sajnos az ementálifoltozáshoz nem fűzök nagy reményeket...

pzs írta:

fórumomban linkeltek egy adatlapot, itt: http://userscripts.org/topics/17920?page=11#posts-155350

Az xss-t kihasználva (jelen pillanatban) csak egyedi háttérképet állított be magának a gyerek [az iwiwen], ami ilyen szintig még poén, de írtam iwiwnek (ebben a pillanatban), h javítsák már - kíváncsi leszek a reakcióidőre.

Amúgy munkahely webcímhez lehet xss-t írni (régi és új fajta munkahely megadásnál is működik) - de úgyis látni fogod.

Ha gondolod, publikáld, bár lehet kéne várni vele kicsit, hátha gyorsan javítják.

Más: indapass.hu-n is van xss, ott a jelszó emlékeztető boxba lehet írni email cím helyett a kódot. És ahogy próbáltam úgy is lehet sessiont lopni, ha csak blog.hu-ra vagy belépve, ill. jelszó emlékeztető belépett állapotban is működik - ami akkor nem lenne létszükséglet.

ezt meg bezlapat:

egy "apró" persistens xss sebezhetőséget találtam az index fórumban. a
következőről van szó:
új hozzászólás írásakor felvehetünk linkeket ("új link:" sor). itt
megadhatunk egy url-t és egy "szöveg"-et. elsőre szépen szűri a bemenő
adatot, viszont módosításnál már nem teszi ezt meg. ergo módosítás
után tetszőleges html kódot tudunk beilleszteni a hozzászólásunkba

Az illetékeseket értesítettem, a publikáció időpontjával igyekeztem egyensúlyt találni a felelős és a hatásos nyilvánosságrahozatal között...

Mialatt a nagyobb Linux disztribútorok gőzerővel igyekeznek megfoltozni az általuk szállított kerneleket a több mint két éves, de csak nem rég óta nagyobb nyilvánosságnak örvendő NULL pointer dereferenciával szemben, addig az Android felhasználók örülhetnek a lyukas rendszermagnak:

Egy zinx névre hallgató hacker egy olyan kis alkalmazást készített, amely a fenti kernel sebezhetőséget kihasználva egy gombnyomásra lecseréli a készülék rendszervisszatöltő képét a cyanogen változatára, melynek segítségével tetszőleges egyedi Android buildet tölthetünk a telefonra: 

Részletes instrukciók itt találhatók.

Bár nem új a történet, a magyar weben még nem nagyon láttam cikkeket a témában: Egy újdonsült botnet a szokásos IRC csatornák helyett új felületet választott a vezérlőközpont(okk)al (C&C szerverekkel) való kapcsolattartásra - a parancsok és frissítések a Twitterre és más mikroblog szolgáltatásokra csiripelődnek ki. 

Szerencsére a hálózat gazdája nem használt kifinomult eszközöket a vezérlés megvalósításakor, így többen vették a fáradtságot, és nekiálltak utánajárni, hogy mit is csinálnak az élőhalott madárkák. A beszámolók szerint Twitterre kiposztolt üzenetek mind base64-el illetve bizonyos URL-rövidítő szolgáltatásokat vannak kódolva, így elolvasásuk nem jelent különösebb problémát. A bit.ly statisztikái szerint néhány száz gép lehet megfertőzve, nagyrészt Brazíliában. A bejegyzések ezután online vágólap szolgáltatásokhoz (pl. az Ubuntuéhoz vagy a Debianéhoz) vezetnek, ahol szintén base64 kódolású adatokat találunk. Rövid ügyeskedés után kiderül, hogy ezek az adatok ZIP-pel tömörített fájlokat rejtenek, melyeket nem véd jelszó. Kicsomagolás után DLL és EXE formátumú frissítéseket találunk az erdeti kártevőhöz, melyeket a VirusTotalnak odaadva elég siralmas eredményeket kapunk (20-47%, AV gyárók, szevasztok!). Az egyelőre nem világos, hogy a különböző komponensek pontosan milyen funkciót látnak el. 

A mikroblog szolgáltatások ilyen célú használata érdekes ötlet: mivel gyakorlatilag mindegyikük felajánl valamilyen weben keresztül elérhető API-t, nem kell külön IRC klienst írni a botnet kliensekbe, valamint a böngészőn keresztüli tunelezéssel sem kell külön foglalkozni (mivel a böngészőt általában minden otthoni tűzfal alkalmazás kiengedi, sok kártevő ezeket a mindenhol meglévő eszközöket használja kommunikációra). A fenti hálózat esete azonban jól mutatja, hogy mivel a felhasznált online szolgáltatásokat jóval szigorúbban monitorozzák, mint az IRC-t, csak rövid ideig lehet rajtuk keresztül megbízhatóan kommunikálni.

Ysombor említette a napokban, hogy mostanában gagyi IQ tesztekkel próbálják rávenni az egységsugarú netezőket, hogy eladják a lelküket valamelyik direktmarketinges bandának - mit eladják, még a kedves felhasználó fizethet azért, hogy az adataival kereskedjenek! Kitöltöd a tesztet, de hogy az eredményt megtudd, a mobilszámoddal kell fizetned, és a kitűnő szolgáltatásért cserébe minden hónapban a számládra terhelnek.

Egyik reggel én is belebotlottam egy ilyen kvízbe (a H-Security-n :P), gondoltam végignyomogatom.

A Google biztonsági csapatának szakemberei több NULL pointer dereferenciát eredményező problémát fedeztek fel a Linux kernel 2.4-es és 2.6-os verzióiban, beleértve a legfrissebb stabil változatokat is. A hiba a socketekhez rendelt proto_ops struktúra kezelésében leledzik, amely egy socketen végezhető műveletekre tartalmaz mutatókat. Amennyiben egy művelet az adott socketen nem végezhető el, a mutatókat előre meghatározott függvénycsonkokra kell irányítani, a konkrét megvalósításban azonban ez néhány esetben elmarad. És bár az ilyen jellegű problémák kiküszöbölésére a kernel a legtöbb helyen ellenőrzi a struktúra mutatóinak megfelelőségét, bizonyos protokollok bizonyos műveletei esetében erre ugyancsak nem kerül sor, ami már biztonsági kockázatot jelent.

Linus Torvalds tegnap adott ki foltot a problémára. 

Frissítés: közben látom, hogy a HUP is megírta a dolgot, exploit van itt 

Frissítés 2: Egyszerűbb, letisztultabb exploit itt: http://www.frasunek.com/proto_ops.tgz

Kumar Kandaswamy, az eBay fejlesztői programjának egyik vezetője mai blogposztjában arra figyelmeztet, hogy olyan problémákat találtak az eBay fejlesztőknek szóló portáljában, amely lehetővé tette, hogy illetéktelenek hozzáférjenek az oldalon regisztrált felhasználók belépési adataihoz. A hiba nem sodorta veszélybe a tagok személyes ill. pénzügyi adatait, valamint nem érinti az eBay hagyományos felhasználóit sem, de az eBay API-t használó fejlesztőknek ajánlatos új jelszót választani a portálra történő belépéshez (Valamint ha ne adj' Isten valaki ugyanazt a jelszót több helyen is használta, úgy célszerű minden érintett regisztrációt frissíteni).

Megjelent a Safari böngésző 4.0.3-as változata, amely több súlyos biztonsági problémát orvosol. Ezek közül több alkalmas távoli kódfuttatásra Windows és OS X rendszereken, valamint több adathalászatra alkalmat adó sebezhetőség is javításra került. Ezek közül az egyik segítségével rosszindulatú weboldalak helyezhetők a "Top Sites" lista élére, erről bővebb információ és példakód is elérhető itt.

• MS09-036: Szolgáltatásmegtagadásra lehetőséget adó probléma a .NET keretrendszerben. Amennyiben az érintett hoszt IIS 7-et futtat, és az ASP.NET integrált módra van konfigurálva, egy speciális, hitelesítetlen HTTP kéréssel elérhetetlenné tehető a kiszolgáló. A klasszikus módra konfigurált ASP.NET kiszolgálók nem érintettek.
• MS09-037: Egy újabb ATL sebezhetőség, amely a bejelentkezett felhasználó nevében tesz lehetővé kódfuttatást. A probléma külső gyártóktól származó szoftvereket is érinthet.
• MS09-038: A Windows Media komponens két sebezhetőségét javító csomag. A foltozoss hibák lehetővé teszik, hogy speciális AVI fájlokon keresztül rosszindulatú kódot futtassanak az érintett rendsezreken, a bejelentkezett felhasználó nevében.
• MS09-039: A WINS szerver egy távolról kihasználható, kritikus sebezhetőségének javítása. A probléma lehetővé teszi, hogy egy hitelesítetlen támadó SYSTEM jogosultsággal hajtson végre parancsokat az érintett, Windows 2000 ill. 2003 Server rendszereken. Aranyos...
• MS09-040: Jogosultságkiterjesztésre alkalmas probléma javítása a Windows Message Queuing Service-ben. A komponens alapértelmezetten nincs telepítve, ezért a probléma csak "Fontos" besorolást kapott.
• MS09-041: A Windows Workstation Service egy hibájának javítása. A probléma lehetővé teszi, hogy érvényes belépési információkkal, de korlátozott jogkörrel rendelkező felhasználók parancsokat hajtsanak végre távolról az érintett rendszereken, adminisztrátori jogkörrel.
• MS09-042: Távoli kódfuttatásra alkalmas sebezhetőség a Windows Telnet szolgáltatásban. Nagyon remélem, hogy ilyet már senki nem használ...
• MS09-043: Speciális weboldalak segítségével, távoli kódfuttatásra alkalmas hibák javítása az Office Web Componentsben.
• MS09-044: Távoli kódfuttatásra alkalmas sebezhetőség javítása a Távoli Asztal szolgáltatásban. A probléma kihasználásához a célfelhasználót rá kell venni, hogy egy rosszindulatú RDP kiszolgálóhoz csatlakozzon, de ez megoldható akár egy weboldalon elhelyezett ActiveX vezérlő segítségével is. A szoftver Mac-es változata is érintett.

Az alábbi képen látható a fenti sebezhetőségek súlyosság szerinti besorolása (kattints a nagyobb képért):

Az 1-es Exploitability Index azt jelenti, hogy a Microsoft szerint 30 napon belül megjelennek a problémát kihasználó exploitok, ezért ezeket a frissítéseket különösen komolyan kell venni.

A Tom's Hardware ismét interjút készített Charlie Millerrel, aki ezúttal a BlackHat-en hívta fel magára a figyelmet azzal, hogy SMS-eken keresztül kihasználható, kódfuttatásra alkalmas iPhone sebezhetőségeket mutatott be a nagyérdeműnek (a nem tólzottan kimerítő tanulmányt itt olvashatjátok).

Teljes fordítást most nincs erőm csinálni (így is van egy félkész a TODO listámban), de a lényeget azért megpróbálom összefoglalni:

Amennyiben egy SMS fejlécében nagyobb hosszúságú üzenetet jelzünk, mint amennyi adatot valójában küldünk, az egyik ellenőrző eljárás hibajelzásként -1-et ad vissza, ami még nem lenne baj, de ezt a visszatérési értéket az SMS-kezelő folyamat többi résztvevője hajlamos valódi adatként kezelni. Így például előfordulhat, hogy a telefon 0xFFFFFFFF (kb. 4 GB) méretű memóriafoglalás kezdeményez, ami nyilván sok lesz szegény iPhone-oknak - az előadás során egy bátor jelentkező telefonját így sikerült is néhány órára kivonni a forgalomból.

Hasonló (a cikkben nem részletezett) elven elérhető, hogy többrészes SMS-ek esetében az iPhone szoftvere a beérkező SMS-részeket tartalmazó tömb előtti memóriacímhez  (a tömb -1. byte-jához) próbáljon hozzáférni, és így alkalmat adjon kódfuttatásra. Mindehez több mint 500 SMS-re van szükség, mivel egyrészt "rendbe kell tenni" a memóriát, másrészt át kell lépni a processzor XN flagje által kikényszerített korlátozásokon, amely az x86-os NX bithez hasonlóan megakadályozza a stacken ill. heap-en lévő adatok futtatását.

Miller kiemelte, hogy ez a támadás különösen veszélyes, hiszen az SMS-ek fogadását nem lehet kikapcsolni, az SMS-ben érkező kártékony kódok a felhasználó akaratától függetlenül lefutnak, ráadásul a feldolgozást végző folyamat root jogosultságokkal fut, így korlátozásmentes hozzáférés szerezhető az érintett készülékekhez.

A TH rákérdezett arra is, hogy az iPhone-ok lelki világát az átlagnál lényegesen jobban ismerő kutató hogyan vélekedik azokról a hírekről, melyek a bázisállomások tönkremenetelével riogatják a kedves vásárlókat. Miller válasza röviden annyi volt, hogy mindez "teljes baromság": A jailbroken iPhone-ok firmware-e ugyanis alig különbözik az eredetitől, a szolgáltatóval történő kommunikációt végző részek nem is változtak. Másrészt ha egy terroristának mindössze egy megberhelt iPhone-ra van szüksége a BSC-k kinyírásához, akkor bizony szarban van a haza.

Index:

"Néhány feltört iPhone túlterhelte a T-Mobile rendszerét, ezért a szolgáltató behívta ezeket a készülékeket, hogy új szoftvert tegyen rájuk. A frissítés a törés végét is jelenti egyben."

Érdekes módon a két másik szolgáltató (akinek nincs szerződése az Apple-lel) nem számolt be ilyen problémákról... Néhány hete az Apple kezdett el FUD-olni, hogy a jailbreak kinyírja szegény tornyokat, de könyörgöm, még ha igaz is a történet: mi az, hogy egy egyszerű elektronikai eszközzel térdre lehet kényszeríteni a mélyen tisztelt szolgáltatókat? A hiba lehet, hogy nem a mi készülékünkben van...

Egyébként az Index cikkéhez annyit fűznék hozzá, hogy az iPhone-ok - a Dev-Team szerint - mindaddig jailbreakelhetők és függetleníthetők maradnak, amíg baseband hardverét meg nem változtatják [najó, erről mégsem vagyok 100%-ig meggyőződve, erősítstetek/cáfoljatok, ha úgy érzitek].  

Helyi idő szerint csütörtök reggel egy elosztott túlterheléses támadás következtében néhány órára leállt a Twitter, valamint a Facebook és a FriendFeed is haldokolni kezdett. A Twitter internetelérését biztosító Arbor Networks tájékoztatása szerint a Twitter hasznos sávszélessége több mint 200Mbps-ről mintegy 60Mbps-re esett vissza 9:00 óra környékén. 

Ryan Naraine biztonsági szakértő szerint az eset kapcsolatban állhat a Twitteren terjedő Koobface féreg legújabb változatának megjelenésével.

Frissítés:

A Webisztán közben megírta a tutit: állítólag egy grúz júzert akartak így elhallgattatni. Én azért szkeptikus vagyok ezzel kapcsolatban...

A 10.5.8-as verziófrissítés számos biztonsági hibát orvosol, ezek közül a leglényegesebbek az alábbiak:

• Kódfuttatásra alkalmas hibák a ColorSync, Image RAW, ImageIO komponensekben: speciális képek megnyitásakor rosszindulatú kódfuttatásra nyílik lehetőség.
  ImageIO: CVE-2009-1722, CVE-2009-1721, CVE-2009-1720
  Image RAW:  CVE-2009-1728
  ColorSync: CVE-2009-1726
• Jogosultságkiterjesztésre alkalmas probléma a kernelben: CVE-2009-1235
• Format string hiba a bejentkezőképernyőt megjelenítő kódban:  CVE-2009-2191
• Puffer túlcsordulás a hálózatkezelő komponensben: speciális AppleTalk  csomagokkal távoli kódfuttás érhető el (CVE-2009-2193)

Ezen a héten erre vagyok képes, hehe :) 

Szóval már jó ideje benne él a "köztudatban" az alábbi szösszenet, az egyik tegnapi beszélgetés végre eszembe is juttatta, hogy megkeressem (remélem az alkotók nem veszik zokon, ha kicsit promótálom a dolgot):

...az előadásról ezt leszámítva egyébként csupa jót hallottam:) 

Ezt a másik képet pedig Laca küldte, személyes üdvözlettel fűszerezve:

Pénteken egy hazai különítmény is útra kel a Plumbercon-ra, és részben a HAR-ra is. Ha valakinek van kedve csatlakozni, még van hely a kocsiban az odaútra (ha valaki esetleg a HAR-t is megcélozza, akkor jó eséllyal a visszaútra is). Ha valakit érdekel ez a remek lehetőség, írjon nekem  (buherator, gmail), vagy keresse dnet-et!

(Többen kérték hogy írjam ki: HAR-ra elfogytak a jegyek, ezért a hollandiai történet nyilvánvalóan csak azoknak érdekes, akiknek már megvan a jegye!)