Vlákno názorů k článku
Kolem 70 % vážných bezpečnostních chyb v Chromiu jsou chyby používání paměti od Uncaught ReferenceError: - je smutný, že jazyk (c/c++), na kterém jsem...

je smutný, že jazyk (c/c++), na kterém jsem vyrostl nezadržitelně umírá, sestupnou tendenci lze pozorovat dlouho. V součastnosti je jen pár zkušených týmů, kteří jsou schopni psát kód bezpečně a je to příliš drahé, učící křivka příliš dlouhá.

[Tomas2]
Podle me jej zabiji zmlsanost a urcita ... hmmm zlenivelost pochazejici z vyssich jazyku - vyhoda pro me, nevyhoda pro C++. Ale myslim, ze jeste dlouho (mozna vzdycky) budou existovat obory, kde bude vyhodnejsi sahnout po C/C++. Ale tak jako tak je to velka skoda.

V čem je to škoda? Očividně je to fabrika na chyby a desítky let snah s tím nic neudělaly. Čas jít jinam... Byl už dávno.

[Ondra Satai nekola]
Ty si bez kam chces, ja u C++ zustavam, lepsi jazyk podle/pro me zatim vymyslen nebyl.

Jak na co...

Každopádně by mne fakt zajímalo, kolik jazyků jsi potkal.

No neviem, ale ja osobne radšej používam C/C++ než Javu, C#, a iné podobné jazyky... môj list jazykov je:

1. JavaScript
2/3. C/C++
2/3. Golang
(stále sa neviem rozhodnúť medzi nimi v poradí v rebríčku)
4. Python
5. Raku
6. ERLang
.
.
.
X. ostatné jazyky

a tiež sa mi nepáči jak to C/C++ začína ísť do kytek.

25. 5. 2020, 19:10 editováno autorem komentáře

[Mlocik97]
Naopak, me velmi tesi, ze porad existuji lide, kteri jeste na C/C++ nezanevreli.

#include<iostream>

int main( int argc, char **argv )
{
  std::cout << "C++ is really best" << std::endl;
  return 0;
}

Ten nešťastný příklad s přetíženým << tomu nasadil korunu!

Roste tlak na cenu, to je celé. Dnes existují dobré jazyky s vyšším množstvím dokončené práce za jednotku času, tak se přirozeně dostávají do popředí tam, kde to je možné. GUI aplikace, kde se iteruje velkou rychlostí, kde se požadavky mění několikrát do roka, kde chyba nemá závažné důsledky (prostě se to v příští verzi opraví)... tam je na dnešní dobu jazyk jako C moc drahý.

V mém oboru (embedded)... je C pořád #1, a ještě velmi dlouho bude. Je to lehká abstrakce nad dnešními procesory, proto je to ideální jazyk k vývoji kernelů operačních systémů, firmwaru a dalších programů, které mají blízko k železu.

bezpečnost a cena spolu souvisí, chyby stojí peníze.

tlak na cenu byl vždy, ale neexistovaly bezpečné a současně rychlé jazyky jako Rust

26. 5. 2020, 08:42 editováno autorem komentáře

Chyby stojí peníze (reputaci) jen když koncový uživatel není pasivní a tolerantní ovce. A to my jsme. Stačí se podívat třeba na současnou Android scénu. Ani nejvyšší cenová není bez ochromujících chyb, a to i hardwarových... ale my si stejně koupíme za rok další. Překvapivě rychle se smíříme s různými obezličkami (třeba že foťák se spouští až napodruhé, že po posledním updatu vydrží baterie jen jeden den, ...) i u zařízení za skoro 30 tisíc, a tak má výrobce zpětnou vazbu maximálně v podobě nějakého rantu někde v diskuzi.

Aplikace pro nekonečně tolerantní ovce se dneska nedělají v C++. Výjimkou jsou hry, kde se C++ používá především proto, že enginy, frameworky a další nástroje už jsou pro C++, a také proto, že začít používat úplně nový jazyk by představovalo riziko, které žádný projektový manažer logicky (a správně) nechce podstoupit v kontextu, kde vývoj produktu stojí obrovské peníze a jeho komerční životnost, během které se musí investice vyplatit, je potenciálně v řádu několika měsíců.

Klientské aplikace jsou jen malá část SW a i tam mohou chyby způsobit velké škody. Ne všechny chyby způsobí jen pád aplikace, mohou způsobit únik dat, vyřazení služby, poškození dat, zápis škodlivých dat.

Je to smutné z nostalgických důvodů, nebo proto, že se software zhoršuje? Řekl bych, že je to spíš to první. Jako parní lokomotivy – mají své nezastupitelné místo v historii, je krásné se s ní jednou za rok projet na výletě z dětmi, ale dojíždět tím každý den do práce bych nechtěl.

Jo, to je fakt super, ze server bez ochrany pameti zbuchne cely kvuli chybe nejake prilinkovane knihovny.

Zrovna na tom novellu to byla prevelika krasa, kdyz se na tom pokouselo prozozovat Apache.

Este lepsi ovsem bylo, kdyz si clovek vyrazil pakl dernych stitku, s tim zasel do datacentra, sjel derne stitky, precetl si chybu a druhy den sel iterovat znova.

[Filip Jirsak]

Reknete mi Filipe, kdo bude tu Lokomotivu povazovat za zastaralou a nepouzitelnou? Vy ktery milujete svistot svho Pendolina, nebo ja, ktery tou lokomotivou stahuji z celeho okresu vsechny nakladky dreva?

Parni lokomotivu bude povazovat za zastaralou clovek, ktery by rad vyssi ucinnost nez 10%.

A C++ povazuje za zastaraly clovek, ktery ma rad ochranu pameti ve stylu Rustu.

[Youda]
Takze to mam chapat, tak ze jedna jedina vlastnost - zde dejme tomu automatizace zpravy pameti - je ten hlavni faktor pro urceni zda je jazyk moderni a pouzitelny? A vsechny ostatni vlastnosti jazyka(/u) jsou naprosto nepodstatne? A napadlo vas, ze to co konkretne Vy povazujete za zastarale, neuzitecne, potencionalne nebezpecne, popripade nehodne tohop aby jste s tim stracel Vas drahoceny cas, nekdo jiny muze povazovat prave za velmi uzitecnou vlastnost, ba mozna je velmi rad, ze spravu pameti ma ve svych rukou?

Kdo v C/C++ umí psát opravdu bezpečně? A tím nemyslím jednoduchou aplikaci o 10K řádků, ale něco rozsahu srovnatelného s Chromiem, které má v C+C++ přes 14M řádků, když nepočítám komentáře a prázdné řádky: https://www.openhub.net/p/chrome/analyses/latest/languages_summary

25. 5. 2020, 22:57 editováno autorem komentáře

Zajimava otazka a jestli mohu, zeptam se z jineho uhlu: Existuje vubec jazyk, v nemz lze psat naprosto bezpecne a neprustrelne JAKYKOLIV rozsahly projekt?

Kdyz nad tim uvazuji, asi bych - za sebe - odpovedel, ze to neni vubec otazka jazyka jako takoveho. Podle me jsou tri hlavni faktory ktere to ovlivnuji:
1) Ucel vysledneho produktu
2) Rozsah a komplexnost
3) Navrh
Hodne to zjednodusuji a uvedomuji si, ze o tom se napsalo tuny obsahlych odbornych pojednani, ale myslim, ze pro ilustraci to staci. Napr o mame tu chrome a naproti tomu dejme tomu Kate (vubec netusim jak moc je rozsahly, ale dovolim si do toho zapocitat KDE Libs a Qt a je z toho moloch ja krava). Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?

Takže jste asi viděl nějaké zranitelnosti v PHP skriptech, a přišlo Vám jich hodně. Může být. Ale víte, jak by to dopadlo, kdyby PHP byl memory-unsafe?

[J ouda]
Ano, ja to vidim podobne.

Jistě hraje roli spousta věcí a technicky vzato zranitelnost může obsahovat i celkem jednoduchý vzoreček v Excelu.

Nicméně C/C++ má ve srovnání s mnohými jazyky o celou třídu potenciálních zranitelností víc, a podle této zprávičky to není jen teoretický problém.

Ano, MLoC je jen orientační metrika, záleží na spoustě dalších věcí. Budu jako příklad brát i jiné kusy softwaru, které jsou dostatečně rozsáhlé (možná ne nutně jako Chromuim, ale neměl by to být softwarevyvinutelný jako one-man-show) a dostatečně interagují s rizikovým okolím. Myslím, že Kate až tolik neinteraguje s nebezpečným okolím. Analogicky by šlo udělat rozsáhnou aplikaci, která se ale nějak obejde bez dynamické alokace paměti. Tam taky neuděláte use-after-free.

A pokud se bavíme o reálném zneužití zranitelnosti a nejen o její přítomnosti, vstupuje tu do hry i další faktor. Jak moc se aplikace reálně používá s potenciálně nebezpečným vstupem. Prohlížeč běžně. Textový editor teoreticky můžete, ale na vývoj tím můžete otevírat třeba i jen svoje důvěryhodné soubory. Takže třeba https://github.com/vim/vim/commit/d0b5138ba4bccff8a744c99836041ef6322ed39a#commitcomment-19938002 dost možná prošla bez zneužití, ve webovém prohlížeči nebo v serverovém softwaru by podobná chyba mohla vyústit v hromadné útoky. A běžný franta uživatel si pokročilejší editor plaintextu ani nebude instalovat. Software pak může být napsán řádově hůře, a přitom se případné zranitelnosti nebudou až tolik zneužívat. A nejspíš se nebudou ani tolik hledat, takže statistiky objevených zranitelností mohou u podstatně hůře napsaného softwaru vypadat lépe.

Prakticky vzato: Pokud se takovéto programátory nepodařilo sehnat Googlu v dostatečném množství a přes všechna ta opatření završená jejich štědrým Vulnerability Reward Programem*, nedá se moc čekat, že se těmto problémům vyhnu výběrem dobrých programátorů.

*) VRP typicky nebývá to úplně první opatření. Jinak by to byl celkem drahý pronájem různých (i volně dostupných) automatizovaných nástrojů, zvlášť u open-source. Ostatně Google z VRP paušálně vylučuje (nebo aspoň vylučoval) nedávné akvizice.

[Vit Sestak]

Dekuji za reakci, Ja si myslim, ze to vidime oba velice podobne. Az na to, cemu dame ten finalni vyznam, dokonce souhlasim i s Vasim zaverem. Rozdil je jen v tom, ze osobne bych necekal ze pri slozitosti a ucelu Chrome dosahnou o moc lepsich vysledku pouhym pouzitim jineho jazyka v projektu.

Myslenka s Kate je v tom, ze si myslim, ze ona neduvera v C++ je dana hlavne tim, co se v psychologii naziva survivorship Bias (zkresleni prazivsich) V nasem pripade jde o to, ze budeme prirazovat vetsi vyznam projektum, u kterych se chyby nasli a projekty ktere bezi bezproblemove (a ja ale netvrdim, ze tam chyby byt nemohou) vicemene nikoho v tomto hledisku nezajimaji a tak se jevi, ze psani rozsahlych projektu v C++ zakonite vede k chybovosti, nebo rovnou k realne zneuzitelnym zranitelnostem. Protoze ty ostatni jsou ignorovany.

A obavam se ze to neni otazka jen C++, ale v podstate jakehokoliv Jazyka. A taky toho, ktery jazyk mi je sympatictejsi.

Zajimava otazka a jestli mohu, zeptam se z jineho uhlu: Existuje vubec jazyk, v nemz lze psat naprosto bezpecne a neprustrelne JAKYKOLIV rozsahly projekt?
Původní důležitou otázku jste posunul do nesmyslu. Samozřejmě dává smysl používat jazyky, ve kterých lze psát bezpečněji. To, že to stále není naprosto bezpečné a neprůstřelné je sice škoda, ale je to pořád lepší, než psát v jazycích, které jsou k těm chybám náchylnější.

Podle me jsou tri hlavni faktory ktere to ovlivnuji
Můžete mít pět aplikací, které budou mít tyhle tři faktory stejné, ale každá aplikace bude napsaná v jiném jazyce. Dává smysl jazyky porovnávat podle toho, která aplikace bude nejbezpečnější. Stejně jako dává smysl je porovnávat podle toho, která bude nejrychleji napsaná, která nejsnáze udržovatelná, která bude mít nejmenší nároky na hardware tak, aby měla použitelnou odezvu.

Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?
To ovšem vůbec nevypovídá o tom, zda tam bezpečnostní chyby jsou nebo nejsou. Může to vypovídat jenom o tom, jaká je příležitost je zneužít. Také jsem nikdy neslyšel o tom, že by někdo vyloupil vlakové nádraží, zatímco vyloupení banky je oproti tomu častý jev. Ale vůbec to neznamená, že jsou nádraží lépe zabezpečená, než banky.

[Filip Jirsak]
"Původní důležitou otázku jste posunul do nesmyslu. Samozřejmě dává smysl používat jazyky, ve kterých lze psát bezpečněji. To, že to stále není naprosto bezpečné a neprůstřelné je sice škoda, ale je to pořád lepší, než psát v jazycích, které jsou k těm chybám náchylnější."

Obavam se, ze ja jsem v teto chvili vubec predrecnika neptal na to co dava smysl ci ne. Ja jsem se ptal, zda existuje realne jazyk, v nemz se daji bezpecne a bezchybne psat velke komplexni projekty. O smyslu tam v tuto chvili nebylo ani slovo.

Hlavně existují jazyky, kde se spousta věcí řeší daleko méně ceremoniálně. Nejsem žádný velký programátor, ale něco málo C, Javy, Pythonu apod. jsem viděl v různých kontextech.
Od nějaké velikosti projektu stejně už nikdo neví, co se skutečně děje a jaké instrukce se procesoru pošlou (natož v jakém pořadí se potom skutečně vykonají, a po zkušenosti Meltdown apod. se zdá, že to relevantní je). Je tedy příležitost zvolit vyšší, robustní a hlavně konzistentní abstrakce a nechat vnitřnosti nějakému chytrému AOT/ JIT kompileru. V poslední době se zabývám ve volných chvílích Clojure a Clojurescriptem, protože mám možnost nahlédnout do projektu (https://orgpad.com/about), který je napsaný výhradně v této kombinaci. Kdybych viděl Clojure před Javou, tak se Javou nebudu zabývat, protože prakticky všechno, co umí Java umí Clojure taky a velmi často stručněji, konzistentněji a s poměrně malou námahou se dá leccos sdílet mezi Clojure a Clojurescriptem - takže Client a Server můžou sdílet dost kódu. Ano, na pár věcí se hodí vědět, jak to JVM a jiné VM nad kterými nějaký dialekt Clojure beží implementují, třeba když chcete mluvit s nějakou C knihovnou z Clojure. Tam potom koukáte na věci typu JNI, JNR apod. Na většinu běžných úkolů, kdy taháte nějaká data z databáze, máte nějakou logiku a komunikaci Client-Server, tam se s přednostmi Clojure/ Clojurescript kombinace dost špatně drží krok.

V moderním C++ se dá psát na velice vysoké úrovni abstrakce, řekl bych i v porovnání s Rustem, můžete skrýt některé detaily.

JIT kompilery se ukázaly jako slepá cesta. Podle mě se od nich ustupuje.

26. 5. 2020, 12:09 editováno autorem komentáře

"Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?"

Nevím, já jsem ještě neslyšel, že by byla použita Kate. Zneužití díry je až o level výš.

Tohle je lichý argument. Možná někomu dělá dobře, že sám sebe ujišťuje, jaký je l33t R3aL Pr0gr4mm3rZ, ale uživateli i zadavateli je to srdečně jedno - a pokud není, měl by se snažit dospět nebo případně se obrátit na psychiatra. V praxi je u softwaru důležitých pět věcí (v náhodném pořadí): výkon, cena, bezpečnost, featury, uživatelská přívětivost. Dejme tomu, že přívětivost nezáleží na použitém jazyku (o tom se dá diskutovat, ale budiž). Z hlediska vyvinutých featur za nejnižší cenu nemá C++ šanci proti Pythonu, Go a podobně. Z hlediska výkonu zaostává za C, Fortranem a Rustem. Z hlediska bezpečnosti je důležitá prokazatelnost, ne jenom ujišťování a ego, a v tom je C++ absolutní katastrofa, tady vede Rust, Ada a Haskell. C++ má dosud své nezastupitelné místo díky tomu, že pro něj existuje mnohem víc nástrojů, než pro objektivně lepší jazyky, podporuje víc cílových platforem a mnohem víc lidí s ním umí. To ale neznamená, že by neměl být tlak na jeho postupné opouštění. Tvrzení že "dobrý programátor" dokáže napsat dobrý kód i v C++ je na stejné úrovní, jako že "dobrý řidič" dokáže jet i s autem s prasklými pneumatikami a které nemá brzdy. U mě to spíš vyvolává pocit, že takový "programátor" až tak dobrý není, když ani nedokáže pochopit, jak velká výhoda je, když někdo vyrobí auto, které stojí polovinu a jezdí zadarmo nebo vymyslí nezničitelné pneumatiky.

Neříkám, že můj styl je geniální, ale problémy v C++ fakt nemám a píšu podle mne bezpečně

Například burzovní robot

https://github.com/ondra-novak/mmbot

Což je prakticky one-man show. Na tak malém projektu může být celkem jednoduchá a predikovatelná alokace/dealokace paměti. Oproti prohlížeči, kde máte celkem komplexní webovou stránku ovládanou javascriptem, je to neporovnatelný rozsah. Ostatně si můžete všimnout, že polovina těch chyb s pamětí tvoří use-after-free. To není primitivní implementační chyba jako buffer overflow, to prostě znamená, že někdo někde zapomněl pointer po dealokaci a dál ho používal. Což se v tak rozsáhlé aplikaci (řádově rozsáhlejší než váš bot) hlídá poměrně těžko.

Škoda, že Google nezmiňuje více o té druhé polovině chyb práce s pamětí. Možná v tom budou i jednodušší implementační chyby jako buffer overflow – tipoval bych, že spíše staršího data a nejspíš ne úplně učebnicové případy, které by zachytila statická analýza.

Jenže Vaše prohlášení "podle mne je to bezpečné" je maximum, čeho je v C++ teoreticky možné dosáhnout, a to prostě nestačí.

V tom je právě ten problém, každý si myslí, že píše bezpečně a nelze to jinak posoudit než důvěrou v tazatele, to je málo.

Pokud se podívám na tvůj kód, hodně zpozorním, máš tam spousty fixe-sized array, u kterých nekontroluješ přetečení, stačí malá nepozornost a právě problém, o kterém je článek, je na světě.

Tenhle kód při parsování jsonu je zranitelný na buffer overflow, https://github.com/ondra-novak/mmbot/blob/master/src/brokers/httpjson.cpp#L61-L68, možná pro tvoje účely to je OK, u chromium by to byla kardinální chyba.

Poté používáš funkce jako sprintf (https://github.com/ondra-novak/mmbot/blob/master/src/trainer/main.cpp#L884) nebo sscanf (https://github.com/ondra-novak/mmbot/blob/master/src/brokers/isotime.h#L26) bez ošetření buffer overflow. Jasně v tomhle kódu to je třeba teď bezpečné, ale za nějakou dobu tam někdo udělá jinou úpravu a bezpečnostní chyba je na světě (podvrhnout chybný čas aplikaci lze třeba relativně dobře). Tyhle věci musíš automaticky ošetřovat a nespoléhat, že je někdo jiný použije dobře.

Na řádkách L61-L68 buffer overflow není. Data se cpou o ostringstreamu a limitem je maximalne velikost paměti - cpou se po blocich

Použití sprintf a sscanf by se dalo jistě nahradit lepším řešením, ale v daném kontextu ano bylo rychlejší pro implementaci a i troufnu si říct i pro performance.

Se závěrem nesouhlasím. Pokud někdo přebírá kód formou copy&paste - je zodpovědný za jeho obsah, jako by ho napsal sám, svými prsty.

Pokud jej přebírá jako knihovnu, je zodpovědnost na autorovi knihovny. Také je potřeba, aby dotyčný definoval kde se knihovna hodí - stejně jako si koupíte v reálném obchodě zařízení, taky je napsáno, že se nesmí používat tu a tam a že je k úrčitému účelu.

Nespoléhal bych se slepě na překladač s tím, že musí zaručit bezpečnost. Nemusí. Pokud tomu půjde naproti bezva, ale nemusí.

C/C++ může stále mít význam, pokud chci napsat něco pekelně rychlého, ale na bezpečnosti mi nezáleží -- třeba fyzikální simulaci pro interní použití. V takovém případě si člověk rád ušetří dodatečný overhead bezpečnějších jazyků typu Rust, ať už v nárocích na vývojáře (boj s borrow checkerem), tak potenciálně runtime overhead (zrovna u Rustu obecně moc není, ale třeba u jazyků postavených na VM).

Jazyk je jenom nástroj. Nemá žádnou citovou ani kulturní hodnotu, stejně jako ji nemá šroubovák. C má dosud své místo a své výhody, C++ byl odjakživa hrozný paskvil. Doopravdy neumře nikdy stejně jako neumře COBOL, ale jak se člověk jednou zbaví Baby Duck Syndromu a ocení výhody modernějších jazyků (v případě C++ tou modernější náhradou může být D, Rust, případně C# nebo i Python, podle typu aplikace), už je návrat k C++ těžko představitelný.