Újabb sebezhetőség részleteit tette elérhetővé a Google a 90 napos türelmi idő leteltével

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

A Microsoft rosszallása ellenére a Google nem akadályozta meg, hogy a hibakövető rendszere a beállított 90 napos türelmi idő letelte után újabb javítatlan sebezhetőség részleteit tegye publikussá. A hiba leírását a Google hibakövetője vasárnap hozta nyilvánosságra.

Tavaly november közepén a Microsoft jelezte, hogy a hibát 2015. februárjában tervezi javítani. Ez a 90 napos határidőn kívülre esett volna. A Google közölte, hogy a 90 nap fix, minden gyártóra és bugtípusra érvényes, így az nem hosszabbítható meg. Egyben azt is közölte a Microsofttal, hogy a 90 napos határidő 2015. január 11-én lejár.

Decemberben a Microsoft megerősítette, hogy 2015. januárjában tervezi javítani a hibát.

Ahogy a Google korábban jelezte, 2015. január 11-én a határidő lejárt, a hiba részletei automatikusan publikálásra kerültek.

A Microsoft 2015. január 13-án javította a hibát.

A hibajegy ma "fixed" státuszba került "Fixed-2015-Jan-13" címkével a Google-nél.

( uid_17784 | 2015. 01. 14., sze – 23:13 )

Ki a faszomnak kepzeli magat a Google?

90 napos kocsog.

Az azonnali publikálás nyilván destruktív, de a halogatás is. Az utóbbi csak a kiváltságosok számára teszi átjáróvá a rendszert, s hamis biztonságérzetet ad. Én egyébként a szavazáson a 90 napos konstrukciót jelöltem meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Rendben, de akkor az user ne panaszkodjon, hogy nincs idore kesz a cucc.

Masreszt meg, mi a normalis? Hogyan mered objektíven? Ki fogja meghatározni ezeket a mindenkire kötelező standardokat? Ki fogja szankcionálni azokat, akik nem követik?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Rendben, de akkor az user ne panaszkodjon, hogy nincs idore kesz a cucc."

Szerintem ha nincs időre kész a cucc az nem a user hibája, hanem a project vezetőé elsősorban, mert úgy kellene működni a dolognak, hogy a user elmondja mit akar, erre közösen kitalálnak egy timelinet, mindenféle megállapított időkkel, tesztekkel, stb stb, aztán mindenki boldog a végén.
Jellemzően ez a valóságban marhára nem így működik, ezért megy a kókányolás, "jó lesz ez majd úgy neki" típusú fejlesztés, és hülyének nézések, és hogy a user fizesse meg a fejlesztő elbaszásait drága pénzekért.

"Masreszt meg, mi a normalis? Hogyan mered objektíven? Ki fogja meghatározni ezeket a mindenkire kötelező standardokat? Ki fogja szankcionálni azokat, akik nem követik?"

Nyilván ezt marha nehéz ügy meghatározni, és nem is mi fogjuk most :), de pl. ha az MS elbaszarint valamit, akkor igenis álljon neki és javítsa ki ASAP, és ne a száját húzogassa mert 3 hónap alatt sem tudták megcsinálni.
Ha meg akkora ordas hibát vétettek amit 90 000-en nem tudnak kijavítani 3 hónap alatt, akkor inkább váltsanak profilt és menjenek pizzát gyártani :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

"Ha meg akkora ordas hibát "vétettek amit 90 000-en nem tudnak kijavítani 3 hónap alatt, akkor inkább váltsanak profilt és menjenek pizzát gyártani"

Lehet, hogy nem kéne bukott mobiltelefontól, használhatatlan kódhostingtól a bukott keresőig mindennel foglalkozni (csak azért, mert más is előállt ilyennel és azt más jobban csinálja), csak azzal, ami a fő profilja volt.

--
trey @ gépház

Aham, szóval te mint szoftverfejlesztésben járatos szakértő megmondod, hogy... hopp, várjunk csak...

Attól függetlenül, hogy milyen a codeplex (nem használtam sosem), annak, hogy átálltak a Githubra nem technikai, hanem üzleti okai vannak, ezt te is tudod pontosan jól.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szólj majd, ha találtál valakit aki használja (aka. szavaztassuk meg?)

"Kinőttem már abból a korból, hogy elhiggyem a review-jellegű cikkeket a netről. :)"

Nem review jellegű cikk a netről, hanem az egyik F# fejlesztő véleménye, aminek nyomán az történt, hogy elköltöztek a CodePlex-ről a GitHub-ra. Egy Microsoft eredetű projekt elment a Microsoft kódhosting platformjáról egy másik szolgáltatásra.

Mi ez, ha nem kritika?

--
trey @ gépház

Szó se róla, nagyon jó lennének ilyenek, de ahhoz nagyon gyökeres változások kellenének a szakman belül. Persze, idővel muszaj lesz ezeket meglepni, addig maradnak a vallalatokon belüli szabványok meg a regexppel xml olvasók.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mennyire igaz! Az én ükapám is hibátlan alap- és felhasználói szoftvereket írt, amelyek adott esetben világhálón keresztül elosztottan több tucat másik rendszerrel működtek együtt, több platformon, több eszközről, ezrek-tízezrek-százezrek-milliók által használva.
Sajnos sírba vitte, hogy hogy csinálta, de gondolkodom vallásalapításon - mert hívő az lenne, ahogy látom.

Ki mondta, hogy a bejelentés után nem javítom?

Arról van szó, hogy a bejelentő ne basszon már ki az userekkel, hogy világgá kürtöli 0. percben. (Az, hogy velem kibasz, az mellékes, mert nekem ugyanannyi a munkám vele.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Miért is? Gondolom pont ugyanezt megteheti a Mikrofost is - lehessen náluk bejelenteni a gugli-szolgáltatásokban rejlő hibákat, és ő meg publikálja őket akkor, amikor neki jól esik. Mégis mennyi időt kéne ücsörögnie egy akárhogyan a tudomására jutó bug fölött?

Megteheti. Megmondom mi lesz a vége: a cégek egymás lejáratása miatt elcsatázgatnak egymással, a felhasználók meg szopnak minden oldalon a nagyok acsarkodása miatt.

Túl naív az, aki azt hiszi, hogy ez az egész az userek miatt van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem. Az egész iparágat a jobb minőségű software-ek előállításának irányába tolja. Ettől persze még nem lehet hibátlan programot írni ezen túl sem, csak annyi változik, hogy a hibákat ki kell javítani. Egy autógyár mikor teheti meg, hogy elszúr valamit, emiatt emberek halnak meg, de lesz.rja, s nem foglalkozik vele? Visszahívja a járgányokat, kijavítja a hibát saját költségén, aztán sűrűn elnézést kér. Az az arcátlanság, ami a végfelhasználói licenszszerződéseket illeti, csak a szoftveripar sajátja. Használhatod, de nem a tied, bérled, ezért fizetsz, de a gyártó semmilyen felelősséget nem vállal a szoftver hibáiból eredő károkért. Hogy mivan-mivan?

Ez inkább a titkosszolgálatoknak szívás, mert nem lesz egy-egy hiba elaltatva, s évekig bejáratként használva, hanem unos-untalan vadászni kell az újabb és újabb bugokra, s remélni, azt más nem találja meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Az az arcátlanság, ami a végfelhasználói licenszszerződéseket illeti, csak a szoftveripar sajátja."

Most arról beszélsz, hogy a Google esetén még csak a szoftver se kerül a kezedbe, hanem csak és kizárólag egy szolgáltatást használsz tőlük az esetek igen jelentős részében?

"Az egész iparágat a jobb minőségű software-ek előállításának irányába tolja."

Persze....

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezzel most mi a baj? Hogy az MS nem tud visszatámadni? Ha egy fodrász fedezi fel a hibát, jelzi a gyártónak, s 90 nap múlva publikálja azt, akkor szerinted csak úgy igazságos, ha cserébe az MS kicsorbíthatja a fodrász ollóját? Ez így szerintem elég ovodista hozzáállás.

Az Android elég sok helyen fut egyébként, szóval nyugodtan vadászhat bugot az MS, és ha talál, jelezze a G-nek, 90 nap elteltével meg tegye publikussá.

A persze alatt mit értesz? Hogy nem? Ja, ha sz.nak bele, akkor elpártolnak a tudatos felhasználók. Aztán ők oltják a többieket, összejön a keitikus tömeg... Vagy a szoftverpiacon a minőség nem verseny tényező?

Egyébként jól értem, hogy most azon megy a sírás, hogy nem lehet programokban otthagyni a bugokat évekig?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most arról beszélsz, hogy a Google esetén még csak a szoftver se kerül a kezedbe, hanem csak és kizárólag egy szolgáltatást használsz tőlük az esetek igen jelentős részében?

Es ha kiteszik a szurodet, akkor mindenfele indoklas nelkul (megsertetted az altalanos szerzodesi felteteleket), aztan talald ki, hogy mi volt a bajuk veled.

Nincs egy support email cim, ahova lehetne irni, hoyg megis mi nem tetszett nekik.
Termeszetesen ez egy fizetos szolgaltatas amirol beszelek.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Természetesen a userek miatt van - értsd a felhasználók "innen-oda" állítása érdekében. Pl. elképzelhető, hogy ha valaki mást se hall, mint hogy a Google már megint mennyi hibát talált az MS rendszerében (fordítva meg nem), akkor a legközelebbi kütyü beszerzésekor nem wines laptopot, hanem mondjuk Chromebookot választ. Nagyon sok egyszerű felhasználó van, aki nem játszik, nem kell komoly prezentációkat csinálni, stb, ezért aztán az a rendszer is kielégítheti az igényeit.
Azaz ez is bőven belefér a reklám kategóriába - hasonlóan a "hagyományos mosópor"-hoz.
Hosszú távon pedig az is bőven elég az én boldogságomhoz, ha javul a fejlesztéskori tesztelési metódusa X Y és Z cégeknek, és igenis nehezebben előidézhető, nehezebben kihasználható hibák maradnak a kódokban és jobban átgondolt protokolokat fejlesztenek.

Megy a vilag a weboldal-alkalmazasok fele. Egy ilyen vilagban az MS nem lesz monopol helyzetben...

Ennek a folyomanya az, hoyg nem fajlaid lesznek, amit a neked megfelelo alkalmazassal tudsz megnyitni (millio+1 kepnezegeto pl.), hanem webes alkalmazasaid lesznek, amibol valahogy ki lehet exportalni az adataidat, es kenheted a hajadra. (vagy irsz hozza egy alkalmazast)

Ez a vilag a google-nak nagyon kedvez, es nyomatja ezerrel (android, chrome, chromebook).

A ceges vilag nehezebben reagal, vagy kifejezetten probal ellenallni. Itt az ms meg eleg nagy szereplo. A legegyszerubb itt alaasni az ms-nek, ilyen hibapublikalassal.

Szerintem ez az igazi motivacio.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Túl naív az, aki azt hiszi, hogy ez az egész az userek miatt van."

Márpedig a felhasználóknak jó az, hogy kiderülnek a sebezhetőségek és a workaround.

Ha szólt, aztán titokban tartja az, aki észrevette a biztonsági hibát, a szoftver gyártója pedig ül a javításon, mert neki az a kényelmes, a felhasználók pedig semmit nem tudnak a dologról, az rossz. Mert attól, hogy nincs nyilvánosságra hozva, attól a hiba létezik és ha egyvalaki megtalálta, akkor megtalálhatta más is.

A felhasználók nem egyformák. Teljesen biztos, hogy van olyan felhasználó, akiknél az adott szolgáltatás vagy rendszer lekapcsolása kisebb veszteség, mint a hibával való üzemelés kockázata.

_Ha tudják_, hogy létezik biztonsági rés, akkor ezt a döntést meg tudják hozni, mérlegelve, hogy mekkora kockázat a hibás rendszer üzemeltetése és mekkora bevételkiesést okoz a workaround.

_Ha nem tudják_, hogy létezik a biztonsági rés, akkor ezt a döntést helyettük hozod meg.

Szerintem, ha te felfedezel biztonsági rést, publikálhatod. Vagy a bug is szabadalmi védelem alatt áll az MS-nél? :D

Az egésznek épp az a lényege, hogy ne tátongjon ott a lyuk évekig, kiszolgáltatva egyeseknek a felhasználókat. Két lehetőség van. Vagy kijavítják, s mindenki boldog, vagy nem, s a felhasználó dönthet: használja azt a fércművet, amiért még fizetett is, s ami által bárki szabadon mászkálhat a gépén, vagy elpártol az igénytelen munkát végző cégtől, s olyan terméket használ, amelynek a gyártója komolyan veszi ügyfelei biztonságát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"s ami által bárki szabadon mászkálhat a gépén"

Hja, csak mikor fognak többen mászkálni: ha egy szűk kör ismeri (jobb esetben megtaláló+fejlesztő..rossz esetben mindenki) vagy ha mindenki? (Ilyenkor a legjobb eset is onnan indul, hogy a hiba és a kihasználásának módja biztosan elérhető azoknak, akik ki akarják használni.)

Persze, nyilván önmagában nem véd meg az, hogy nem kürtöljük világgá, de egy fokkal nagyobb védelmet adhat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Erre van a 90 napos védelmi idő. Ennyi idő szerintem elegendő a hibák javítására. Ha nem, ott nagy baj van. Ennek kétszerese idő alatt egy új Fedora release jelenik meg alkalmazásokkal, systemd ámokfutással, miegymással. És igen, ha a javítatlan bug és a gyártó hanyagsága miatt bedől néhány millió felhasználó rendszere, ez talán elég nagy pofon a gyártónak ahhoz, hogy újragondolja minőségpolitikáját, a felhasználónak meg ahhoz, hogy elgondolkodjék, honnan szerzi be a software-eit.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Ennyi idő szerintem elegendő a hibák javítására. Ha nem, ott nagy baj van."

Erre hoztam egy példát egy másik threadban, hogy mit csinálsz akkor, ha pl. protokolt kell módolsítani, amihez többtíz-száz-ezer másik partnernek kell igazodnia és nem, pluszba egyeztetni velük, stb. és nem, állhat le a szolgáltatás.

Vagy mondok még egyszerűbb példát: autóriasztó rendszerben kiderül, hogy kijátszható. Lehet, hogy javítható 90 nap alatt, de hogyan flasheled fel az összes eladott autó firmwareját?

El kellene már szakadni attól, hogy csak egy linux distro tákolása szintjén kezeljük ezeket a témákat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Protokollra szerintem workaround. Ne használják, ne azt, ne úgy, tenyésszenek postagalambot, 3 hónap alatt szerintem azok is felnőtt madarak lesznek. Hagyjuk már ezt a „kell” kifejezést. Tudod mi kell? Víz, levegő, kaja, megfelelő hőmérséklet. Úgy kb. Háborúban is azt mondod, hogy ne lőjenek, mert a szolgáltatásnak mennie kell? Érdekes módon, amikor nagyon szorít a cipő, hirtelen lesz megoldás. Y2K probléma ismerős? Jó, tudom, volt rá idő, de elég merev határidőnek tűnt, valahogy nem lehetett megfűzni az Égieket, hogy 2 hónappal később legyen 2000. (Nem az ezredforduló, mert az 2001-ben volt, csak valamiért egy évvel korábban ünnepeltek valamit. Biztos holmi névnap lehetett, nem tudom.)

Az autó érdekesebb probléma. Én akkor sem lopok autót, ha tudom, hogyan lehet, aki meg komolyan gondolja magát, az lehet, trélerrel megy érte.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Ne használják,"

Es ha mondjuk egy kereskedoceg azon rendszeret erinti, amelyen keresztul lehuzza az arlistakat es/vagy rendel, ami nelkul be is zarhatja a boltot?

"Én akkor sem lopok autót"

Na most ezzel a mentalitassal a secholeket se kellene javitani, mert "ugy se tornek be" :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Itt ket dolgot kell merlegeni: egyik, hogy kinek a kezebe juthatott el eddig az informacio, masik, hogy mennyire tudod elerni a vevot.

Ha aktivan kihasznaljak, akkor mar ugy is mindegy, be kell terelni a szervizbe minel elobb az embereket. Itt kerdes, hogy a vevoket mennyire tudod megszolitani, viszont nekik eleg egy figyelmeztetes. Ha nem ismert az, hogy publikusan kihasznaljak, akkor probalnam titokban tartani, ameddig lehet es a kotelezo szervizek soran patcheltetni az autot, amennyiben garantalhato, hogy onnan nem leakelodik tobb info, mint kellene. Ha elore bejelentem, hogy itt meg ott hiba van, azzal csak csaletket kinalok fel azoknak, akik nem ismertek meg eddig a hibat.

A reszleteket maximum akkor publikalnam, ha mar tudom, hogy a legtobb vevo vedett.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt ugy erted, hogy az MS-nek nem kellene szetbarmolnia a mar meglevo nyilt szabvanyokat es sajatokat gayrtani belole, hogy semmivel ne legyen kompatibilis, mert igy sok partnerrel kell targyalnia, mig ha kovetne a szabvanyokat talan nem lenne erre szuksege?

Mondok egy peldat en is. Feluti egy virusos betegseg a fejet, ami 100 napig tunetmentes, majd az osszes fertozott meghal. A virus levegoben, es testendvekkel is terjed, strapabiro kis szorny. Van egy vedooltas, amit ha ket hettel a fertozes utan beadnak nem hal meg a fertozott. Szerinted amikor felfedezi valaki a virust szoljon az embereknek hogy menjenek beoltani magukat????

Egyébként miért nem fordítod az előnyödre. Én úgy tudom a Gúgle nagyon bőkezűen fizet a bejelentett hibákért. Én kívánom tiszta szívemből, hogy legyél gazdag a Gúglénak bejelentett hibákból.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Néhány adalék.

A security a Microsoft mumusa. Sokáig hallani sem akartak róla. A Mozilla, a Google és mások security bounty programokat indítottak és jutalmazták (és jutalmazzák) a sebezhetőségeket bejelentőket. A Microsoft erről hallani sem akart sokáig. Majd amikor már ciki volt a hozzáállása, engedett.

De a beszámolók szerint továbbra sem szereti a bejelentőket.

A Google ellenben elég sokat tesz a biztonságért. Utána lehet nézni, hogy milyen programokat indított, emberei hány kritikus hibára hívták fel a figyelmet stb. (konteósok legnagyobb bánatára nem csak Microsoft hibákra)

--
trey @ gépház

>A security a Microsoft mumusa. Sokáig hallani sem akartak róla.

"masturbating monkeys" - Bill Gates
"security circus" - Steve Ballmer
"a bug is a bug" - Marci (a Microsoftnál dolgozok^Hm)

yup, all true

>A Google ellenben elég sokat tesz a biztonságért. Utána lehet nézni, hogy milyen programokat indított

valami PRISM jut eszembe mint a google legnagyobb biztonsági programja

Ez így igaz. Egyetlen cent licencdíjat sem szed be a Google a telefongyártóktól az Android után. Sőt ingyen adja a teljes rendszer legfrissebb változatát forráskóddal. A gyártók dolga ezzel foglalkozni.
A Microsoft viszont licencdíjat szed minden egyes Windows pc után. A gyártók még a kezdőképernyőn sem változtathatnak a Microsoft engedélye nélkül. A Windows biztonságáért a Microsoft a felelős.
A Nexusokban pedig valóban nincsenek tömegesen javítatlan sebezhetőségek.

"A gyártók még a kezdőképernyőn sem változtathatnak a Microsoft engedélye nélkül"

Hala az égnek, nincs annal idegesitobb, mikor a gyártó, de meg inkabb az operator teletolja mindenfele haszontalan szeméttel a készüléket, amit aztán nem frissít. Engem inkabb az zavar, hogy miert kell a gyartok es az operatorokra is ennyot varni la az MS-nek, hogy frissithessen. (Mondjuk, hogy a telefongyartas mar házon belul van, talan lesz valami fejlődés).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"

Egyszerű a megoldás, olyan gyártótól kell mobilt venni aki nem tolja tele a képernyőt "mindenféle haszontalan szeméttel"
Vehetsz Nexust is, azzal az Android fejlesztő Google kezdőképernyőjét kapod.
A Microsoft által erőszakolt, megváltoztathatatlan kezdőképernyő ugyanakkor nem aratott osztatlan sikert. A WP egy nagy bukás. A piaci kudarc pedig már a WP kezdőképernyőjénél kezdődött.

A végén sajnos én is fizetek, mert az MS sarc is a kiadás oldalon jelenik meg.

(Totálisan off: Két kedvenc MS szabadalom, amikért perkálni kell: "Loading Status in a Hypermedia Browser Having a Limited Available Display Area" (6339780) és "Searching and Browsing URLs and URL History" (7831547))

Kérlek sorold fel az Apple-n kívüli IOS-es telefon gyártókat, mert nekem most egy sem jut eszembe.

ps: a saját telefonján (Nexus) a Google is meg tudta oldani a frissítést, a Samsung vagy az LG telefonjain talán a Play Store-t licenszeli egyedül, minden máshoz a Samsungnak és az LG-nek van köze.

Igazad van, kár volt az apple-t idekevernem.
Amíg más gyártók nem csak a friss kiadásokat teszik könnyen elérhetővé, de a régi kiadásokba is visszaportolják a (biztonsági) frissítéseket. A goole ezt elegánsan megoldja annyival, hogy "just use supported kernel/phone". A vitaindító szál szempontjából mindegy: a google nem tesz semmit, hogy az android telefonok többsége frissüljön.

Az pedig nem állja meg a helyét, hogy ezt azért (nem) teszi, mert nincs hatalmában. Egyszerűen fontosabb nekik, hogy minden szaron az fusson (a google érdeke), minthogy megfelelő minőségű és hosszúságú támogatást biztosítsanak (a felhasználó érdeke). A zártabb, kötöttebb (wp, ios, bb) riválisoknak nem nagyon van ilyen problémájuk. A felelősség gyártókra való terelése a szabadság jegyében - pláne a PRISM akták után - számomra nevetséges.

A PRISM-et milyen logikai bukfenccel sikerült idekeverned?
Úgy, hogy ha az os fejlesztő által berakott beckdoort a mobil gyártója, sem külsős fejlesztőcsoport sem szedheti ki?!
Ha androidnál "hazafias alapon" arra kényszerű a Google, hogy backdoort rakjon az Androidba azt még kiszedheti a nem amerikai gyártó a más országokba irányuló mobiljainál, vagy kiszedheti egy olyan független csoport mint a CyanogenMod vagy http://omnirom.org/
Az iOS-ből honnan lehet letölteni ilyen alternatív rendszert mint androidnál a CM?

Valamelyik pihent agyú firkász fél éve kitalálta ezt a badarságot azóta rendszeresen visszhangozzák a lapok. Egyszerűbb copy-pastelni mint saját eredeti cikket írni.
Nézz meg egy kínai Android mobilt, Baidu-ra belőve, nulla Google szolgáltatással. Egyébként is Kína egy Google outside ország. Mit ad Isten működik! Teljesen kompatibilis az android appokkal. Döbbenetes!
Gmail app, Gmaps app, és Google szolgáltatásokra épülő alkalmazások nem mennek. Helyette vannak megfelelő Kínai szolgáltatásokra épülő appok.
Az Android továbbra is open source szoftver

Szájbarágósan: rossz a párhuzam.

Desktop oprendszer --> nincs szolgáltató, gyártó, stb. által befolyásolható OTA --> jó.
Mobil oprendszer --> van szolgáltató, gyártó, stb. befolyásolható OTA --> rossz.

Az azért eléggé edge case, hogy az oprendszer vendor megszűnik, vagy befejezi a termékvonal fejlesztését. A Vörös Hajnal manufaktúra _nem_tudja_befolyásolni_, hogy a fedup tudja-e frissíteni a rendszert. Ha tudja, akkor már nem nevezhető Fedorának a végeredmény, lásd redhat legal állásfoglalások.

Továbbá, ha a PC-ről legyalulom a Fedorát, és teszek rá Ubuntut, az nem veszélyezteti a garanciát. Telefonnál ha kukázom a Nexusról az Androidot és Firefox OS-t teszek rá, akkor bukik a gari. És még sorolhatnám a végtelenségig...

A vendor igenis felelős azért, hogy lehetővé tette a gyártóknak, hogy genyózzanak, és kikényszerítsék a régi verziók megtartását.

Ugye azt tudod, hogy az Android forrás különböző szabad licenszek alatt van (elsősorban GPL) a linux alapok miatt, így a Google ha akarná se tudná megtiltani hogy a gyártók azt csináljanak vele, amit csak akarnak - például hogy belerakják egy telefonba, amit soha többet nem frissítenek?

Mondok egy másik, a valóságtól nem ennyire elvonatkoztatott példát, hátha megérted. A freebsd-re egy csomó termék épül, amit nem tud a user csak úgy netről frissíteni, pl.:
- A Juniper switcheinek és routereinek az oprendszere
- A Sony PlayStation 3 és 4 oprendszere
- A Dell iSCSI SAN storage-a

Ha a FreeBSD javít egy security bugot egy újabb verzióban, de a Juniper / Dell / Sony nem frissít, akkor a FreeBSD teamnek, vagy a Sonynak / Junipernek / Dellnek a k. anyját?

Meg kellene érteni, hogy a Google azoknak a telefonoknak a frissítéséért felelős, amiket ő adott ki. És azokkal nincs is baj.

> így a Google ha akarná se tudná megtiltani

Azt valóban nem tudja megtiltani a Google, hogy az Android kódját felhasználja valaki, de azt simán, hogy a végterméket ne lehessen Androidnak hívni.

Ha már előjött a fedorás példa, nekik sikerült: https://fedoraproject.org/wiki/Legal:Trademark_guidelines

> Az mindenesetre a Google sara, hogy az ilyen tré szarokra is odaadja a Playt, meg a többi húzó-dolgát.

Pontosan. Jogi és technikai lehetősége is van ellenőrizni az Android felhasználását, csak nem pont úgy, ahogy itt a hupon elképzelik (t.i. "a nyílt forráskóddal mindenki azt csinál, amit akar")

"Ki a faszomnak kepzeli magat a Google?"
"90 napos kocsog."

Ki a faszomnak képzeli a Microsoft?
Hogy egy qrva bugot ne lehessen 90 nap alatt fixálni, az kissé röhejes.
Lehet példálózni autóiparral, meg csúnya gugli, meg különben is napszél van meg tököm tudja micsoda.

Nemhogy örülne neki a baromja, hogy valaki előzetesen informálja, (hogy bocsi pisti, luk van az ajtódon), nem, megy a nyekergés, hogy ezt eddig, meg addig tudják csak javítani.
Nálam nemcsak a fejlesztő, de a menedzsere is nagyívben repülne, ha csak megpróbálná megideologizálni, hogy miért is kell néhány órás fixre 90 nap (és nem néhány órás, hanem néhány napos, akkor is).

És ahogy előttem már jelezte valaki, ennyi idő alatt fedora release szokott készülni, halom szoftverrel, tonnányi bugfixálással.
Nem csak egy adott komponens piszkálgatása. Szóval ha a kommunikációs overhead-re csoportosított energia 10%-át ha fixálásra fókuszálná az MS, akkor lehet nem kéne ilyen marhaságról szót sem ejteni.

Azért kíváncsi lennék, hogy akkor is kardoskodna-e az MS a 90 napért, ha mondjuk a saját infrastrukturájába zúznának be a hole miatt?
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

??? Teljesen normalis hozzaallas a Google (vagy barki mas - lasd lentebb) reszerol szerintem. Mi a bajod vele, te 900 napot jelolnel meg? Vagy, hogy ne legyen mindenki egyenlo, es csak azert mert az MS, neki tobbet engedjenek mint masoknak? Vagy nem ertem. Es ez teljesen cegfuggetlenul irom, nem azert mert a Google, vagy mert az MS, ezen mar tul kene lepni ... Erdekes amugy, hogy csak meg egy honap lett volna kb, de ahogy megjelent, par nap mulva megis tudtak javitani. Szoval menne ez :) Valoszinuleg meg elobb is ment volna ...

"Erdekes amugy, hogy csak meg egy honap lett volna kb, de ahogy megjelent, par nap mulva megis tudtak javitani. Szoval menne ez :)"

Nyilván amikor megtudták, hogy a Google nem ad még egy hónapot, előrébb hozták a javítást, nem azalatt a pár nap alatt dobták össze...

Elképzelem hogy működhet ez a Microsoftnál: minden terméknek van egy vagy több csapata, ezek a csapatok viszont relatív kicsik, nyilván feladatfüggő hogy pontosan mennyire. Ebből következően ezekben a csapatokban nincsenek security expertek, ők egy vagy több külön csapatot alkotnak a cégen belül. Feladatkörük többek között a termékek tesztelése biztonsági szempontból, biztonsági hibák javításainak validálása, új biztonsági megoldások fejlesztése (legalábbis azok tervezése), bejelentett biztonsági hibák kivizsgálása (valid-e a bejelentés, mekkora a scopeja), stb. A Microsoftnak van egy rakás szoftvere, jó biztonsági szakemberből meg kevés van, tehát ez(ek) a csapat(ok) baromira túlterhelt(ek), több hónapra elég feladatuk van. Ezért egy ilyen csapat esetén nehéz megállapítani, hogy minek mekkora prioritást kell élveznie, mert sok a szempont, ezért szerintem teljesen normális, ha egy biztonsági hibával foglalkozás adott esetben kisebb prioritású, attól függően hogy kihasználják-e már azt, mennyire korlátozott, stb.
A másik probléma, hogy miután javították a hibát, le kell ellenőrizni, hogy nem tör-e el semmit. Figyelembe véve, hogy a Microsoft hány éves támogatást ad a szoftvereire, illetve azt, hogy egyes komponensekre hány szoftver épül, amiket összesen hány felhasználó használ, ez rengeteg (remélhetőleg automatikus) tesztelést jelent. Szinte biztos vagyok benne, hogy a legtöbb biztonsági javítás első verziója eltör pár tesztet, ezeket megint csak ki kell vizsgálni, módosítani a javítást és újra tesztelni.

"Ja, lehet, hogy nem terelni kéne házon belül a problémákat, hanem valakinek megoldani...."

Jobb helyeken azért vannak munkakörök, hogy mindenki a dolgával foglalkozzon. A QA megkeresi a hibát, felveszi a hibajegyet, a fejlesztő meg kijavítja. Ha ez neked terelés, az elég szomorú.

"Jobb helyeken"

Látjuk hatékonyságát ennek a hozzáállásnak. Ne nevezzük jobb helyeknek ezt. "Ez nem az én dolgom" felkiáltással beleszarni valamibe a legkönnyebb. Hogy házon belül a QA, a portásnéni, a vezérigazgató vagy a programozó oldja meg, az tök mindegy. Első az ügyfél. Kifelé ennek nem kéne látszódnia. Megoldás kell, nem mellébeszélés és mutogatás.

--
trey @ gépház

Látok embereket szoftverfejlesztéssel foglalkozni. Azt is, hogyan hárítják le magukról a feladatokat. Azt pedig számos szoftverfejlesztőtől elhangzott, hogy a fejlesztők nem szeretnek hibát javítani. Nézzél szét a levlistákon.

Ha pedig nem szeretnéd folytatni, nem kell szar kifogásokat keresni. Elég ha nem válaszolsz.

--
trey @ gépház

"Látok embereket szoftverfejlesztéssel foglalkozni."

Kb 9 éve dolgozok szoftverfejlesztőként.

"Azt is, hogyan hárítják le magukról a feladatokat."

Rossz emberekkel ismerkedsz.

"Azt pedig számos szoftverfejlesztőtől elhangzott, hogy a fejlesztők nem szeretnek hibát javítani. Nézzél szét a levlistákon."

Ha 10 ember azt mondja, akkor az úgy is van? Van aki szeret javítani, van aki nem. Embertől is függ, hibától is, kódbázistól is. Ez személyes tapasztalat, nem csak olvasgatok róla. Egyébként a miheztartás végett eddig a hiba *keresésről* volt szó, nem a javításról. Nem összekeverendő a kettő.

"Ha pedig nem szeretnéd folytatni, nem kell szar kifogásokat keresni. Elég ha nem válaszolsz."

Nehéz szó nélkül hagyni a ferdítésekkel és féligazságokkal teli hozzászólásokat, ha már egyszer beleszóltam a szálba...

Ha egy 3 emberes szoftverfejlesztő vállalatról vagy csoportról van szó, akkor valószínűleg mindenki csinál mindent. Jó esetben tervez, programozik, tesztel, hibát javít, dokumentációt ír, telepítőt ír, tartja a célközönséggel a kapcsolatot, stb. Ilyenkor tényleg a fejlesztő dolga a hibakeresés ha tetszik, ha nem.

Ha egy nagyobb szervezetről van szó, akkor általában vannak dedikált tesztelők. Ilyenkor a tesztelést és hibakeresést a tesztelő csinálja, majd az felveszi a hibajegyet és a fejlesztő elvégzi a javítást. Természetesen van fejlesztői teszt, de amíg azon nem megy át a kód, addig a programozó ki sem adja a kezéből amit csinált: ennek célja az éppen módosított funkció kipróbálása, nem az átfogó/mindenre kiterjedő teszt. Dedikált feladata van mindenkinek, így sokkal hatékonyabb. Ha tanultál történelmet, akkor ismerős lehet ez az iparosodás korából, amikor a céheket (1 ember minden feladatot elvégzett a termék gyártása során), felváltotta a manufaktúra (1 ember csak 1 lépést csinált a gyártásnál, így abban gyakorlott lett és a teljes gyártási folyamat felgyorsult).

Attól hogy egy fejlesztő nem szeret hibát javítani, attól még megcsinálja, hiszen az a dolga. Viszont a hibakeresés nem az ő dolga, nem egymásra mutogatás ha ezt a tesztelőnek kell elvégeznie. Csőtörés esetén se az álljon neki szerelni aki épp ráér vagy helyben van, hanem hívni kell egy vízvezetékszerelőt, mert az meg az ő dolga. Autós példát nem tudok.

"A több millió soros zárt forrásban? Hogy a fenébe férnek hozzá?"

Forrásban? Forrás nélkül!

Fuzz testing
Making Software Dumber - Tavis Ormandy
Google Online Security Blog: Fuzzing at scale
fuzzing.info
papers
Adobe admits Google fuzzing report led to 80 'code changes' in Flash Player
Announcing cross_fuzz, a potential 0-day in circulation, and more

A végtelenségig sorolhatnám.
--
trey @ gépház

Kérdés, hogy honnan? Ha körbenézel a hupon, az elég jó képet ad arról, hogy jó IT biztonsági szakember* baromi kevés van.

* értsd ez alatt: én is dolgoztam már IT security témában, de imho még ez sem elég, hogy azt lehessen mondani, szakértő vagyok a témában. És akkor ugye vedd hozzá, hogy az informatikusok kellemetlenül nagy részének (nem csak itt) köze sincs az IT biztonsághoz, sem munkahelyeket, sem szaktudást tekintve.

Tényleg ennyire nincsen, ha jó szakembert keresel. Az IT security valamiért elég túlmisztifikált, amennyire tudom, Magyarországon pl. nincs is a felsőoktatásban olyan képzés/szakirány, ami legalább minimálisan felkészítene egy ilyen munkakörre.

szerk: illetve ott van az is, hogy mivel ebben az iparban jóval kisebb a lehetőség a gányolásra és maszatolásra, így magasabb a belépés költsége

De láthatóan egyre nagyobb az igény rá, egyre több ilyen incidensről érkezik infó. Ettől nem fog jobban beindulni, nem kéne jobban beindulnia az ilyen irányú képzésnek? Persze akik most ott tanulnak, azok jó pár év múlva tudnak munkába állni, de legalább elindulna valami.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( uid_17784 | 2015. 01. 15., cs – 11:03 )

Itt is (itt a hupon) lemerheto, hogy miert nyerne a Google a magyarorszagi valasztasokon (ha indulna a baromja).

( atomjani | 2015. 01. 15., cs – 12:17 )

Én még mindig nem értem, hogy konkrétan minek a hibájáról van szó és mi a hiba. Mindenről van írva, csak erről nincs. Pedig szakmailag ebből többet lehetne tanulni.

( uid_16313 | 2015. 01. 15., cs – 15:20 )

Ha valaki hibás terméket gyárt, akkor vállalja fel a tetteinek a következményeit. Törvénnyel kellene szabályozni. Ès nem olyan licenszfeltételeket elfogadtatni automatikusan szerencsétlen ügyféllel, hogy teljesen természetes pl. az adatvesztés és mindennek az ügyfél az oka.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

deleted, félre ment...
na közben ha még "szabad", akkor szerkesztem.
---
Én csak azt nem értem, hogy jött ide a lovaskocsi... :) (ha van még ilyen gyár, szerintem ők sem dobhatnak a piacra akármit, mert forgalomba szánják..)

De mint mások is írták: az emberélet egyelőre még komolyabb értéket képvisel, mint a word doksiban elmentett szeretőlista :), egy hibás autó sokkal nagyobb valószínűséggel olt ki emberéletet, mint egy 0 day sebezhetőség. Megkockáztatom, hogy ez igaz a lovaskocsira is :D

Ne kattints ide!

Szerintem igen :)

De ne vegyük egy kalap alá a klasszikus programhibákat (pld. hibásan megvalósított funkció) és a biztonsági réseket, főleg hogy az első csoportot azért tesztelik rendesen. Ráadásul egy autógyártó/hídépítő manufaktura - ha van csöppnyi esze a vezetésnek - élesbe töltés előtt teszteli a szükséges funkciókat.
A biztonsági rések ráadásul általában nem a rendes használat vagy működés során derülnek ki, kihasználásuk sem tök egyértelmű, hanem sok esetben a "csillagok állása" is közrejátszik :).

Ne kattints ide!

Csillagok állása a funkcionális hibáknál is. Ugyan hardware, de emlékszel az Intel CPU-k osztás hibájára? Nem volt az olyan nagy hiba, de bizonyos esetben és halmozódva - teszem azt, lineáris algebra, mátrixegyenletek, s a műszaki problémák gyakran épp ilyenek - csúnya vége lehet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az Inteles gond kimaradt az életemből - vagy lehet, hogy benne volt, de már kikopott :) . Utolsó konkrétnak mondható ilyen tapasztalatom még C64 BASIC-ben volt, ahol sqr(625)^2=624.999999 volt vagy ilyesmi.

De szerintem ezzel el is jutottunk oda, hogy miért nem vállalnak (illetve mernek vállalni) a fejlesztők a program használatából adódó adatvesztés és egyéb károk esetén felelősséget :)

Ne kattints ide!

Nem lesz sértődés, a vélemény szabad. Pusztán az érveidet hiányolom. Ott tartottunk, autót gyártanak, a gyártónak van felelőssége. Software-t is gyártanak, a gyártónak nincs felelőssége, s egyesek szerint ne is legyen. Mi van akkor, ha a program elszámolja magát, összedől a vele tervezett híd?

A programozó miért védettebb állat az autógyárban dolgozó mérnökhöz, helyesebben szólva a software cég az autógyárhoz képest?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezekben az esetekben általában nem hárítható el a felelősség, pl. saxus írt ilyenről már csak most nem találom. Kérdés, hogy egy szoftver bug miatt bekövetkező adatvesztés, mind gondatlan károkozás a szoftverfejlesztő vagy az üzemeltető felelőssége. Ez elég egyértelmű ha a szoftver olyan feltételekkel van terjesztve, hogy pl. nincs garancia arra, hogy nem okoz adatvesztést, ezzel áthárítva a felelősséget az üzemeltetőre. Nyilván ezt csak azért teheti meg, mert nincs olyan jogszabály, hogy egy szoftverfejlesztő nem háríthatja át magáról ezt a felelősséget. Szerintem jogilag az sincs kimondva, hogy ha pl. összedől egy híd, akkor az kinek a felelőssége, csak a megrendelő (pl. állam) nem fog olyan szerződésbe belemenni ami ezt a felelősséget az üzembentartóra hárítaná, pláne hogy egy ilyen eset könnyen emberéleteket is követelhet.

> Mi van akkor, ha a program elszámolja magát, összedől a vele tervezett híd?

Ez eleg egyszeru. A vegfelhasznalo (statikus) sara.
Neki mindig le kell ellenoriznie, es nem vakon megbizni egy mankoban.

Itt egy szoftver amit tipikusan erre hasznalnak: http://axisvm.eu/index.html

Szolj, hogyha te mast olvasol ki az EULA-jukbol.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A gond az, hogy muszáj (lenne/lesz) így fejleszteni, mert pl. az autók, amik egyre jobban ráépülnek az informatikai megoldásokra konkrétan emberéletekkel játszanak. Egy rossz algoritmus, és elszáll az autó a picsába. Autonóm autó. Na, üljön bele, akinek nem kedves az élete.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

+1, több ízben vitatkoztam már emberekkel, hogy "de milyen jó lesz a kugli okos avtója, mert akko' nem kő vezetni". A dolog jogi, etikai aspektusain (jogilag kié a felelősség, ha automata autóval ütsz el valakit?*) mindig sikerül felülemelkedniük, mert hát a mesterséges intelligencia és majd jól megtanulja... aztán persze vannak az elvakult fanatikusok, akiket egy teljesen életszerű, no-win scenarióval sem lehet meggyőzni arról, hogy függetlenül attól, hogy milyen intelligenciát, szoftvert adnál egy kocsinak, lesz baleset.

Na, üljön bele, akinek nem kedves az élete.

A gond akkor lesz, amikor ezeket kiengedik az utcára és jön a sok marha és elkezdi használni... az a kategóriás marha, aki "zavart az állandó sípolás" felkiáltással inkább kiköti a biztonsági öv érzékelőjét, minthogy bekapcsolja azt a szart; és ez a barom majd teljes nyugalommal fog mondjuk hulla részegen a volán mögé ülni (lásd: *), mondván, úgy sem ő vezet... és nem feltétlenül önmagát fogja kinyírni.

*: szerencsére egyelőre egyértelmű, nincs ország, ahol a forgalomba engednének automata autót ember nélkül, így az emberé, mert nem bírálta felül.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Persze, ha ételmérgezést kapok egy étteremben, arról is én tehetek, miért mentem oda?

Még mielött megint beidézi valaki az aláírásom, képzelje magát egy ilyen helyzetbe... biztosan azt mondaná: "á, semmi probléma, én kérek elnézést, majdnem meghaltam a szaruktól."

Túl megengedö a szoftveripar szabályozása, meg is látszik rajta.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

"Túl megengedö a szoftveripar szabályozása, meg is látszik rajta."

Oké, akkor mi itt a fejlett nyugaton szigorítsunk be. Lesz itt szoftver, csak méreg drága és bődületesen lassan fejlődő. A világ többi része meg huss, elsuhan. Mivel lassanként minden szoftver alapú, minden területen elhúznak. Jó lesz?

Igen, csak a mérgező étel és a balesetveszélyes autó betiltása előrevisz, míg a szoftveripar túlszabályozása esetleg pont nem. Pedig jó analógiának tűnik. Az a baj, hogy szoftverek esetén gyakran csak utólag tudod megmondani, hogy mit kellett volna betiltani. A legtöbb helyen fut milliónyi becsületesen összerakott regression test case set, mégis ramaty minden szoftver.

Oké, de hogyan szigorítanál? Én még hibátlan szoftvert nem láttam soha és nem hallottam olyan emberről, aki tudná, hogy hogyan lehetne ilyet írni a gyakorlatban. Ezért helyette tesztekkel próbáljuk meg felkutatni a hibákat, megkérdőjelezhető sikerrel. Láttam igen alaposan megtervezett tesztelést hatalmas erőforrásokkal, láttam modellek alapján generált teszteket, de ezek nem vezetnek hibátlan szoftverhez.

Aztán ott vannak az egyéb futásidejű védelmi mechanizmusok, pl. ASLR, stack protector, NX, SELinux, tűzfal, konténer/VM, IDS, fizikai hozzáférés védelem stb. és azt látjuk, hogy még így is minden támadható. És akkor erre jön rá az emberi tényező, ami földig rombolhatja bármikor bármelyik céget és intézményt. Egy rendszerből első körben az embert kéne kiküszöbölni, az a hibák fő forrása :)

Amire én reagáltam, az innen indult:

"Túl megengedö a szoftveripar szabályozása, meg is látszik rajta."

Oké, akkor mi itt a fejlett nyugaton szigorítsunk be. Lesz itt szoftver, csak méreg drága és bődületesen lassan fejlődő. ... Jó lesz?

Szerintem pont az a probléma amit wachag írt: az sokkal fontosabb, hogy egy szoftver gyorsan elkészüljön, mint az, hogy minél kevesebb hibát tartalmazzon. Ha a hibás szoftver kiadásának következménye a gyártóra nézve rosszabb lenne, mint a későbbi piacra kerülés, akkor a helyzet valószínűleg sokkal jobb lenne.

"Oké, de hogyan szigorítanál? Én még hibátlan szoftvert nem láttam soha és nem hallottam olyan emberről, aki tudná, hogy hogyan lehetne ilyet írni a gyakorlatban."

Nem tudom, és én sem tudok hibátlan szoftverről.
Tesztek nélkül már az is rengeteget segítene, ha minden bemenet rendesen validálva lenne, és az összes visszatérési érték illetve lehetséges exception kezelve lenne. Viszont ekkor egy funkció lefutása 5-ször annyi ideig tartana, és 10-szer annyi kódsort kéne írni hozzá. Ezt ma szerintem nem reális megvalósítani, ezért kéne a szemléleten változtatni, hogy értékesebb legyen egy hibátlan szoftver mint egy gyorsan megjelenő.

"ha minden bemenet rendesen validálva lenne, és az összes visszatérési érték illetve lehetséges exception kezelve lenne."

A legtöbb kódoló, akivel találkoztam, pont így csinálja. Plusz statikus analízis ezerrel. Plusz mindenféle, amit pl. a gcc nyújt. Mégis ratyi az eredménye.

Hát nagyon meglepődnék ha valóban pont úgy csinálnák :)
De ha a legtöbb kódoló, akivel találkoztál valóban pont úgy is csinálja, sajnos sokan akkor sem: lásd a HUP-on hibákról szóló híreket.

https://github.com/jduck/asus-cmd - HUP cikk
Then, it calls the memcpy and suspiciously checks the return value against zero.

http://randomthoughts.greyhats.it/2015/01/osx-bluetooth-lpe.html?m=1 - HUP cikk
Issue 1: When a user-space client provides an argument with a NULL value but a large size, a subsequent call to IOMalloc(size) fails, returning a NULL pointer that is eventually passed to callees, causing the NULL pointer dereference.
Issue 2: As shown in the screenshot below, IOBluetoothHCIController::BluetoothHCIChangeLocalName() is affected by an "old-school" stack-based buffer overflow, due to a bcopy(src, dest, strlen(src)) call where src is fully controlled by the attacker.
Issue 3: The function carefully checks that the supplied pointer is non-NULL; however, regardless of the outcome of this test, it then dereferences the pointer (...).
Issue 4: In this case, the problem is due to a missing sanity check on the arguments of the following function: ...

https://code.google.com/p/google-security-research/issues/detail?id=118 - HUP cikk
This function has a vulnerability where it doesn't correctly check the impersonation token of the caller to determine if the user is an administrator.

Többet cikket nincs időm/kedvem keresni, amennyire emlékszem elég sok itt megjelent bug hasonló problémákra vezethető vissza.

Nálunk a hibák nagy része nem a validálás hiányából ered. De ahol mégis, ott sem az a baj, hogy a kódoló általában ne validálná az inputokat, hanem hogy esetleg nem teljesen jól. Ezért nem tetszik a "Túl megengedö a szoftveripar szabályozása" megközelítés, mert még kód review-n is ragyogóan el lehet siklani sok ilyen felett.

Statikus analízis azért tud segíteni, de ez meg a másik őrület. Egyrészt sok fals pozitívval kell megküzdeni. Másrészt ha minden kis frinci-franci, alapvertően inline-olódó függvénybe ellenőrzések hadát építed be, az feleslegesen lassítja a kódolást és olvashatatlan eredményre vezet.

Ott van még az a probléma, hogy nem csak a függvény elején bejövő inputok, de a meghívott függvények visszatérési értékét vagy rosszabb esetben megváltoztatott paramétereit és még rosszabb esetben a megváltoztatott globális változókat is validálni kéne. Ez teljesen megölné a kódot. Még ha az adott verzió sokkal megbízhatóbb is volna, következő verzió egy ilyen trutymóból nem készíthető.

Ezekre persze vannak megoldási próbálkozások. Konstruktorokkal lehet az inicializálatlan változók ellen küzdeni, exceptionökkel és pl. null pointerek helyett üres objektumokkal lehet hibákat kezelni. Iterátorral esetleg lehet a rossz for ciklus ellen tenni. Set/get-tel és privát attribútumokkal is el lehet kerülni egyes hibákat (vagy legalább csak egy helyen kell javítani). Ha ezt a (sebtében összedobott, nyilvánvalóan hiányos és valószínűleg hibás) listát megnézed, mind OOP eszközök. Tehát ha mindenképpen szabályozást szeretnénk, akkor tiltsuk be a nem teljesen OOP nyelvek használatát kritikus helyeken (beleértve mindent, ami primitív típusok használatát megengedi)? Mert az OOP progik ugye olyan hibátlanok...

Immutable objektumok, finalized/const változók (különösen a globálisak esetében, de legjobb esetben mindenhol), exception handling, option típus használata ha van. Igen, ezeknek van teljesítmény vonzata, de minél jobban megkötöd a programozó kezét, annál kevesebb hibát fog véteni.

A TDD, vagy inkább egy becsülettel összehozott Continuous Integration rendszer nélkül ma már - remélhetőleg - nem készül semmi az iparban. De ez nem az általad említett "félmegoldás", hanem az alap. És sajnos a gyakorlat azt mutatja, hogy még mindig igen gyatra alap, még ha maga Uncle Bob is végzi a munkát.

( uid_17784 | 2015. 01. 15., cs – 15:54 )

Az miert van, hogy belebofgnek emberek a mikrofonba?

Szoftveripari szakertoi konferencia a hupon; sok idiota kepzeli magarol, hogy amihez itt hozzabofog, ahhoz van egy pici koze, de __affinitasa__az biztosan nagy.

Nem kell hozongni, pontosan tudom a reakciot, amit kivalt a fenti boffenet! (a vege csak mert igy helyes)

( Darkcomet | 2015. 01. 15., cs – 17:36 )

Éleződik a nemzetközi helyzet, ahogy megboldogult Virág elvtárs mondaná. Most a Microsoft került szopóágra, sokáig ugye meg ők szopattak másokat. Ezzel ugyan semmi baj sem lenne, csak ezt a szopatást a Google egyre gusztustalanabbúl csinálja. Bocsi az alpári megfogalmazásért.

--------------------------

Csak a viták elkerülése végett. Ha nem használok ékezetet, mobiltelefonról írok.

( Som-Som | 2015. 01. 15., cs – 18:33 )

Úgy sejtem, hogy a hibák ismerete hatalmas nagy vagyonná tehető érték, hiszen a hibára épülő támadó programokat jó pénzért lehet árulni. Ha viszont valakik kifecsegik a részleteket, akkor többen versenyeznek ugyanazon a pályán, ami hatalmas áresést hozhat. Ezzel egyrészt a bűnözők összes vagyona csökken és nem is annyira koncentrálódik. Nekem ez elég pozitív következménynek tűnik még akkor is, ha pl. script kiddie-k miatt esetleg a többeket ér támadás.

Remélem az MS elég nagy bug bounty-t fizet a Google-nek, hiszen egy csomó tesztelést megspórol nekik egy ilyen önkéntes tesztelés.