JohnnyCage

Microsoft: Ázsia nem játszik tisztességesen

A redmondi szoftveróriás szerint Japán, Kína, és Dél-Korea közös terve egy ingyenes Windows rivális operációs rendszer készítésére akadályozza a tisztességes és szabad piaci versenyt.

Japán, amely az Egyesült Államok után a világ második legerősebb gazdasága, egy napokban megrendezett ázsiai konferencián javaslatot tett Kínának és Dél-Koreának egy szabad forrású Windows alternatíva közös kifejlesztésére. Az új megoldás, amely valamelyik szabadforrású operációs rendszerre, valószínűleg a Linuxra épülne, elsősorban a támogató országok Microsofttól való függőségét lenne hivatott csökkenteni. Az új operációs rendszer a projekt támogatói szerint emellett megoldást jelentene a Microsoft szoftverekkel kapcsolatos biztonsági problémákra, és szabadon másolható lenne.

"Mi úgy gondoljuk, a piacra kellene hagyni annak eldöntését, hogy kik legyenek a szoftverpiac vezetői" - mondta Tom Robertson, a Microsoft ázsiai részlegének kormánykapcsolatokkal foglalkozó igazgatója. A szoftveróriás szerint nem a kormányoknak kellene eldönteni, hogy melyik szoftver a legjobb. "Nem a kormányok hatásköre annak eldöntése, hogy kik legyenek a győztesek" - mondta Robertson, aki szerint a Microsoft közvetlen és nyílt kommunikációt folytat a japán kormánnyal a szoftverek biztonsága, és a szoftveres szabványok terén.


Az IT piac japán képviselői szerint a Microsoft túl nagy befolyással rendelkezik a PC piac fölött, és a társaságok ezért egy ideje alternatív szoftvereket keresnek. A japán lapok jelentése szerint az ország kormánya most 86 millió dollárnak megfelelő jennel támogatna egy olyan ipari szövetséget, amely egy ütőképes Windows rivális szabadforrású operációs rendszert fejlesztene ki. A projektben a kínai és dél-koreai kormány mellett számos ázsia IT cég is részt venne.

Takeo Hiranuma, Japán kereskedelmi minisztere a napokban megrendezett ASEAN konferencián emellett a Microsoft szoftvereket érintő biztonsági problémákat is megemlítette azon okok között, amelyek miatt a miniszter szerint szükség lenne egy alternatív megoldásra.

Robertson szerint a számítógépes rendszerek biztonsága egy, a kormányokat és a felhasználókat egyaránt érintő, egész iparra kiterjedő probléma. "Nem vezet sehova, ha egy adott szoftverfejlesztőre mutogatnak" - mondta a vezető, aki szerint a Microsoft igyekezett Japánt is bevonni abba a programba, amelynek keretében kormányszakértők hozzáférhetnek a Windows operációs rendszer forráskódjához, beszélhetnek a fejlesztőkkel, és felvilágosítást kérhetnek az alkalmazott megoldásokkal kapcsolatban. Az ázsiai országok közül Tajvan és Kína már korábban belépett a programba.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Lola. #145
    "Tudod, mindennek megvan a neve, az ms szerint is buffer overflow"

    Idézet a microsoft security bulletinjéről, a két héttel ezelőtti rpc bug:
    MS03-026: Buffer Overrun in RPC May Allow Code Execution
    Gyk: http://support.microsoft.com/default.aspx?scid=kb;en-us;823980

    Nahát... :)
    ennyit akkor a butaságokról.

    " amirol en beszelek, annak pedig boseges irodalma van"

    Hogy a forrás nem segiti a debugot/törést? :)))
    Mert sajnos te csak azt szajkózod minden hozzászólásodban, aminek senki nem állitotta az ellenkezőjét mégpedig, hogy forrás nélkül is fel lehet törni egy szoftvert...
    Én meg arról beszélek, hogy forrással mégkönnyebb. De én már leirtam mindent erről, ha gondolod ird még le párszor, hogy nem kell forrás a töréshez én nem fektetek ebbe több energiát, bizzál csak benne, hogy nem segit senkit a programod megtörésében, ha nyilvános a forrása :)
    Részemről lezártam a vitát.
  • Lola. #143
    " miota felvilagositottalak, hogy az nem is overrun vagy mi :)"

    Google szerint ez a nemlétező "buffer overrun vagy mi" potom 113.000 oldalon szerepel, de biztos te jobban tudod. :))
    Úgyhogy az, hogy rádhagytam, hogy nevezd úgy ahogy megérted az lehet, hogy mást jelent. Egyébként sem kell mindjárt személyeskedni, ha valaki kijavit egy butaságodat, mert az ilyesmi nem vall kulturált emberre.

    "A lenyeg, hogy a buffer tulirasaval meg tudod valtoztatni a visszateresi hivas visszateresi cimet."

    Az nem mindig sikerül... Mert pl tudni kéne meddig tart az adott eljrás, amit éppen a forrás mond meg. Vagy mert egyáltalán nincs szükséged a visszatéritési cimre egyszerűen csak támadó kóddal irod felül a változó utáni kódrészletet, amennyiben tudod mikor kerül oda a vezérlés. Jéé ezt meg a forrásból tudhatod csakis. (ill. mondjuk egy hónap alatt, ha nagyon nagy guru vagy, akkor csak az asm-ból...)

    A stackhez igen ritkán férsz hozzá egyébként...
    Mák kell hozzá, hogy olyan távolságan legyen a hibás változótól, hogy ne legyen összeomlás ami DoS-hoz vezet és nem a halálpontos hack (zárt forrás elleni támadások mondjuk 80%-a, szemben a halálpontos hack többségével nyilt forrás elleni támadások esetén. De te úgyis megmagyarázod, hogy ez csak azért van, mert a nyilt forrást törők nagyobb zsenik és véletlen sem azért mert nagyban segiti őket a forrás :))

    " nem kell hozza semmi, amit egy debugger nyujt, eleg egy sima disassembler. "

    Még mindig nem érted, de kezdek belefáradni...
    Senki egy szóval nem mondta, hogy ne lehetne megtörni egy szoftvert kizárólag disassemblerrel. Csupán arról van szó, hogy, ha kezedben a forrás akkor 10-ed annyi energia/erőforrás/idő szükséges.
  • Lola. #140
    "Ha asm ablakot nezegetek, akkor folosleges veszodni a debugos forditassal."

    No ezek szerint nem láttál még asm ablakot debuggerben... Csak akkor minek vitázunk?
    Egy rakás információ belekerül a forrásból a disassemblerbe, pl az összes eljárás neve paraméterei, hol kezdődik hol végződik stb-stb...

    " En a sima forditas vs. vegleges optimalizalt forditasrol beszeltem. Eleg, ha az exploit azon az egy verzion fut, ami kozkezen forog. Viszont ha belathato idon belul meg ki akarod hasznalni a hibat, akkor ezen a verzion kell dolgoznod. "

    No ez teljesen értelmetlen... Az, hogy én a debug (optimalizálás nélküli) verzión irom meg az exploitot az kb mindössze csak napokkal hetekkel röviditi le a szükséges időt (és jópár kihullott hajszálat) mivel a forrás sokat segit. (bár ezt te még nem láttad sajnos...)

    "Viszont ha belathato idon belul meg ki akarod hasznalni a hibat, akkor ezen a verzion kell dolgoznod."

    Mint emlitettem - talán csak 10-20x... - ezt a verziót nagyon könnyen tudod forrással debugolni, ugyanis a siteok általában odairják milyen paraméterekkel forditották a binárisokat, amit a világ 95%-a használ. Gyk: ezeket a paramétereket aztán beadod a debuggernek és máris lehet forrás alapján törni a végleges binárist ami "mindenhol" fut. Ennyi...
  • Lola. #138
    Pont erről beszélek, hogy simán megkapod ezt a binárist c debuggerben aztán nézheted te az asm ablakot, lényeg, hogy alatta ott a c forrás amit (ezek szeirnt) elképzelni sem tudsz, hogy mennyire egyszerűsiti a hacket...

    "Az optimalizalt kodnal meg az iteraciok is maskeppen nezhetnek ki"

    néz_het_nek ki... pont erről beszéltem lejjebb. nem mindig, de gyakori, hogy változtatás nélkül elfut a támadórutin többféle optimalizált változaton...
  • Lola. #136
    a siteokon 99%-ban ott van, hogy hogyan is lett leforditva a bináris, igy simán le tudod debug módban forditani és máris megkaptad debug módban (forrás szinten) azt a binárist amit a világ 99%-a használ... Ha pedig azt az 1%-ot akarod törni aki magának újraforditotta a forrást, hát az sem túl megerőltető feladat, hogy kipróbálgasd hogyan is forditotta újra... (ebbe ne menjünk bele, de egy optimalizált forditás korántsem jelenti változók helyzetének és méretének felborulását, igy jó eséllyel minden további nélkül meg tudod törni bitazonos támadó rutinnal az egyedileg forditott alkalmazásokat egy normál compile-os debug verzió láttán...)

    Plusz leirnám ezerkettedszerre is, még akkor is nagyságrendekkel könnyebb nyilt forrást törni, ha valami speciális ok miatt disassemblingre kerülne a sor, mert pontosan tudod, hogy hogyan is épül fel a program és csak ez a lényeg...
  • Cat #133
    izgi téma
  • Lola. #132
    "Masreszt a CS sem egy betu szoval nem vagyok egybetus :)"

    Idézném magamat:

    "Az én nevem 5 betűs. A tied 2. Igy talán 3-al rövidebb. :))"

    ???

    "Van egy binarisod, es van hozza forras. A binarisban ki kell hasznalni egy buffer overflow-t (errol volt ugye szo). Miert nem kell disassembling? Es miert nem egyszerubb ranezni a memoriateruletre? "

    Pl. azon nagyon egyszerű oknál fogva, hogy zárt forrás esetén nem tudod melyik változó a hibás igy azt sem tudod hol helyezkedik el a memóriaterületen. Nyilt forrásnál kezedben a forrás, leforditod debug módban és szépen megkeresed, hol is van a gond, mi van előtte, mögötte, szépen traceled mikor kerül oda a végrehajtás (fyi: alatta ott fut a c forrás a debuggerben, mindent látsz, hogy mi történik mikor és miért, ez a legfontosabb egy halálpontos hack-nél, ellentétben a DoS támadásnál!!!)
    Ennél több azt hiszem nem kell... Ha még mindig nem világos miért könnyebb nyilt forrást törni, akkor én passzolnék...
  • Lola. #130
    " (ha a forraskodbol nem latszik, (marpedig nem latszik)"

    No pont ez utóbbival van baj... Nem a forráskódból látszik, hanem elmész az adott terémék oldalára (pl. sourceforge) és lehúzod a beforditott binárist, és a siteok 95%-án ezt a binárist futtatják, nagyon ritka az egyedi újraforditás... (megjegyzem ugyanitt általában azt is irják milyen paraméterezéssel készültek a binárisok. De, ha neked éppen nincs szerencséd, és kézzel forditott változtatot kaptál meg, akkor is egyrészt nem olyan vészes számú forditási változat van, másrészt - mint emlitettem - még mindig ott a disassembling, amely disassembling össze sem hasonlitható egy teljesen ismeretlen zárt forrású program disassemblingjével... (gy: ezerszer könnyebb még mindig törni, mert kezedben a forrás...)

    "Ize, a © tudtommal nem a nick resze, a '.' pedig nem betu, max. karakter. En is regisztraltam, es onnan tudom, hogy hozzaappendeli a ©-t. "

    Bár csak viccnek szántam a problémát, de úgylátom még mindig nem stimmel valami...
    @Lola. Ez 6 betű... A kukac tényleg nem kell hozzá, mert azt nem én kértem, ellenben a ponttal. (igy kell bejelentkezzek)
    Tehát az én login nevem bizony 5 betűs. Te azt mondod regisztráltál, ellenben megint nem úgy irtál, igy nincs is @ a neved előtt, marad a két betű 5-2=... folytassam? :)
  • Lola. #128
    Igen, 70 hozzászólással ezelőtt, még regisztrálatlan voltam... :)
    csak aztán jött valami nicklopó kretén igy regisztráltam magam.
    Az én nevem 5 betűs. A tied 2. Igy talán 3-al rövidebb. :))

    "Masfelol en a buffer overflowrol irtam es a nyilt vs. zart forraskod kerdeset nem erintettem."

    Sajnos, akaratotodon (figyelességeden) kivül érintetted, ugyanis én R-el a nyilt és zárt forráskód biztonsági összefüggéseiről beszéltem, aminek példájára hoztam fel a buffer overrun-t, amivel te nem értettél egyet. (máig tisztázatlan okokból, de ez most mind1, jogod van nem egyetérteni vele...)

    Innentől a hozzászólásod többi része értelmezhetetlen, mivel tetszik vagy sem a beszélgetés amibe belekapcsolódtál a nyilt és zárt forráskódról szól(t)...
  • Lola. #126
    Ha visszaolvasnád melyik hozzászólomba próbáltál belekötni látnád, hogy nem is neked irtem, és nem is magammal beszélgetek... R-nek irtam, bár lehet, hogy az is te vagy, olyan sok itt a regisztrálatlan egy betűs "hozzászóló"... :)
    Én pedig a nyilt és a zárt forrás biztonságosságáról irtam a buffer overrun-ról konkrétan (hogy érthetőbb legyen) aztán fogalmaztam meg ezt általánosan is mindenféle hibára...
    Abban megegyeztünk, hogy nyilt forrás esetén is, speciális esetben szükség lehet disassemblingre, de ez egyrészt ritka, másrészt még akkor is nagyságrendekkel könnyebb törni mint zárt forrást...