Názory k článku Chyby v programovacích jazycích ohrožují bezpečnost aplikací

výpis zdrojáku u dobreho programu nicemu nevadi, v opacnem pripade by bylo nebezpecne cele open source

nejvěrohodnější příklad je až napadená aplikace :). Spoléhat na to, že útočník není chytřejší než já není opravdu dobrý nápad.

Ano, žádná z těch chyb by se nedala v dobře nastaveném systému a dobře napsané aplikaci zneužít, ale v praxi ty systémy jsou v takovém stavu, že i tahle drobnost stačí k velkým problémům. Většina systémů je provozována s výchozí konfigurací z distribucí/balíčků.

Souhlas, že je kolem toho zbytečné halo a stejně tak souhlasím, že většina těch chyb jsou drobnosti i za mě. Donutit aplikaci k pádu ale považuji za kritický problém.

Ano, dát uživatelský vstup do require je extrémní blbost, ale ve složitější aplikaci se může útočníkovi podařit do require propašovat svůj vstup díky naprosto jiné elementární chybě a máš problém. Za mě by require neměl načítat obsah souboru pokud to není validní js, dříve to node.js nedělal (očekávám, že to je chyba z node.js).

To je dost obecny prohlaseni - zase priklad s C - tam s spatnym vstupem spadne 99% funkci ? budeme rikat, ze C je derave? Urcite ne.

Ano :). Problém v C není ani tak v tom, že by funkce (definovaně) spadla, ale že spousta věcí vede na UNDEFINDED BEHAVIOUR. Tohle hlavně vede na security issues. Samozřejmě z toho lze vždy vinit programátora, on udělal chybu, takže je za to zodpovědný, ale je to alibistický přístup. Lidé prostě chyby dělají a dělat budou. Přitom stačí dost málo, nepoužívat C, ale něco modernějšího, třeba Rust, to by situaci dost vylepšilo.

Takže si to shrneme.

C je silně unsafe jazyk. Používá se hlavně z historických důvodů, protože nic lepšího nebylo. Přepisovat velké existující věci do Rustu se nebudou, protože by to stálo spoustu peněz, které nikdo nezaplatí. C bude existovat ještě hodně dlouho, stejně jako třeba COBOL. To ale neznamená, že je C nějak dobré a vhodné. Naopak, C veškerou zodpovědnost za bezpečnost kódu přenáší na programátora.

Rust je výkonem na úrovni C (ve skutečnosti je to aktuálně asi 90% rychlosti C). Velkou část unsafe věcí z C řeší a eliminuje všechny bezpečností chyby typu buffer ovetflow, use after free apod (a že je jich opravdu dost...). Jenom hlupák by na novou aplikaci, která řeší bezpečnost, vybral C místo Rustu. Pokud chceš být hlupákem, tvoje volba.

Jako trolling je to ale od tebe slabé.

Porovnání výkonu je vždycky zavádějící, jsou úlohy, ve kterých je rychlejší Rust než C, průměrně to vychází víceméně jako plichta: https://benchmarksgame.alioth.debian.org/u64q/rust.html

Nesnažím se tě přesvědčit o ničem, jenom vyvracím tvoje nesmysly o tom, že by se projekty, kde jde o bezpečnost, měly psát v C a že za všechno může programátor. To je opravdu hloupé, protože Rust je oproti C lepší snad úplně ve všem a dává bezpečnostní garance, které C nikdy dávat nebude. Většinu bezpešnostních chyb (chyb programátora) Rust chytí už při kompilaci, vůbec se to nepřeloží. Smiř se s tím, že C je zastaralé a nesplňuje požadavky na bezpečný programovací jazyk.

Na vytvoření enkoderu se nehodí ani C. Enkodery H265 se dělají na specializovaném hardware. Je vidět, že nemáš moc přehled.

Co je na něm unsafe? Prostě si jenom nehlídá meze polí, nehlídá přetečení integer operací, má chabrus typový systém, některý věci jsou o kompromisu mezi bezpečností a čistým kódem, ale jinak až na pár drobností typu implicitní přetypování čehokoliv na int je celkem v pohodě...

Pokud se teda do toho nevloží někdo, kdo píše stylem

if(a == TRUE) ...


Do toho seznamu si taky přidej, že C ještě nehlídá validitu pointeru a obecně přístup do paměti. Chyby typu:

free(pointer);
...
tyhle_data_ted_pos­lu_klientovi_po_si­ti(pointer, delka);

Jsou opravdu zábavné, někdy získají takovou publicitu, že o nic píšou i na novinkách: https://www.novinky.cz/internet-a-pc/332872-sifrovaci-knihovna-openssl-ma-zavaznou-bezpecnostni-chybu.html

Rust tohle řeší, takový chybný kód se ani nezkompiluje a přitom Rust nepřidává žádný runtime overhead navíc oproti C.

jen šťouravá otázka, pokud se programátor v C dopouští takových chyb neukazuje to spíše na jeho nekázeň a špatné kontrolní procesy (třeba si sám autor svůj kód neprochází a dostatečně netestuje)? Jak velká šance existuje, že se bude dopouštět fatálních chyb i v rustu?

Nezpochybňuji výhody rustu, zpochybňuji, že to zabrání chybám, programátoři jsou velice nápadití a najdou si jiné způsoby jak nám rozbíjet naše čisté programy :).

Takové chyby se objevují ve všech projektech, které jsou psané v C. Včetně linuxového kernelu, openssl a podobných kritických projektů, které dělají zkušení programátoři a mají zavedené code review. Přesto se i tam bezpečnostní chyby objevují stále. Není v lidských silách ohlídat všechno, komplexnost software je už příliš vysoká na to, aby člověk dokázal domyslet všechny důsledky.

Rust řeší největší slabinu C, což je unsafe memory managenent, který vede na ty nejhorší bezpečnostní chyby (remote code execution, information exposure...). Ani Rust ale nedokáže zabránit všemu a nikdo se to ani nesnaží tvrdit, pokud programátor načte z disku privátní klíč a pošle ho klientovi, tak je úplně jedno, v čem to napíše a bude to průšvih. Nicméně Rust dokáže zabránit všem chybám, které vznikají z nesprávného přístupu k paměti. A dokáže to bez nějakých runtime režií navíc.

chyby v C, které zmiňuješ nejsou o komplexnosti, ale o elementárních a těžko odhalitelných chybách. Problémy v komplexnosti budou i v Rustu.

Nepřu se s tebou o výhodách rustu. Raději bych viděl fungující SW vývoj nad C a poté přechod na rust než se snažit problémy ve vývoji záplatovat rustem, s velkou pravděpodobností povedou k jiným chybám i v rustu.

Tomáš2: Pokud jsem pochopil, tak Rust opravdu spoustu typů chyb nepřipustí. Ale např. za cenu toho, že neuděláš obousměrný seznam. A pokud uděláš, tak (minimálně) jeden ze směrů je obdobně unsafe, stejně jako by to bylo C. To byl jen příklad už mírně složitější komplexní struktury. Nemyslím konkrétně jen toto. Nevýhoda Rust je, že pokud máš zůstat v safe oblasti, tak v principu tam některé konstrukce neuděláš. Celý návrh musíš koncipovat jinak. Což někdy, jede-li člověk low level (a někdy ani to netřeba), buď vůbec nejde, anebo za vysokou cenu (čas, paměť. náročnost, ...)

Takže chyby zanesené do Rust budou např. i takové, které vzniknou z nižších úrovní (psaných nižších jazycích) za použití unsafe volání, které na určité úrovni prostě vznikne, protože čistým Rustem neřešitelné.

Jenom se zeptám, kdy naposledy jsi měl potřebu implementovat ručně obousměrný seznam a nepoužil na to radši knihovnu? Já se přiznám, že nikdy, vždycky jsem vzal knihovnu.

Obousměrný seznam jde v safe Rustu udělat, ale není to moc elegantní a má to svoje nevýhody: http://cglab.ca/~abeinges/blah/too-many-lists/book/fourth-final.html
Doporučuju přečíst i to před tím.

Prakticky je lepší vzít knihovnu, ve které to nějaké to unsafe bude, ale s vysokou pravděpodobností bude to usafe udělané správně. V user space kódu pak žádné usafe není.

Mýliš se, chyby které zmiňuji, jsou o komplexnosti. V C je například obtížné udržet informaci o validitě pointeru. Např. pokus o smart pointer v čistém C s počítáním refcountu je dost na hlavu, musíš stále myslet na to, kdy refcount zvýšit a snížit a jakákoliv opomenutí vede k těžko ohalitelným chybám. Druhá kategorie jsou data races v multithread aplikacích, tohle je taky hodně obtížné udělat správně a stále se v tom dělají chyby (i ti nejlepší programátoři...).

Rust tohle všechno řeší už při kompilaci, pokud takovou chybu uděláš, program se vůbec nezkompiluje.

A ještě jedna věc, Rust není o nějakém záplatování chyb. Rust nabízí mnohem vyšší míru abstrakce než C, např. má i generika. Vývoj v C bude pomalejší a dražší než v Rustu a výsledek bude horší.

no zrovna refcount je příklad, kdy je velice komplexní takovou chybu najít, ale není to důsledek komplexnosti aplikace, ale absence chytřejšího memory managementu a nedůslednosti programátorů, špatném způsobu testování.

Argument s race condition uznávám, mutex není řešení a bojume s tím i v jiných jazycích, dokonce i v rustu (sic), ne v samotném kódu aplikace, ale v její interakcí mezi více nody v clusteru, s databází či při load balancing a hodně vysoké frekvenci volání update procedur. A o tom mluvím, pokud programátor udělá race condition chybu v C, je velká šance, že stejnou chybu udělá i na vyšší úrovni aplikace v rustu. Já jdu raději cestou naučení programátorů jak tyhle chyby hledat, na co si dávat pozor, co kontrolovat, jak k problémů přistupovat, jaké jiné algoritmy mohou použít, vede to daleko k méně chybám než bylo dosaženo výměnou jazyka.

Tou záplatou jsem nemyslel způsob jak je rust udělaný, ale ta samotná výměna jazyka a spolehnutí na to, že tyhle chyby zmizí.

V jednom oddělení jedné analytické/datové spolešnosti se přešlo na rust (původně většina věcí byla v C/C++, Python, Scala), teď už většina nových věcí je v rustu (volba samotných programátorů, nikdo je k tomu nenutil, jen se dala ta možnost). K odstranění řadě chyb v aplikacích ale nedošlo, jen se přesunuly na jinou úroveň a ty programátoři stejně dělaly chyby, výrazně pomohlo až školení, mentoring, párové programování či lepší komunikace v týmu a poučení se z chyb.

Ze své zkušenosti bych subjektivně řekl, že většina chyb není z nepozornosti ale z neznalosti (ať už jsem na nějakou věc zapomněl nebo jí vůbec neznám).

Pointa je v tom, že Rust nabízí mnohem vyšší míru abstrakce než C. V Rustu nemusím refcount vůbec řešit, použiju Rc<T> a všechno za mě udělá překladač/knihovna. Takže nemusím hledat chybu ve špatné inkrementaci/de­krementaci refcountu, nemůže to nastat. Režie navíc oproti ručnímu řešení v C je nulová.

Jen pro upřesnění, Rust nedokáže obecně zabránit race conditions, např. lze v Rustu vyrobit deadlock špatným zamykáním mutexů. Rust ale dokáže zabrátnit data races, což znamená nekorektní přístup k datům z více threadů (např. současně zápis i čtení), tohle se chytí už při překladu.

Většina bezpečnostních chyb typu buffer overflow, use after free apod. je z nepozornosti, programátoři dobře vědí, co nemají dělat a stejně to udělají. Tohle Rust dokáže chytit, taková chyba se v Rust programu nemůže vyskytovat, chytí se to už při překladu.

očividně se točíme ve smyčce, ty pořád mluvíš o výhodách rustu, o tom jak to tam je super, já ti řikám, hele, nám to ze zkušenosti stejně ty chyby neodstranilo a vznikly nové, špatný programátor zůstane špatným i v jiném jazyku...

Jej, sorry, psal jsi opravdu o data race a ne o race condition, to ale nemění můj argument, že zrovna tahle chyba přetrvává i v rustu a stejně s tím vznikají problém, i bezpečnostní.

Zažil jsi přechod nějakého většího projektu/týmu na rust? Máš s tím zkušenosti nebo si jen píšeš aplikace sám?

Stále dokola říkám: Rust odstraní všechny chyby, které vznikají špatnou prací s pamětí. Neexistuje buffer overflow, neexistuje use after free, nestane se ti, že útočník přepíše buffer na zásobníku svým kódem. Bavíme se v kontextu bezpečnosti, tady je Rust kosmicky dál než C.

Jestli to někdo pochopil tak, že použitím Rustu mávnutím kouzelného proutku zmizí všechny chyby v software, tak to je samozřejmě nesmysl.

My máme spoustu legacy kódu a dlouhodobé projekty v C++, které nikdo do Rustu přepisovat nebude, nikdo by to nezaplatil. Takže otázka přechodu na Rust u většího projektu u nás nemá smysl. Svoje věci si píšu v Rustu, ale do týmu ho násilně nenutím, ani by to nešlo, nikdo nezahodí miliony řádků kódu v C++ s tím, že od zítřka to bude Rust.

Já mám z vašeho příspěvku pocit, jako by byl Rust nějaký zázrak. Že je to konečně jazyk, u kterého platí "když to jde zkompilovat, tak to funguje!"

Tak samozřejmě není, u Rustu ale narozdíl od C platí: Když to jde zkompilovat, tak tam není nekorektní přístup do paměti, nenastane SEGFAULT a není tam data race.

"Rust, to by situaci dost vylepšilo"
jo, to jiste ... 1e234 ... takovy obycejny ... cislo. Nebo 0xaf31 ... to taky bezne lidi chapou ze je cislo.

Pokud je programator dobytek je uplne jedno v cem to pise.

pro ten jediný bit to rotace přece je :)

a = 0x61 = 0110 0001
A = 0x41 = 0100 0001

SUB AL, 20H <> AND AL, 0DFH