Bezpečnostní problém Stagefright v Androidu

Na stránkách společnosti Zimperium (Wikipedie) byly zveřejněny informace o vážném bezpečnostním problému (CVE-2015-{1538,1539,3824,3826,3827,3828,3829}) nalezeném v knihovně Stagefright v Androidu. Problém se týká 95 % zařízení s Androidem. Detaily budou zveřejněny na bezpečnostních konferencích Black Hat USA a DEF CON 23 příští týden.

27.7.2015 23:00 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[R]

Keby to bola normalna linuxova distribucia, tak zajtra to moze mat kazdy spustenim napr. "apt-get update && apt-get upgrade" opravene.

V bordeli menom Android zostane tento bug na velkom mnozstve zariadeni neopraveny.

[kyknos]

sere na to pes, mobil, ktery se furt nekde vali a potencionalni utocnik k nemu snadno ziska fyzicky pristup stejne zabezpecit nejde

[.]

I když nemám potřebu ho nějak opatrovat, tak se mi mobil teda nikdy nikde jen tak neválí.

[kyknos]

kde ho mas? porad v kapse? co ted v lete treba na plazi, beres ho s sebou do vody?

[HonzaRez]

Tzv. mezipůlní model...

[Atrament]

Tak když jde člověk na pláž s tím, že se bude i koupat, tak si snad mobil sebou nebere ne? Aspoň mne by to teda ani nenapadlo :)

[koudy]

Já sebou mobil tahám skoro vždy a všude.

Neříkám, že ho vždy a všude zvedám (on slouží mě, ne naopak :) ), ale je to skoro jako s peněženkou, jdu ven, beru ho..

[kyknos]

takze koupat je vzdy specialni vyprava, nemuze se stat, ze e jen tak vykoupes, protoze jdes kolem rybnika? .)

[Atrament]

Ne, to se mi stát opravdu nemůže :)

[kyknos]

no jo zapomnel jsem, ze jsem na abclinuxu :)

[AsciiWolf]

[Jendа]

Získá, ale ani s fyzickým přístupem to není tak snadné. SD karta je šifrovaná, displej je zamčený a bootloader je rozbitý/zamčený. Pokud tam není chyba v USB (byly chyby že mu šlo po USB říct „dej mi shell“), napadá mě jenom rozšroubovat to a připojit se na JTAG/flashku vevnitř.

[Jendа]

Jenže fyzický útok je něco jiného než když si koupíš za pár korun tarif s neomezenými MMS a rozešleš to na milion čísel.

[kyknos]

ale to je mi popravde receno celkem jedno

ma mi to vadit, protoze spam v siti? not my problem

nebo protoze si milion lidi prohlidne nejakou mou genialni fotku? enjoy :)

popravde asi nejvic by me nasralo, kdyby mi nekdo ukradl ingress ucet

[xm]

To je totální nesmysl co říkáš. Mobil mám zašifrovaný silným heslem a mám nainstalovanou opensource aplikaci SnooperStopper, která hlídá počet pokusů o odemčení displaye a po 3 neúspěšných rebootuje mobil (takže útočník po rebootu musí zadat silné šifrovací heslo).

Takhle lze mít jednoduchý krátký PIN (či gesto) na odemčení displaye (ve SnooperStopperu je možné změnit šifrovací heslo nezávisle na heslu, PINu či gestu pro odemčení displaye) a přesto mít mobil bezpečný. Samozřejmě vyžaduje to mít root práva.

[kyknos]

a kdo dela s mobilem takove opicarny? a proc?

mimochodem roota nemam, stejne jako vetsina lidi... nevim proc bych se mel namahat, telefonuje to i bez nej, vyrobce to nepodporuje...

[Jendа]

a kdo dela s mobilem takove opicarny? a proc?

Protože by chtěl mobil používat mimo jiné jako GPS s logováním, na čtení citlivých šifrovaných mailů a Jabberu, pro šifrované telefonování přes SRTP/ZRTP, pro focení věcí do kterých nikomu nic není, na nouzové zásahy na serverech a jako terminál pro různé interní systémy. A k tomu je kupodivu potřeba ho zabezpečit.

A i kdyby nic z toho nedělal, pořád kompromitovaný telefon znamená trackování polohy a nahrávání okolních rozhovorů vzdálenou aktivací mikrofonu, což podle databáze uniklé z HackingTeamu dělá třeba česká policie.

Na mobilu možná fakt nic citlivého nemáš, ale neříká se ani nic takového v jeho blízkosti? Nebo sis udělal hardwarový odpojovač mikrofonu? (asi těžko, když se bojíš i rootnutí)

[prqek]

... GPS s logováním ...

Co tím přesně myslíš?

[Jendа]

Jako že když to někdo vyhackuje, tak si může stáhnout záznam kdy jsem kde byl.

[prqek]

To je featura, kterou chceš? Proč? Chápal bych, že ty chceš mít přehled, kdes byl, ale to už ty telefony dneska umí a Goolge, alespoň v tomhle případě, ty údaje poskytuje. Sice mi to tvrdilo, že jsem jednou byl v Kladně, což určitě není pravda, ale jinak to celkem sedělo.

[xm]

He? On říká že si sám loguje GPS pozici kde byl a právě že _nechce_ aby se k těmhle datům někdo dostal (tedy logicky ani nebude používat služby od Google k logování polohy, to by ty data rovnou mohl volně posílat na web ).

[Jendа]

To je featura, kterou chceš? Proč?

Už se mi párkrát hodilo vědět kde jsem kdy byl (momentálně to dělám zaznamenáváním wifi sítí). Nebo jako proč chci aby když mě někdo vyhackuje on věděl kde jsem? No to právě nechci! :)

Chápal bych, že ty chceš mít přehled, kdes byl, ale to už ty telefony dneska umí a Goolge, alespoň v tomhle případě, ty údaje poskytuje.

Jako že bych svoji polohu ohlašoval Googlu? To zní opravdu lákavě.

[prqek]

Už se mi párkrát hodilo vědět kde jsem kdy byl (momentálně to dělám zaznamenáváním wifi sítí). Nebo jako proč chci aby když mě někdo vyhackuje on věděl kde jsem? No to právě nechci! :)

Takle už to chápu :)

Jako že bych svoji polohu ohlašoval Googlu? To zní opravdu lákavě.

Jestli máš telefon s Androidem, tak už se to dost možná děje... I když u tebe bych očekával, žes s touhle fíčurou zatočil :)

[Jendа]

Jestli máš telefon s Androidem, tak už se to dost možná děje...

Moc ho nenosím, protože šmíruje, je v něm backdoor a vzdáleně snadno zneužitelná chyba kterou už výrobce neopraví (tato zprávička). Byla to opravdu „výhodná“ koupě.

Za levno prodám Samsung Galaxy Chat, rootnutý.

[kyknos]

ta ficura je nahodou super, dosel jsem si takhle pro telefon, ktery mi nejaky debil slohnul

[Jendа]

K tomu ale přece není potřeba posílat ty informace do Googlu.

[kyknos]

to samozrejme ne, ale zas na druhou stranu, google to dela sam, ja bych se s takovou ficurou nenamahal

ale pak se hodila, kdyz jsem asi dva mesice po ztrate telefonu zjistil, ze porad loguje mou polohu a odstehoval se do budejic :D

jak rikam, to ze google loguje mou polohu me netrapi, protoze stejne hraju ingress, ktery patri google :D

[kyknos]

s telefonem hraju ingress, takze o moc vic mou polohu logovat nemusi :)

pokud ale ingress nehraju, je obvykle vypnuty (ano, opravdu vypnuty, nic nezere baterku tak, jako ingress) a pohozeny nekde buh vi kde

[xkucf03]

+1

Upgradoval jsem na SE K750i

[SGF]

Taky máme doma 2 kusy, ale musím říct, že to je příšernej krám Mnohem víc mi vyhovoval SE T700, který jsem kdysi vlastnil. Bohužel oba dva trpí hloupou konstrukcí nabíjecího konektoru, takže připojit nabíječku tak, aby nabíjela je akce na 5 minut. Člověk to připojí, ono to problikne, ale nenabíjí. Tak se s tím musí trochu verglovat, což pomůže jednou ze 100 případů.

[Radek Miček]

Since media processing is often time-sensitive, the library is implemented in native code (C++) that is more prone to memory corruption than memory-safe languages like Java. (Experts Found a Unicorn in the Heart of Android)

Kéž by jazyky C, C++ a podobné zmizely.

[koudy]

Ovladače/jednočipy se budou psát pak v...asm?

"Když budu mít jen kladivo, všechny problémy budou vypadat jako hřebíky."

[Radek Miček]

Ovladače/jednočipy se budou psát pak v...asm?

Hledal bych jazyky, které unsafe konstrukce dovedou uzavřít pouze ve vymezených částech kódu (například Rust, ATS nebo C#).

[koudy]

Co si představujete pod pojmem "uzavřít"? Oddělit paměťově?

Pokud v tom bude memory corruption, jak se takový systém zachová?

[Radek Miček]

Co si představujete pod pojmem "uzavřít"?

Uzavřít ho třeba do bloku unsafe {}. To samozřejmě nezaručí paměťovou bezpečnost, ale aspoň víte, kde nebezpečný kód hledat.

Navíc knihovny jako Stagefright by takový kód vůbec neobsahovaly – vyhradil bych jej například pro ovladače.

[koudy]

Neříkám, že to není zajímavá myšlenka, ale stále nevidím přínos -

jak píšete, ani unsafe { } neoddělí proces od nebezpečné části, takže pokud dojde k problému třeba i v knihovně (předpokládám, že správa paměti přidělí volané fuknci z knihovny stejný paměťový prostor jako má proces) složí se pravděpodobně celý proces. Nebo nebude fungovat jedna část, pokud to bude dobře "zapouzdřené", což je určitě lepší, ale stejně se musí opravit ta část co nejde.

Jen chci říct, že tu "nikdy nebude" (nikdy neříkejte že něco nejde...) programovací jazyk, který vyřeší všechny problémy - někdy je kvůli jednoduché správě paměti lepší použít "low level" jazyk protože víte, že to bude jednoduché ovládání nějakého osvětlení a nebude to na milion řádků.

[Radek Miček]

ale stále nevidím přínos

Přínos je, že toho nebezpečného kódu máte málo a máte ho jasně oddělený. Tyto nebezpečné části kódu pak můžete důkladněji testovat, revidovat nebo formálně verifikovat. V C nebo C++ je potenciálně každá funkce nebezpečná, tudíž tam musíte věnovat zvýšenou pozornost celému kódu, což v praxi nejde, neboť by to bylo příliš nákladné. Navíc je v C a C++ řada konstrukcí, které nemají ani definované chování, což snižuje efektivitu revizí kódu.

[biolog]

+1

[koudy]

V tomhle máte pravdu.

Chápu, že odhalování takových chyb může být jednodušší, protože je většinou svázáno s objektem/částí kódu.

Na druhou stranu, pokud vám něco v programu nefunguje, tak to musíte opravit a je jedno, že to je v "dobré" nebo "špatné" části. Sice můžete mít v pořádku ovladač zařízení, ale do toho ovladače budou chodit špatné informace.

Jako většina věcí v životě má každý nástroj své klady a zápory.

V C jsem něco málo napsal, takže vím, že ta správa paměti většinou není zas takový "opruz" - jen je dobré dodržovat nějaké "best practice".

To je ale dobré dodržovat vždy. Zkuste si v objektu/struktuře kde jsou všechny proměnné nazvané AhojClovece, NevimCoSTim nazvat proměnnou se*u_na_konvence a uvidíte jak Vás kolegové budou mít rádi...

Skoro vždy je důležitější kdo to píše, než v čem. (předpokládán jistý inteligenční kvocient)

BTW: Díky za rozumnou a přínosnou diskusi (alespoň pro mě) .

[xkucf03]

jak píšete, ani unsafe { } neoddělí proces od nebezpečné části, takže pokud dojde k problému třeba i v knihovně (předpokládám, že správa paměti přidělí volané fuknci z knihovny stejný paměťový prostor jako má proces) složí se pravděpodobně celý proces.

Proto je lepší některé úlohy vyčlenit do samostatných procesů, které můžou běžet pod jiným uživatelem, v kontejneru nebo třeba i na jiném stroji. Např. kódování videa, sazba PDF nebo třeba indexace dokumentů můžou běžet v jiném procesu, než správa uživatelů. Stejně tak jdou oddělit veřejné části systému od těch, které jsou určené pro zaměstnance nebo vybrané uživatele.

[koudy]

Jj to mi přijde jako rozumnější a funkčnější řešení, ale tady je zas jedno, jaký programovací jazyk použiju.

Proto si stále myslím, že dobře navržené řešení ulehčí programátorovy práci víc, než jakýkoliv programovací jazyk. (a v kombinaci se správným jazykem se to pak "píše samo" - jak často slyším od managera :D )

[Atom321]

Kéž by jazyky C, C++ a podobné zmizely.

To by za ně nejprve musela existovat plnohodnotná náhrada. A to nemluvím o přepsání starého kódu.

[Radek Miček]

Co přesně chybí v jiných jazycích? Například, proč myslíte, že nejde kód z C++ přepsat do C#?

[chrono]

Napr. preto, lebo Android nepodporuje C#. Každopádne ak by stačilo niečo ako C# tak by určite použili Javu.

[Radek Miček]

C# lze překládat i do nativního kódu.

[noo]

A proč by to proboha někdo rozumný dělal? Proč by vůbec někdo měl chtít programovat v C#.

[Jendа]

Lidi jsou různý. Někdo do sebe píchá špendlíky, někdo si zapíše Proseminář z matematické analýzy a někdo zase programuje v C#.

[biolog]

Někdo rozumný by to proboha dělal proto, aby se vyhnul JIT překladu a tím zrychlil start. A aby odstranil metadata, což ztíží reverse engineering na úroveň C (v closed-source to berou jako důležité). Myslím že to i odstraní závislost na .NET knihovnách.

Proč by vůbec někdo měl chtít programovat v C#.

Zeptejte se spousty programátorů na C# fórech, čí zaměstnavatelů, proč jsou tak hloupí.

[noo]

Protože si nechali nakydat do ucha od M$

[Radek Miček]

Proč by vůbec někdo měl chtít programovat v C#.

Na rozdíl od Javy máte hodnotové typy a reifikovaná generika, což se hodí při psaní kódu náročného na výkon.

[xkucf03]

Javu taky.

[Radek Miček]

Pointa ovšem byla, že v C# se dá celkem pohodlně psát i nízkoúrovňový kód (na rozdíl od Javy).

[Atom321]

C# nemá (nebo má jen mizernou) podporu některých platforem - Androidu, "malých" procesorů (Cortex-M3, m68k/ColdFire). Dost blbě se tam např. používá inline-assembler - tedy, alespoň to platilo v době, kdy jsem se na to naposledy díval. Moc si nedovedu představit jak napsat v C# drivery hardwaru nebo bootloader.

Správnou cestou je IMHO kombinace - běžný aplikační kód psát v C#/Javě, zatímco v C/C++ jen speciality, kde se C#/Java nehodí. Drivery pro HW dekodéry videa bohužel spadají spíš pod ty speciality.

Přepsání starého kódu je technicky možné, ale reálně se to nevyplatí. Potřebujete na to programátory, kteří dobře ovládají oba jazyky a budou ochotní to dělat. Takoví dobří programátoři odvykle neradi dělají nudnou práci, takže je budete muset motivovat - dobře jim zaplatit. Ve výsledku ale software bude dělat to samé, co předtím a to u managementu budete dost těžko obhajovat.

[kyknos]

bezny aplikacni kod v jave je atentat na uzivatele

[Radek Miček]

Moc si nedovedu představit jak napsat v C# drivery hardwaru nebo bootloader.

Co přesně je podle vás problém? AFAIK uvnitř unsafe bloků můžete v C# psát prakticky stejný kód jako v C (což není dobrý nápad) až na zmíněný inline assembler – ten musíte napsat mimo a vytvořit mixed assembly.

zatímco v C/C++ jen speciality, kde se C#/Java nehodí

Co je na nich tak speciálního, že musí být v C/C++? Proč nestačí v C/C++ napsat třeba jen několik malých funkcí, proč to musí být celé v C/C++?

[Atom321]

Moc si nedovedu představit jak napsat v C# drivery hardwaru nebo bootloader.

Co přesně je podle vás problém? AFAIK uvnitř unsafe bloků můžete v C# psát prakticky stejný kód jako v C (což není dobrý nápad) až na zmíněný inline assembler – ten musíte napsat mimo a vytvořit mixed assembly.

Ano, uvnitř unsafe bloků. Jenže u bootloaderu není žádné "uvnitř". Typický bootloader je kus kódu, který se spouští jako úplně první věc (nebo druhá - po loaderu v boot-ROM). Při svém startu nemá inicializovaný základní hardware. Kód běží z flashe nebo malé interní RAM (typicky jednotky/desítky KB). Nemá k dispozici nic - žádné volání operačního systému, scheduler, alokaci paměti. Běžné knihovní funkce jako printf() jsou osekané nebo vůbec nejsou. Není zde místo ani pro obyčejný malloc(), natož pro garbage collector. Například můj první bootloader byl pro EP9135, musel se vejít do 2KB SRAM, inicializovat SDRAM a stáhnout přes sériový port second-stage bootloader (u-boot). Inicializace HW byla komplet assembleru. Stažení dat přes UART se vešlo naspané v C, z čehož jsem měl velikou radost.

Drivery jsou jiná kapitola - paměti je sice dost, ale zase musíte brát ohled na ostatní věci běžící v OS. V obsluze přerušení smíte použít jen to, co si driver zabral už předtím. Nemůžete alokovat další paměť - protože kód správy paměti není reenterantní a možná jste právě jeho běh přerušili. Nemůžete použít zámky - protože zámek drží proces, který jste přerušili a pustí ho, až vy skončíte a on bude moci pokračovat. Vše co děláte, musíte udělat rychle - protože síťový adaptér už má plný buffer a tahá za interruptový signál ke svému driveru.

zatímco v C/C++ jen speciality, kde se C#/Java nehodí

Co je na nich tak speciálního, že musí být v C/C++? Proč nestačí v C/C++ napsat třeba jen několik malých funkcí, proč to musí být celé v C/C++?

Ale stačí a stále častěji se to tak i dělá. Akorát ty "malé funkce" v některých případech hodně narostou - typicky právě u těch kodeků.

[elenril]

Jako by všechno co má jen managed práci s pamětí bylo okamžitě zcela bezpečné. V high-level jazycích se bezpečnostní díry dělají úplně stejně dobře, akorát jsou jiného druhu. Nemluvě o tom, že v leckterém vysokoúrovnovnovém jazyce každý takyprogramátor je schopen zbastlit něco co "funguje". Kdežto u C musí většinou člověk mít aspon trochu představu o tom co dělá.

[trekker.dk]

A to nemluvě o tom, že vysokoúrovňové jazyky zpravidla mají nějaký interpreter, ve kterém mohou být (a jsou) chyby, které pak umožní stejné zneužití jako ten kód v C.

[Radek Miček]

ve kterém mohou být (a jsou) chyby, které pak umožní stejné zneužití jako ten kód v C

Ano. Nicméně ve vysokoúrovňových jazycích, kde se běhové prostředí distribuuje odděleně od programů, stačí opravit ono běhové prostředí a chyba zmizí ze všech programů. Zatímco u programů v C a C++ musíte opravit jednotlivé programy, neboť chyby jsou přímo v nich. Navíc běhové prostředí bývá mnohem více testováno, než běžné programy.

[sonicpp]

Trochu divná úvaha - na druhou stranu zase můžeš říct, že jedna chyba v interpretu a máš chybu ve všech programech. Plus chyby, který můžeš udělat stejně jako v C++. Zas tomu C# tak nevěř ;)

[Radek Miček]

na druhou stranu zase můžeš říct, že jedna chyba v interpretu a máš chybu ve všech programech

Ano. Nicméně, jak už jsem psal výše, ten interpretr je jeden program, takže ho lze důkladně zkontrolovat, otestovat a případně i formálně verifikovat. Zatímco, abyste chyby přístupu do paměti eliminoval v C a C++ programech, musíte provést kontrolu každého programu, což se většinou nezaplatí.

Krom toho chyby bývají i v kompilátorech C a C++. A jelikož se jedná o poměrně složité a ne zrovna dobře navržené jazyky, není jednoduché tyto chyby v kompilátorech eliminovat (pro C se o to snaží například CompCert).

[Jendа]

Kolik takových chyb bylo třeba v cpythonu?

[trekker.dk]

Kolik lidí to používá (tj. jak velká je základna lidí, kteří mají motivaci ty chyby hledat, ať už z jakéhokoliv důvodu)?

[Jendа]

Jako kolik lidí používá CPython? Všichni?

[trekker.dk]

Dobře, o čem se bavíme? Že v tom interpeteru žádné chyby nikdy nebyly, nejsou a nikdy nebudou?

[Jendа]

Bavíme se o

vysokoúrovňové jazyky zpravidla mají nějaký interpreter, ve kterém mohou být (a jsou) chyby

Jediná taková chyba na kterou si vzpomínám bylo nějaké divné spouštění věcí v Perlu, tak mě zajímalo, jestli máš příklady i na nějaké jiné populární interpretry.

[Mrkva]

Ty desitky 0dayu pro kazdy prohlizec ktere vetsinou zahrnuji javascript virtual machine? Nebo shellshock v bashi?

[biolog]

V Javaskriptovém virtuálním stroji chyby nebývají. Bývají v API přístupných skriptům. Přikládám chyby, které opravili v posledních dvou verzích Firefoxu a které se dají vyvolat přes JS:

• chyby v Cairo texturách+zipování+zase zipování+Direct3D+barvy+nsXMLHttpRequest (mfsa2015-66)
• use-after-free v případě XMLHttpRequest a web workerů (mfsa2015-65)
• chybné zpracování Content Policy na DOM objektu u microtasků (mfsa2015-63)
• vykreslování audia (mfsa2015-62)
• špatné čtení pointeru v Indexed Database Manager (mfsa2015-61)
• webchannel dodával odpovědi i cizím oknům (mfsa2015-56)
• parsování MP4 metadat (mfsa2015-55)
• parsování XML (mfsa2015-54)
• vytváření Media Decoder Thread (mfsa2015-53)
• vertikální texty (mfsa2015-51)
• SVG ve stránce s CSS (mfsa2015-48)
• parsing of H.264 (mfsa2015-47)

Jako JS-specifická chyba se dá považovat chyba v:

• Memory safety problem in ArrayBufferBuilder::append (CVE-2015-2739)
• Out-of-bounds read and write in asm.js validation (mfsa2015-50)

(Vynechávám zranitelnosti, které se netýkaly JS.)

Tedy mi přijde, že v runtime JS chyby moc nebývají. Určitě se nedá říct, že by zranitelnostmi bylo prolezlé, jak říkají někteří diskutéři.

[Jendа]

V browseru jde většinou o escape již běžícího kódu ze sandboxu, ne kompromitaci důvěryhodného kódu vstupními daty.

S tím shellshockem máš pravdu, i když Bash není zrovna klasický případ interpretru.

[biolog]

Aha, zapomněl jsem na Bash.

Shelshock je chybně implementovaná funkcionalita, která je dodávaná s Bashem, ale pro interpretování shelových skriptů není podstatná. (Dokonce ani není známo, že by ji nějaká skript používal.)

Je to podobné, jako kdyby Bash programům/jobům na pozadí předával cizí vstup v případě, že byl Bash spuštěný na neobvyklých terminálech (terminály musí job control podporovat, a mohou ho implementovat nekompatibilně). Nesouvisí to s bezpečným interpretováním skriptů, ale je to featura dodávaná s programem, který obsahuje (hlavně) interpret.

[trekker.dk]

Nevim, jestli je to přesně cpython (a hledat se mi to nechce), ale co třeba tohle? https://www.debian.org/security/2002/dsa-159

Ruby má dokonce stránku (něco jako) has there been a security vulnerabilty today? Pravda, tam počítají i Ruby on Rails, ale chyby v interpreteru nebo standardní knihovně si pamatuju taky.

[Bystroushaak]

Nevim, jestli je to přesně cpython (a hledat se mi to nechce), ale co třeba tohle? https://www.debian.org/security/2002/dsa-159

Tohle třeba nic. Vždyť je to z roku 2002 (13 let zpět) a navíc to nebyla zrovna dvakrát kritická chyba.

Python je právě krásná ukázka toho co Jenda popisuje, protože těch bugů je tam málo a spousta z nich jsou prkotiny.

[trekker.dk]

Takže pokud tu chybu označíte za "ne zrovna dvakrát kritickou", tak se nepočítá a tvrdíte, že v interpreteru Pythonu chyby nebyly, nejsou a nikdy nebudou? (#77)

[Bystroushaak]

Ne, díky za nabídku, ale do tohohle flame se zatáhnout nenechám.

[Jendа]

Nevim, jestli je to přesně cpython (a hledat se mi to nechce), ale co třeba tohle? https://www.debian.org/security/2002/dsa-159

Zapomněl jsem dodat že mi jde typicky o remote exploity :)

[trekker.dk]

Dobrá, uznávám, zastával jsem chybný názor, ale nyní jsem poučen. Proto opravuji #26 na "V interpreterech vysokoúrovňových jazycích nemohou být a nejsou chyby."

[biolog]

Ta chyba z 2002 je ve funkci os._execvpe, tedy je to chyba v knihovně dodávané s interpretem, protože volali Céčkovou funkci execvp špatně (chtěli ji volat jinak, protože pythoní skripty mají vidět jiné chování). Nebyla chyba v interpretu samotném.

Ruby má tu stránku https://www.ruby-lang.org/en/security/. Tady jsou chyby od roku 2009 v interpretu samotném, ne v dodávaných knihovnách:

• Hash-flooding DoS vulnerability for ruby 1.9 (CVE-2012-5371)
• $SAFE escaping vulnerability about Exception#to_s / NameError#to_s (CVE-2012-4464, CVE-2012-4466)
• Denial of service attack was found for Ruby's Hash algorithm (CVE-2011-4815)
• Exception methods can bypass $SAFE
• Heap overflow in String (CVE-2009-4124)

Nepočítám chybu CVE-2013-2065, kde byla zranitelná ochrana (taint detection), která v nižších jazycích není vůbec a musela by se psát ručně. Takže máme co, tak 1 chybu ročně?

[Bystroushaak]

Kolik lidí to používá

Řádově miliony, možná desítky milionů? 100k je jen odběratelů /r/python (tj programátorů, co sleduje konkrétní subreddit).

[Radek Miček]

Jako by všechno co má jen managed práci s pamětí bylo okamžitě zcela bezpečné.

Nic takového jsem neřekl.

V high-level jazycích se bezpečnostní díry dělají úplně stejně dobře, akorát jsou jiného druhu.

Tyto chyby jiného druhu nejsou v C a C++?

[elenril]

O C++ se nebudu vyjadřovat, protože v něm nepíšu, ale C je velmi kompaktní a jednoduchý jazyk a je zcela v silách průměrného programátora ho celkem rychle pochopit a ovládnout celý. Kdežto vysokoúrovnové jazyky mají často tuny (mis)featur a vyžadují roky studia, aby člověk pořádně zvládl jejich vzájemnou interakci. Takže ano, řekl bych, že spousta chyb pramenících z nedostatečného pochopení jazyka v C nebude.

[koudy]

+1 - jako průměrný programátor musím s tímto souhlasit :)

[Bystroushaak]

O C++ se nebudu vyjadřovat, protože v něm nepíšu, ale C je velmi kompaktní a jednoduchý jazyk a je zcela v silách průměrného programátora ho celkem rychle pochopit a ovládnout celý.

Jo, proto se v něm opakují stále ty samé bezpečnostní bugy (koukám na tebe, buffer overflow) už asi 30 let.

Kdežto vysokoúrovnové jazyky mají často tuny (mis)featur a vyžadují roky studia, aby člověk pořádně zvládl jejich vzájemnou interakci.

Jako bys v C nakonec nedělal úplně to samé, jen často vlastní (ne-úplně kvalitní) implementací. Kdybych měl počítat kolikrát jsem v C viděl implementovaný lineární spojový seznam, nebo asociativní pole, asi bych se nedopočítal. Výhoda C v korporátní sféře teda je, že na tom můžeš zabít pár dní, takže vypadáš že něco děláš, i když nic neděláš.

[koudy]

Ten buffer overflow je tam určitě už něco přes 40 let (asi tak 43) :)

Ať budete psát v čemkoli, pokud se jedná o složitější projekt než 1 000 řádků, tak bude trvat delší dobu "přijít" na to kam a jak změnu provést, než ji tam opravdu napsat. (nemluvím o přebarvení nějakého prvku, protože se to šéfoj nelíbí, ale zásah do několika objektů/souborů/doplňte si dle svého programovacího jazyku, kvůli nové funkcionalitě)

Navíc pokud si dělám sám analýzu chování zákazníka/výrobku/..., bude programování jen chvilka z celé pracovní doby a přes to to bude přesně to co po mě zaměstnavatel chce.

Takových lidí co dělají že dělají je, to ale neznamená, že se v C nedá vyvíjet rychle a pokud se dodržují určité standardy tak i bezpečně a celkem pohodlně. (i když by někteří řekli, že jako člověk používající vim k programování asi nemám o pohodlnosti vůbec představu :) )

[biolog]

Co má managed práci s pamětí bývá prakticky zcela bezpečné. V runtimu (JIT/interpret, implementace GC) managed jazyků bezpečnostní chyby nebývají - bývají v knihovnách, co se s nimi dodávají, viz Suní Java a PHP. Navíc jejich dodavatelé na bezpečnostní problémy reagují řádově rychleji, než autoři běžných aplikací.

SQL injection, CSRF, zapomenutí autentizovat a podobné chyby je možno napsat v nízkoúroňových i vysokoúrovňových jazycích stejně dobře, ale v high-level jazycích nízkoúrovňové chyby (přepsání bufferu atd) nejsou, ledaže by autor použil unsafe blok, tedy vysoúrovňové jsou bezpečnější.

Vlastně bych řekl, že vysokoúrovňové jsou lepší i proti SQL injection a podobným vysokoúrovňovým chybám, protože kód je stručnější a programátor si spíše všimne, že ve funkci např chybí escapování.

[Jendа]

Vlastně bych řekl, že vysokoúrovňové jsou lepší i proti SQL injection a podobným vysokoúrovňovým chybám, protože kód je stručnější a programátor si spíše všimne, že ve funkci např chybí escapování.

Programátor by v první řadě neměl slepovat textový SQL dotaz s parametry uvnitř, proboha!

[biolog]

Přesně o tom mluvím. Ve vyšších jazycích jde taková chyba vidět snadněji. (Doplnění: V případě SQL by se měly používat parametrizované dotazy, ale jde i escapování a slepování. V případě generování HTML a Javascriptu používat templejty nebo escapování a slepování. Stále platí to o čitelnosti ve vyšších jazycích.)

[Bystroushaak]

V případě SQL by se mělo používat ORM. K tomuhle tam pak prostě nemůže dojít.

[xkucf03]

V případě SQL by se mělo používat ORM

To jakože vždycky? :o

(ORM mám celkem rád a často ho považuji za dobrou volbu, ale dovedu si představit dobře a bezpečně napsanou aplikaci i bez něj – a někdy je to lepší bez ORM)

[Bystroushaak]

Osobně poslední dobou preferuji nepoužívat SQL vůbec a používat rovnou objektové databáze. Neříkám, že to tak jde vždy, ale člověku to usnadní dost sraní.

(ORM mám celkem rád a často ho považuji za dobrou volbu, ale dovedu si představit dobře a bezpečně napsanou aplikaci i bez něj – a někdy je to lepší bez ORM)

Neříkám že to nejde, jen prostě proč. Jen se tím zvyšuje náchylnost k chybám a kód je pak zmixovanost dvou jazyků, přičemž oba fungují úplně jinak a ten druhý skládám stringama (podívej mami, já umím jezdit na kole bez držení - kdo si myslí, že je to dobrý nápad, ať se přihlásí). Nehledě na to, že se tam pak pořád objevují stejné vzory sáhnu_do_databáze-zkontroluji_hodnoty-něco_udělám, místo aby tam byla jen ta část něco_udělám a zbytek se přesunul do ORM.

[xkucf03]

Neříkám, že to tak jde vždy, ale člověku to usnadní dost sraní.

Ono zase když máš pak v těch datech něco hledat, tak dost usnadní práci, když máš model rozumně navržený a jakž takž normalizovaný. Pokud začínáš objektovým modelem a ten databázový ti zázračně vyčaruje nějaké ORM, tak to dost často nemusí vyjít.

Neříkám že to nejde, jen prostě proč. Jen se tím zvyšuje náchylnost k chybám … a ten druhý skládám stringama (podívej mami, já umím jezdit na kole bez držení - kdo si myslí, že je to dobrý nápad, ať se přihlásí).

O nebezpečí „SQL injection“ se ví už hodně dlouho a bylo o tom napsáno nespočet varovných článků, takže jestli to někdo dosud nepochopil a nedokázal se s tím vyrovnat, tak bude mít patrně i jiné a mnohem vážnější problémy.

kód je pak zmixovanost dvou jazyků

To by samo o sobě nevadilo – spíš naopak: je dobré používat jazyk navržený pro daný účel. Problém je spíš v nedostatečné propojenosti – kompilátor Javy mi nezkontroluje SQL vložené v kódu jako řetězec (stejně jako regulární výrazy, XPath dotazy a další výrazy) a taky tu dochází k nežádoucí duplikaci informací (názvy sloupečů a tabulek vs. názvy tříd a metod/atributů). Ale i tohle je řešitelné, např. pomocí JOOQ nebo různých query builderů. Já např. píšu SQL do zvláštních souborů, ne přímo do kódu (v Javě nebo podobném jazyce).

Navíc to není nic oproti dynamickým jazykům, kde si nemůžeš být jistý vůbec ničím a musíš si na všechno napsat testy.

Bylo by fajn, kdyby tyhle výrazy (SQL, regulární výrazy, XPath, různé EL atd.) šlo automatizovaně validovat (zrovna u toho SQL by to šlo velice dobře, stačí ho rozparsovat a zkontrolovat, zda dává smysl vzhledem k danému datovému modelu). Líbilo by se mi mít pro podporu v Jazyce a v IDE.

Nehledě na to, že se tam pak pořád objevují stejné vzory sáhnu_do_databáze-zkontroluji_hodnoty-něco_udělám, místo aby tam byla jen ta část něco_udělám a zbytek se přesunul do ORM.

Můžeš poradit nějaké prostředí, kde je přechod mezi daty uloženými persistentně (na disku) nebo v nějakém externím zdroji (typicky síť) a daty načtenými v aktuální paměti úplně bezešvý? Taky je potřeba řešit víceuživatelský a vícevláknový přístup. Bylo by to hezké, ale přijde mi to jako utopie, že všichni odevšad budou s daty pracovat, jako by to byla proměnná v jejich paměti.¹ Takže nakonec stejně musíš pro data nějak někam sáhnout, pak s nimi něco děláš, a pak je zase persistentně někam uložíš – ať už s ORM nebo bez něj.

Neříkám že to nejde, jen prostě proč.

Taky je to trochu otázka perspektivy – jestli je pro tebe databáze nějaké nedůležité odkladiště dat a nutné zlo, zatímco primární je aplikace – nebo jestli naopak databáze je něco primárního a trvalého, zatímco aplikace je pomíjivá (můžeš ji třeba po roce zahodit a napsat novou, nebo jich provozovat víc najednou, kdežto databáze je pořád stejná, resp. vyvíjí evolučně).

_{[1] asi nejblíž k tomu mají právě uložené procedury v SQL databázi}

[Bystroushaak]

O nebezpečí „SQL injection“ se ví už hodně dlouho a bylo o tom napsáno nespočet varovných článků, takže jestli to někdo dosud nepochopil a nedokázal se s tím vyrovnat, tak bude mít patrně i jiné a mnohem vážnější problémy.

Jo, přesto se čas od času vyskytne i u hodně velkých společností, kde by člověk čekal profesionální programátory.

Můžeš poradit nějaké prostředí, kde je přechod mezi daty uloženými persistentně (na disku) nebo v nějakém externím zdroji (typicky síť) a daty načtenými v aktuální paměti úplně bezešvý?

Poslední dobou si hraju s pythonní ZODB, resp. ZEO clusterem. Pak taky se smalltalkem, kde by přesně tohle měl dělat gemstone, ale zatím jsem se k němu ještě nedostal.

Se ZEO to je bezešvé, ale dá chvíli zabrat to rozchodit tak jak to má být (například nepoužívat vlastní datové struktury (slovníky typicky), ale jen ty ze ZODB).

Taky je to trochu otázka perspektivy – jestli je pro tebe databáze nějaké nedůležité odkladiště dat a nutné zlo, zatímco primární je aplikace – nebo jestli naopak databáze je něco primárního a trvalého, zatímco aplikace je pomíjivá (můžeš ji třeba po roce zahodit a napsat novou, nebo jich provozovat víc najednou, kdežto databáze je pořád stejná, resp. vyvíjí evolučně).

Oboje zároveň - jako nutné zlo mi přijde SQL, tedy pokud s ním mám pracovat. Nevadí mi, že běží někde na pozadí a uznávám, že má pár výhod, jen mě to prostě programátorsky nebaví.

[Jendа]

Další možnost je C s bound-checking. Umí to GCC 5 a procesory od Intelu které přijdou tento rok. (nechápu proč to někdo neudělal dřív, je přece 2015, sakra!)

[johniez]

Starsi gcc umi aspon address sanitizer (pripadne memory sanitizer).

[Kvakor]

Ono často úplně stačí nepoužívat nebezpečné funkce (jako místo sprintf() používat snprintf(), místo strcpy() používat strncpy() a podobně), případbně alokovat datové struktury, do kterých se vkládají data z "vnějšího světa", někde jinde než na zásobníku.

BTW: První pokus o bound-checking přímo procesorem byl už v proceroru i80286, kde instrukce BOUND testovala registr vůči dvojici hodnot uložených v paměti. Bohužel Inteláci tuto na první pohled rozumnou instrukci naprosto zabili tím, že místo nastavení příznaků generuje při překročení mezí vyjímku (konkrétně číslo 5) a navíc dává do zásobníku adresu intrukce vyvolávající vyjímku a ne až té následující (stejně jako třeba u chybné instrukce). Tudíž je naprosto nepoužitelná pro uživatelské procesy, které nemohou sahat do IDT a nastavovat si vektory na vlastní obsluhu, a i pro systém je vyjímka a její obsluha zbytečná zátěž.

[JZD]

Příloha:

• nastaveni174.png (78805 bytů)

Koukám, že nikomu nevadí jak text (CVE-2015-{1538,1539,3824,3826,3827,3828,3829}) nějak moc přetejká do ostatního textu.

[Václav "Darm" Novák]

Příloha:

• abcl.png (62318 bytů)

Nevadí. Screenshot je firefox, chromium i qtwebkit prohlížeče (tam testováno s defaultním css) taky v pohodě…

[kapo]

Já mám FF a přetejká mi to stejně, jak JZD. Default CSS.

[Václav "Darm" Novák]

Zvláštní. Odhlásil jsem se kvůli default css a „works for me“. Jaká verze?

[Jendа]

Nemohlo by nastavení lámání záležet spíš na locales?

[Václav "Darm" Novák]

Nějak mě bohové ví proč nenapadlo že locales tohle taky řeší… Mám en_US.

[kapo]

Mno hlavně u Tvého screenshotu to taky není zalomené. Jen prostě máš menší písmo, tak se Ti to do toho sloupečku vleze, kdežto minimálně mně ne.

Locale mám cs_CZ, FF 31.0.

[Václav "Darm" Novák]

U původního screenshotu se to neláme vůbec, u mě za 2015- a seznam se vejde, u Jaduse taky za 2015-, ale nevejde se mu tam ten seznam čísel (ono by stačilo doplnit mezery kde mají být a je po problémech)

[noo]

Příloha:

• pretejka.png (30131 bytů)

Taky přetejká. Firefox

[Jendа]

Nevadí, levý sloupec má skrytý a zprávičky čte přes RSS :)