Názory k článku Kde se berou bezpečnostní mezery?

JSOU Z MÉHO JARU!!!

Clanek jasne popisuje, jak vznikaji nektere bezpecnostni chyby.

Ale naprosta vetsina bezpecnostnich chyb jisteho velmi rozsireneho operacniho systemu vznikla naprostou nekoncepcnosti a ignorovanim rizik. Lze v souladu s vyrobcem tohto software konstatovat, ze to nejsou chyby, ale vlastnosti - zamerne implementovane vlastnosti, ktere si primo rikaji o zneuziti.

pekne auto!
a mami, proc mas tak hebke ruce?

:))

clanek je super, ale nikam nas to neposunulo. mozna by to chtelo trosku zabrednout do oblasti softwaroveho inzenyrstvi a prozkoumat, jak produkt vlastne vznika. pak se prijde na to, ze se to vetsinou nehorazne lepi, genialni navrh je v puli tvorby zmenen lidmi z marketingu, cimz se to totalne zmrsi, pak se nestiha a nejak se to zbastli.

problem je v tom, ze zakaznik hodnoti produkt podle toho, jestli funguje. nikdo neresi, JAK funguje.

takto se rodi informacni systemy, ktere je tezke pouzivat a ohromne produkty s nezvladnutelnym mnozstvim nejen bezpecnostnich chyb.

program ktery za "urcitych okolnosti" deli nulou, pretece buffer, nebo po sobe neuklidi po zachyceni neznameho preruseni, je proste spatne napsan a obsahuje CHYBY, nikoliv vlastnosti, ke kterym muze dojit 1:10e9.

nekteri vyrobci sw k tomu pristupuji stejne jako pisatel clanku a podle toho to pak dopada.

Probuh, termin "bezpecnostni mezery" jste slysel kde? Spravne je "bezpecnostni diry"!

pod bezpecnostini dirou si clovek predstavi problem. ale kdyby jste cetl clanek pozorneji, tak zjistite, ze autor nema v umyslu poukazovat na odflaknutou praci, ale na vlastnosti, osud, nestastne nahody.... no proste na bezpecnostni mezery :))

Clanek jsem cetl pozorne. Popisuje problemy, ke kterym dochazi v dusledku bezpecnostnich der, nemuzu si pomoci :-) Pojem "bezpecnostni mezera" se nepouziva. Alespon jsem ho za ty roky, co se kolem IT pohybuji, nikdy neslysel. Spravne se skutecne rika "bezpecnostni dira".

V M$ Windows, obsah clanku lze takto zkratit :>)

vim,

ale asi jste nepostrehl ironii v mem prizpevku :)

Take Solaris, Linux, HP-UX, AS-400, Oracle, SAP, Lotus apod...

Kecy, nic vic. Naivne jsem cekal ze autor rozebere nekolik popularnich der z posledni doby, popise jejich podstatu, a zpusob jak vznikly. Kdyz spadne letadlo, je takove vysetrovani a zduvodnovani zcela samozrejme.

Misto toho jsou tu jakesi tlachy o "koleckach" a "slozitem api". Ach jo, radsi nepiste. "nezavisly novinar" se pomalu stava nadavkou.

I přes upřímnou snahu jsem převážně nepochopil, co vlastně autor chce sdělit, a kde jsem pochopil, tam spíš nesouhlasím. Takže se asi kvalifikuju za technokrata, který to "neponese rád" :-)

Představy a analogie jsou svůdné, ale nemusí být vždy užitečné. "Kombinace koleček" - tak to není. Vezměmě něco dost jedoduchého, pracujícího v dost homogením prostředí třeba "php redakční systémy" - obsahují méně chyb? Kdepak, mnohé populární jsou děrovaté jak řešeto (pouze je málo útočníků).

"Univerzálnost". To se neudržím, ale to je úplný blábol. Ke slovu počítač lze přidávat všelijaká adjektiva typu "domácí" a kecat o obtížnosti návrhu něčeho unverzálního. Kdesi hluboko však leží pojmy jako "Turingův stroj", nějaké věty o ekvivalenci, "von Neumannův stroj" a tak podobně. Právě že počítače jsou přirozeně univerzální a díky těm hlubokým pojmům v pozadí v principu "umí všechno". Je strašně obtížně obtížné je tomu "odnaučit" a je to častým zdrojem bezpečnostních problémů :-)
Variabilita využití nijak podstatně nesouvisí s "interakcí různých rozhraní".

"Totéž homogenní prostředí ale přispívá k relativně spolehlivému a stálému fungování informačních systémů."
K relativně stálému a spolehlivému fungování "globálních systémů" přispívají jednotné definované protokoly. Homogení prostředí je především levné, spolehlivosti škodí.


Námět na hlubší zamyšlení, kde se berou bezpečnostní "mezery":

Výroba nejrozšířenějšího software dnes znamená unikátní kombinaci podmínek
- Nulová odpovědnost výrobce za chyby, vzniklé škody, záruka...
- Uzavřenost. Není známo nějaké složení, plány... (zdrojové kódy). Nelze se přesvěčit, jaké prasárny se případne skrývají "uvnitř".
- Výrobky se prodávají "jako jablka", od kusu. (Hovoří se o "krádeži" software). Doopravdy ale mají podobu čísel, která lze s naprosto nepatrnými náklady replikovat na mnoho fyzicklýchh nosičů. Ztrácí tak význam řízení jakosti, prototyp,...
- Neexistují normy, certifikace.

Žádná z těhle podmínek není technické povahy.
Není ale třeba zmiňovat filosofii, otázka prostě je, co se výrobcům kancelářského software obchodně vyplatí.

.

Jak to, ze neznate pojem "bezpecnostni mezery"? To mate bezpecne znalostni mezery!

Coz je skutecne pravda - a cely clanek by daleko lepe sel, kdyz uz se musi zabyvat prirovnanimi, prirovnat k nakupi u Vietnamcu - zbozi nekvalitni lec lacine. A spousta lidi kupuje tam - protoze jinde je to, preci, drahe - a v souboji mezi "kvalitou" a cenou u mas vyhrava jednoznacne cena.

A vyrobce dodava co jest zakazniky pozadovano. Bezpecnost je "luxus" - nikdo ho moc nechce a plati se draho. Co se pozaduje je nizka cena - a maximalne tak tenky maskovaci nater vzbuzujici iluzi "ze to je bezpecne".

Podstatná je první podmínka.

Druhá je nezajímavá. Moderní auta jsou taky blackboxy, a k ničemu podobnému u nich nedochází. Když dojde, stahuje se celá série a firma se modlí, aby ji stihli stáhnout včas, než se bude platit zmrzačeným a auto bude prohlášeno za "nebezpečné v každé rychlosti".
Ostatně už u škodovky, na které jsem se učil řídit, jsem se sice dokázal přesvědčit, jestli je brzdová kapalina, ale ne jestli není někde nějaká zhůvěřilost, která při prudkém brzdění rupne.

Třetí nerozumím. Prototyp samozřejmě je, otestovat jde, s prodejem jako kusu to nesouvisí.
Jde to testovat. Ale asi se nedělá, protože - podm. 1.

Čtvrtá neplatí. Normy a certifikace existují, ale proč je dodržovat, když je zákazník nechce? A navíc - podm. 1.

Ta první podmínka stačí. Bohatě.

Tak si taky rýpnu:
"...A tak je současný typický klient - obyčejné PC - doslova prošpikováno různými API a protokoly, které se podílejí na jeho fungování v míře omezené buďto účelem (TCP/IP), platformou (Win32), prostředím (Javascript), případně kombinací několika z těchto prvků. Typický stav přitom je, že nevyužíváme pouze jedno z těchto rozhraní, ale v rámci jedné konkrétní aplikace mnoho různých..."

Možná jsem to špatně pochopil, ale připadá mi to, jako kdybyste kritizoval základní myšlenku ISO/OSI: Každá vrstva dělá jednu věc a dělá ji jak nejlíp umí!

"Lepení chybám nesvědčí"
Když už se nalezne nějaká ta chyba, jak by se podle Vás měla opravit, když ne záplatou?
---
V diskuzi byla zmíněna nezodpovědnost vývojových firem. Ale co jim zbývá? Kdyby řekli klientovi, že vývoj bude třikrát dražší a bude trvat třikrát déle než u konkurence, ale v programu nebudou skoro žádné díry, tak každý radši koupí levnější děravé řešení.

ne, to je dira ve vzdelani :)

> Pojem "bezpecnostni mezera" se nepouziva. Alespon jsem ho za ty roky, co se kolem IT pohybuji, nikdy neslysel

a co na to rika googlefight? :)

http://www.googlefight.com/cgi-bin/compare.pl?q1=bezpecnostni+mezery&q2=bezpecnostni+diry&B1=Make+a+fight%21&compare=1&langue=us

me to vypsalo bezpecnostni mezery 288x : bezpecnostni diry 610x

takze diry sice vyhraly, ale mezery na tom taky nejsou tak zle ;)

Já jsem ty implikace myslel obráceně - podle mě by k výrazným změnám u software stačilo upravit kteroukoli z uvedených vnějších podmínek.

Auta jsou bezpečná - neplatí pro ně 1., ale ani 3. a 4. Samozřejmě na spoustu věcí v autě je spoustu norem. A automobilce se samozřejmě kontrola jakosti vyplatí, protože stažení každého šmejdu je drahé. Oproti tomu oprava softwarového šmejdu je pro výrbce levná, prostě se umístí záplata.

Podmínka 3. prakticky znamená, že vyrábět šmejdy se u softwaru neprodražuje, samozřejmě souvisí s 1.

Poviné normy a certifikace na bezpečnost kancelářského software neexistují. Normy na bezpečnost software v řadě specifických aplikací existují.
Oproti tomu v ostatním světě jsou normy na bezpečnost třeba i kuchyňských elektrospotřebičů, čím méně poučený uživatel, tím musí být zařízení "blbuvzdornější". A povinost splnit je je daná zákonem, ne jen vůlí zákazníků.

Tak mi to tak připadá, že si autor nechal problém "vysvětlit" některým z rádoby programátorů, kteří se takto vymlouvají a pak nám to zde prezentuje jako obecnou pravdu.

Když bych se pokusil o shrnutí příčin chyb SW:
- chyby v počátku návrhu, kdy se opomene zahrnout určitá podmínka
- následné přidání nového kusu kódu s nedůsledným zkontrolováním
- špatné kódování jako takové (sem potom patří výmluvy neschopného programátora an složitost rozhraní)
- a samozřejmě libovolné kombinace

Samozřejmě je ale chudák programátor, který používá knihovny libovolného systému. Tyto knihovny jsou totiž blackbox (i když je k nim zdroják, tak je nebude do mrtě studovat - na to není čas) a zde se opravdu může přihodit souhra náhod. Nejhorší je to samozřejmě při multivláknovém programování, kdy spousta kódu běží najednou, k tomu si vlastní vlákna vytvářejí i knihovny...

No, asi tak...

teda sorry, tady to vidite

Vite, von programator je taky jen clovek. Kolik vy udelate denne chyb? ... I kdyby byl treba nadclovek a psal programy podle vsech dnesnich "bezpecnostnich" pravidel, tak se zejtra muze probudit a zjistit, ze uz to neni pravda :). Sem tam se objevi nove zpusoby, jak zneuzit to, co bylo vcera povazovano za neoblomne. Viz napr. integer overflow (a pak, ze nezkopirujete 2GB bez toho aby to hapalo :) ). Smirme se s tym, ze chyby budou, ale snazme se je eliminovat.

Turingův stroj raději nevzpomínejte. Tato jednoduchá představa matematiků, jak by mohl vypadat počítač, strašným způsobem brzdí teorii potřebnou pro současný rozvoj. Jak třeba Turingův stroj "čeká na další požadavek člověka" (rozuměj třeba kliknutí myší)?
Já osobně jsem přesvědčen, že za programové mezery může další nesmyslná teorie o naprosté nevhodnosti používání GOTO. Hned popíši proč.
Pokud někdo píše nějaký program - a není vyložený flink - tak u každé podmínky se rozhoduje, jak a kdy co učiní, a také má i představu, jakou variantu neuvažuje. Může-li pro nepatřičné varianty udělat jednoduše GOTO PRYC, tak to udělá. Ale když to tak snadno nejde (anebo by se mu za to někdo teoreticky vysmíval), tak se na to vykašle. - A potom už jenom stačí najít vhodnou kombinace neošetřených podmínek.
Takové je prostě moderní programování a tak si všichni na viry musíme zvyknout! Berte to tak, že představy o bezpečných programech jsou nemoderní a také žádný teoretik se něčím tak ubohým, jako jak psát bezpečné programy, nezabývá a zabývat nikdy nebude.

s goto hoooooodně nesouhlasim

Chybovost úměrně roste se složitostí algoritmu. Nedoporučení goto (nikoliv jeho zákaz) plyne ze snahy dekomponovat složitý problém na jednodušší. Když máte funkci dlouhou přes tři obrazovky a v ní tři a více vnořených úrovní tak souhlasím že už Vám z toho bordelu nic než goto nepomůže :-) a to je ten okamžik kdy vzniká maximum chyb.

Snahou je samozřejmě takové funkce nepsat a problém rozdělit do více dostatečně jednoduchých funkcí - při tomhle stylu psaní zaprvé vyloučíte chyby plynoucí z nepřehlednosti a na goto ani nepomyslíte (ne proto že byste se ho bál).

berk

1. S turingovým strojem jste trochu mimo. Ten neslouží jako model, na kterém byste měl postavit počítač s interaktivními hrami. Turingův stroj je teoretická konstrukce, jejímž účelem je umožnit definici toho, co je to vlastně algoritmus a algoritmizovatelná úloha, případně modelování konečnosti a časové složitosti.

2. Striktní zákaz goto v jakékoli podobě hlásala pouze hrstka fanatiků, a i ti nejaktivnější z nich už nejspíš stihli zmoudřet. Ostatní už tehdy tvrdili, že goto minimálně v situacích, které odpovídají céčkovým break, continue, return a exit jsou žádoucím a opodstatněným prvkem jazyka. Nehledě na to, že moderní zpracování chyb, založené na výjimkách (exceptions) je přesně řešením vašeho problému (i když je to vlastně zase maskované goto).

No jo, jenomže nebrzdící auto nebo probíjející mixér či nabíjecí baterka koupená u Ťongů vás může zabít. Takže tyto normy jsou nutné a každý jejich nutnost uzná. Snad i to, že tu baterku je vhodné zabavit.
(Vzpomínám, jak v dobách největšího nařízeného a kontrolovaného! přátelství se SSSR - naším to vzorem - se u nás nesměly prodávat ruské samovary na elektriku. Neměli u našeho vzoru, a asi dosud nemají, nulák. Postupovali dle normy GOST, je nás dost, jak jsem se doslechl na vojně... Přes veškerou ideologickou spřízněnost si nikdo nedovolil povolit ani nařídit povolení nenulovaného spotřebiče 220V s vodou.)

Mizerný SW vás obvykle nezabije. Teda pokud vám nesmazal těsně před důležitou prezentací několikadenní práci a i pak to normální člověk okomentuje několika (mnoha) doprdelemi a lehkými slečnami (popřípadě pokálenými), leč nezkolabuje. Někdo ano.

Takže daly by se napsat normy na bezpečnost SW, ale program to prodraží. A jak správně psal tady někde Dan Lukeš, lidi radši koupí něco levného než bezpečného. Navíc, tu bezpečnost většinou neuvidí, zato dvojnásobnou cenu ano.

BTW - máme normy na vývoj SW a testování. A jsme drazí. Vyrábět kancelářský SW, nikdo by to nekoupil... Taky žádné bohémství, žádný rozlet pro developery, krutá otročina. Potřebná.