safe funkcie v C (diskuse)

[vlastikroot]

V ankete mi chybi ze M$ je kupa sracu a meli by jit doprdele

[thingie]

Tak, já bych se nebál prostě a jednoduše každý výskyt třeba strcpy označit za [bezpečnostní] chybu. Ne že by to někdy nemohlo být OK a platné, ale obecně vzato to značí problém. :)

[Luk]

Ona to skutečně je bezpečnostní chyba (taktéž třeba to sscanf()). Ale zatímco u gets() se to zdůrazňuje (takže tuto funkci snad už dnes nikdo nepoužívá), celá halda těch zbývajících se vesele používá dál, a to i v tutoriálech pro začátečníky (což je výtečná cesta, jak jejich použití dále upevňovat a prodlužovat, a jak si tedy zadělávat na budoucí záludné problémy v programech).

[rastos]

a) ak to je bezpečnostná chyba, ako písať multiplatformný kód? Čo použiť na Linux-e?
b) čo s existujúcim starým kódom, ktorý treba udržiavať?
c) osobne si nemyslím, že to je chyba(s výnimkou gets()). Len treba vedieť s akými dátami človek pracuje.

[Miloslav Ponkrác]

a) ak to je bezpečnostná chyba, ako písať multiplatformný kód? Čo použiť na Linux-e?

Pokud nejde psát multiplatformní kód jinak, než přímým použitím standardní C knihovny, tak jsem žil celý život ve lži.

[YYY]

Coz

char *strncpy(char *dest, const char *src, size_t n)

?

[Miloslav Ponkrác]

Znovu se ptám, víte co strncpy dělá? Abyste nebyl překvapen!

Jedna z nejhorších bezpečnostních chyb, a kupodivu velmi častých, je použití strncpy Céčkaři, kteří netuší, co ta funkce opravdu dělá.

[kozzi]

No ja bych rekl ze ta funkce opravdu dela to co si mysli. A to ze kopiruje n znaku z jednohe retezce do druheho. Horsi je kdyz clovek nevi jak to dela

[Miloslav Ponkrác]

No jo no

Ona dělá trošku víc, než jenom kopíruje.

A zase při kopírování občas nezkopíruje to, co si ten člověk nahoře myslí.

[YYY]

Pokud tim clovekem nahore myslis mne, tak ja jsem se jen cloveka nade mnou zeptal, coz strncpy.. ? Nic vic, nic min. Nevim, proc z toho odvozovat nejake dalsi soudy.

[YYY]

Vim, co de dala a jak. man strncpy umim napsat

[rastos]

Coz

char *strncpy(char *dest, const char *src, size_t n)

?

strncpy_s,

[Miloslav Ponkrác]

Ona to skutečně je bezpečnostní chyba

Jaká je bezpečnostní chyba v tomto kódu?:

int pokus(const char* src)

{

  if (src == NULL)

    return ERR_NULL_STRING;

 

  size_t src_size = ::std::strlen(src);

  if (src_size > 10)

    return ERR_TOO_LONG_STRING;

 

  char buff[11];

  ::std::strcpy(buff, src);

  // ... dalsi akce ...

 

  return ERR_OK;

}

 

Chci slyšet přesné vysvětlení, jak výše uvedené použití strcpy způsobilo bezpečnostní chybu.

[Luk]

V tomto konkrétním případě tam chyba není. Chyba nastává v těch případech, kdy autor nemá plnou kontrolu nad velikostí dat, se kterými se pracuje. Problém je, že často je to tak, že i když nejprve tu kontrolu má, později program upraví tak, že ji ztratí - a přitom zapomene místo potenciálně nebezpečné funkce použít jinou.

[Miloslav Ponkrác]

Já bych to zobecnil: Každou funkci jde použít chybně, naprosto každou. Takže rizikem je naprosto každá funkce, kterou v programu použijete.

Ale jsou určitá dogmata, která – bez pochopení podstaty samé – se budou papouškovat dokola.

Stejně chybně můžete použít třeba strnprintf – jednoduše do ní třeba napíšete, že buffer má velikost 100 bajtů a později program upravíte na buffer o velikosti 20 bajtů. A máte stejnou bezpečnostní chybu.

Že je to nepravděpodobné? Co tohle:

wchar_t buff[10];

wcsnprintf(buff, sizeof(buff), ...);

A hned máte úplně stejnou bezpečnostní chybu, i se „safe“ funkcí.

Rád bych, aby se přestalo blekotat o nebezpečnosti některých funkcí. Největší bezpečnostní chyby dělá programátor, který má mylný dojem, že některé funkce jsou „bezpečné“, a je celkem jedno, jaké to jsou.

[hanzz]

od doby co je v hodne distribucich SW prekladan s fortify check to zas takovy bezpecnostni problem neni, coz nemeni nic na tom, ze je to stale chyba... jen nasledky nemusi byt tak dramaticke

[deda.jabko]

Tak, já bych se nebál prostě a jednoduše každý výskyt třeba strcpy označit za [bezpečnostní] chybu.

Ona to skutečně je bezpečnostní chyba

muzete mi dolozit, ze kazdy vyskyt strcpy je bezpecnostni chyba?

[Luk]

Každý výskyt ne - viz výše.

[Kvakor]

Také považuju názor "každé strcpy() je chyba" za poněkud extrémní - to, že funkce může být nebezpečná, totiž nutně neznameném že opravdu musí být nebezpečná. Já bych to rozdělil na tři úrovně:

1. Bezpečné ("blbovzdorné")
2. Podmíněne nebezpečné, ale zabezpečitelné kontrolou vstupů (pokud jsou vstupy v pořádku, funkce je bezpečná)
3. Nebezpečné - nejdou nijak zabezpečit a neměli by se vůbec používat

strcpy() patří do druhé skupiny, kdežto klasický připad té třetí je gets(), který nemáme šanci zabezpečit, protože vstup je plně na libovůli uživatele.

[kozzi]

No kazdopadne nas tyto funkce uci (nuti) pouzivat i na vysoke skole. A to ze jsou nebezpecne slysim prvne. Je nekde dobrej clanek, kterej by mi to objasnil?

[#Tom]

V čem spočívá bezpečnostní chyba při použití sscanf nebo scanf? Pokud se tím nenačítá celý řetězec neurčité délky (formátem %s), ale číslice, případně znaky, nemělo by se nic stát.

[Michal Kubeček]

Ona to skutečně je bezpečnostní chyba (taktéž třeba to sscanf()). Ale zatímco u gets() se to zdůrazňuje (takže tuto funkci snad už dnes nikdo nepoužívá), celá halda těch zbývajících se vesele používá dál

Mezi těmi dvěma příklady je ale hodně podstatný rozdíl. Zatímco gets() je opravdu nebezpečná vždy, strcpy() je bezpečnostní chyba jen v případě, že neošetřím, jestli mám dost místo pro to, co kopíruji. Takže jde jen o potenciálně rizikovou funkci, na rozdíl od gets().

[Deleted [8409]]

#if defined(_MSC_VER) && !defined(_CRT_SECURE_NO_WARNINGS)
#define _CRT_SECURE_NO_WARNINGS
#endif // _MSC_VER

[#Tom]

Líbí se mi funkce gets_s, o které v tom PDF píšou, že je lepší místo ní použít raději fgets.

[Semo]

Ja som tie *_s fcie nepochopil, v com su lepsie nez strncpy, snprintf, strncmp a podobne?

[Miloslav Ponkrác]

Mimochodem, pochopil jste vůbec, co dělá funkce strncpy?

Věřte mi, že řada Céčkařů žije v bludu, že ví co skutečně tato funkce dělá.

Víte o tom, že funkce strncpy může zkopírovat string ukončení řetězce koncovou nulou?

[thingie]

No, kdopak nám tady z relativně triviální věci zase dokáže udělat velkou mystickou aféru…

Ta třetí věta nedává česky smysl.

[Miloslav Ponkrác]

Z naprostého prdu dokázal udělat skandální záležitost především autor článku.

A já jsem to tady jenom chtěl trochu rozbít, protože je tu úžasné, jak spousta lidí, co se rozhořčují nad MS netuší, která bije.

Realita je jednoduchá: V jakémkoli low level jazyce můžete nasekat chybu na každém řádku kódu, ať použijete cokoli. Low level jazyk jako je Céčko Vám umožní natlouci si čumák kam se jenom podíváte. Naprosto vše je v něm „potenciálně nebezpečné“, fakticky nulové kontroly, vše musí hlídat programátor a vědět co dělá.

Chcete používat bezpečné funkce? Jak jednoduché! Nepoužívejte Céčko! Zvolte si high level jazyk, který má kontroly a bezpečnost už v jazyce. Nebo si zvolte Adu. Nebo něco podobného. Ale pamatujte si, před Vaší blbostí (případně nezkušeností) Vás neochrání vůbec, ale naprosto nic. I tam jde udělat chybu v algoritmu, dostat se do nekonečné smyčky a řadu jiných věcí.

Céčko je systémový jazyk! Tedy pro ty, kdo chtějí programovat operační systém, nebo kdo chtějí programovat věci na nízké úrovni. Takoví lidé potřebují, a to velmi nutně, jazyk, který jim dovolí všechno – včetně zhroucení počítače, včetně chyb jejich vlastní blbosti a další. Ano, Céčko je nebezpečný jazyk – je v něm potenciálně nebezpečná každá funkce, každý řádek.

A za druhé – všechny safe funkce, co si prosadil Microsoft je schopen běžný programátor naprogramovat za jedno odpoledne. Všechny ty funkce s přídavkem _s v názvu jsou velmi jednoduché k napsání, a dají se nádherně – a multiplatfromně – napsat jako modul nad standardní knihovnou Céčka. Ať už si o MS myslím cokoli, jeho počin není úplně nejhorší, a je za ním dobrá myšlenka.

Stringové funkce v Céčku je totiž něco příšerného. A nejenom příšerného, ale také pomalého, neefektivního, a navíc chyby přitahujícího. Jakýkoli blbý objekt typu string, který napíšu v C++, nebo strukturu, kterou budu emulovat v C objekty a nad ní vystavím pár funkcí – rychlostně, efektivitou i bezpečností překonají všechny funkce strněco v Céčku. I poměrně špatně napsaná STL třída std::string rychlostně trumfne low level práci v Céčku se strněco funkcemi, na komfort a bezpečnost ani nemluvě.

Microsoft měl dobrou ideu – postavit nad nedomyšlenou, neúplnou množinou strněco funkcí v Céčku úplnou množinu funkcí, které navíc jsou schopny kontrolovat délky a rozsahy. Tuto množinu nabídl ISO ke standardizaci, ale byl odmítnut. Protože jejich funkce jsou tisíckrát lepší, než to, co je ve standardní knihovně Céčka, zařadil je tedy do svého kompilátoru a sám je používá. Multiplatformovosti to nebrání – a pokud to někdo tvrdí, měl by si uvědomit, že moc toho ještě neumí. Jsou to jednoduché funkce, které nikterak nezávisí na žádné platformě.

 

 

[rastos]

Z naprostého prdu dokázal udělat skandální záležitost především autor článku.

Uh. To bolo na mňa?

A za druhé – všechny safe funkce, co si prosadil Microsoft je schopen běžný programátor naprogramovat za jedno odpoledne.

To možno. Ale nie som si istý, či si pochopil môj problém:

1. Mám existujúci kód používajúci staré funkcie bez kontrol hraníc. Ak ten kód chcem kompilovať súčasným kompilátorom a knižnicami od MS tak ho musím prekopať a na každé miesto, kde sa robí so stringami dotiahnuť údaj o veľkosti. Viem, že je to netriviálna úloha, pretože som niečo podobné už absolvoval a nebola to sranda.
2. Ak píšem nový kód a chcem, aby bol kompilovateľný aj gcc/glibc aj s MSVC, tak ho musím písať tak ako ho chce MS a na gcc/glibc musím buď linkovať knižnicu, ktorá nie je v distre alebo si napísať makrá, ktoré tie extra argumenty zahodia. Ani jedno sa mi nepáči.

(MS) Tuto množinu nabídl ISO ke standardizaci, ale byl odmítnut.

To máš odkiaľ? Pretože ja hore linkujem dokument od open-std.org, kde sa tie funkcie pridávajú do C99.

[pht]

Tak pod to bych se s radostí podepsal.

[Miloslav Ponkrác]

Mimochodem, teď jsem si vylistoval zdrojové kódy všech safe funkcí v C kompilátoru (MS automaticky dává ke kompilátoru zdrojové kódy celé runtime knihovny). Celá sada funkcí, včetně zdrojového kódu pro obě varianty, tedy jak pro 8-bitové znaky, tak pro unicode – je psána multiplatformě i Microsoftem, a celé to má dohromady 64 KB zbytečně roztahaných zdrojových kódů.

[rastos]

Celá sada funkcí, včetně zdrojového kódu pro obě varianty, tedy jak pro 8-bitové znaky, tak pro unicode – je psána multiplatformě i Microsoftem

Nemal som na mysli multiplatformovosť čo do 8-bit vs. WCHAR, ale použitie na OS, ktorý nie je od MS, alebo kompilátorom, ktorý nie je od MS. Čo sa stane s existujúcim kódom, keď _CRT_SECURE_NO_WARNINGS jedného dňa zanikne?

[...............23]

Nemal som na mysli multiplatformovosť čo do 8-bit vs. WCHAR, ale použitie na OS, ktorý nie je od MS, alebo kompilátorom, ktorý nie je od MS.

Imho aj ten príspevok nad tebou

Čo sa stane s existujúcim kódom, keď _CRT_SECURE_NO_WARNINGS jedného dňa zanikne?

Čo by sa akože malo stať?

[salam]

co to?

[Deleted [8409]]

Je tu diskuze na téma strncpy a místo vysvětlení možného problému této funkce laikům se tu někteří vytahují otázkama, jestli ten druhý ví, co ta funkce dělá. Takže k věci:

V manuálových stránkách najdete toto:

char *strncpy(char *restrict s1, const char *restrict s2, size_t n);

The strncpy() function copies at most n characters from s2 into s1. If s2 is less than n characters long, the remainder of s1 is filled with `\0' characters. Otherwise, s1 is not terminated.

Zvírazněná pasáž je velice důležitá, protože říká, že pokud bude zdrojový řetězec větší než cílový, zkopíruje se 'n' znaků do cílového bufferu a ten nebude ukončený nulou. V praxi to znamená, že zavoláním funkce strlen() nebo jakékoliv neuvážené použití takového bufferu povede s největším štěstím k pádu (mluvím o štěstí, protože ladit tyto chyby může někoho pěkně vytočit ).

[Miloslav Ponkrác]

Jenom poznámku – to není vytahování se na laiky. To je jen upozornění, že když někdo machruje v této diskusi, měl by na to mít.

Ale je fajn, že tu mnozí konečně objeví, co skutečně dělá strncpy. Sám jsem se divil, kolik lidí to neví.

[M. Lox]

Kolik lidí to neví? Já v C téměř neprogramuji a ani ho moc neumím (mám ale, pravda, zkušenost v LISPu, takže mi seznamy problém nedělají ), ale je mi naprosto jasné, že když zkopírujete první tři položky ze seznamu [A B C D E F \0], tak vám vznikne [A B C].

[M. Lox]

Jinými slovy: „A to je všechno, ta úžasná bezpečnostní chyba je taková hovadina?“

[stativ]

Já si nemůžu pomoct, ale tady v diskusi nikdo neříkal, že tohle neví. Spíš mi přijde, že bezdůvodně předpokládáte, že dotyčný to vůbec neví.

[thingie]

Kdyby to nevěděl, tak by asi ani nevěděl, že to neví, a nemohl se tedy hlásit k tomu, že to neví. Náš veliký mystik nám tu jenom chce ukázat, že ani strncpy není nutně zcela bezpečná funkce, což má a nemá pravdu, ve smyslu debaty ovšem spíš nemá.

[qiRzT]

To mě taky taky překvapuje. Asi jsem měl nadprůměrně schopnou chvilku, ale jedna z prvních věcí, co mě napadla, když jsem se o té funkci dozvěděl, bylo, co se asi stane, když ten vstup bude delší než n. A jak jsem čet tuhle diskusi, tak si celou dobu lámu hlavu, kam směřují ty tajuplné narážky o nebezpečnosti téhle funkce.

[Semo]

Dakujem za vysvetlenie, ale som sklamany. Cakal som bombasticku dieru (po ponkracovych niekolkoobrazovkovych napinakoch) a ono iba nieco, o com uz roky viem a da sa liecit prikazom s1[n-1]='\0'. Na pocet znakov sa to podoba M$ fciam, na pocet podtrzitok to dokonca vedie.

[pht]

No, a to se vždycky řešilo tím, že se na konec bufferu nacpala natvrdo \0, ať už ji tam strncpy dal nebo ne. Nebo se použije snprintf. Spíš je důležité si odnést ponaučení: když jakkoli manipuluju s nulou ukončeným char*, musím se přesvědčit o tom, že tam někde ta ukončující nula je, nejlépe tam, kde má být.

[Deleted [8409]]

No v tomto případě je to asi nejlepší řešení. Ale já osobně tyto funkce vůbec nepoužívám, přijde mi to z hlediska koncepce nevýkonné a navíc i nebezpečné :)

[Deleted [8409]]

OMG, já asi neumím česky...:)

[petr_p]

Zajímavější problém je kopírování bufferů, které se překrývají. Nicméně i to se průměrný čtenář manuálů dozví. (Chválím správce manuálových stránek, že zařadili *p kapitoly.)

[Deleted [8409]]

To jo, to mě nenapadlo. Podle mě je stejně nejlepší používat nějakou třídu v C++, popřípadě si udělat alespoň strukturu v C a napsat si nějaké funkce nadtím. Ale to už je detail;)

[podlesh]

Idea za těmi funkcemi je v zásadě správná, ale nemohu si pomoci že v C podle Microsoftu je více podtržítek než v LISPu závorek.

[honza]

my to u nas ve firme obchazime makrama. A to jiz leta, uz i napr u systemovych funkci (stat,open.write,read ...) mel M$ ty kompatibilni jinak pojmenovany.

Jinak, jiz po tisici, C neni urcena k tomu, aby se v tom psaly programy, C se pouziva k psani generatoru programu. A v takove konstelaci neni strcpy zadny problem, protoze o to, aby ty delky stringu byly konformni se stara nekdo jiny.