Ohjelmistojen tietoturvariskeistä

[Ganymedes]

Päivitin edellä esitetyn mukaisesti alkuperäistä kirjoitusta. Lisäsin siihen yhden matriisin ulottuvuuden: Riskit ohjelmiston käytön mukaan - tarkoittaen tällä itseasennettuja ohjelmia, jotka mahdollistavat normaalista poikkeavaa liikennöintiä tietoverkossa (web server, ssh, jms).

Tätä lisäystä yllä toivottiin - jo aikaa sitten  .

[jimbo]

menee ehkä hiukan sivuun mutta lienee niin, ettei mistään voi tietää, jos joku on käynyt tai juuri käymässä(!)  koneella ? eli siis tullut sisään ja tekee mitä haluaa. nykyaikaisessa koneessa ei välttämättä vaikuta esim. nopeuteen, ei tietty jää mitään lokeihin tms. näkyviin, kun on tarpeeksi näppärä. toinen asia on sitten kuinka näin mennään sisään, mutta se ei ole topic
 

[Ganymedes]

menee ehkä hiukan sivuun mutta lienee niin, ettei mistään voi tietää, jos joku on käynyt tai juuri käymässä(!)  koneella ? eli siis tullut sisään ja tekee mitä haluaa. nykyaikaisessa koneessa ei välttämättä vaikuta esim. nopeuteen, ei tietty jää mitään lokeihin tms. näkyviin, kun on tarpeeksi näppärä. toinen asia on sitten kuinka näin mennään sisään, mutta se ei ole topic

Joo, menee sikäli sivuun, että tässä on tarkoitus lähinnä keskustella riskeistä, joiden vuoksi sisääntunkeutuminen on mahdollista ja toisaalta oikeista menettelytavoista, jotta tuollainen estyy.

Näkisin, että riskejä on tyypillisimmillään:

- päivittämättömät tai lähtökohtaisesti väärennetyt ohjelmat tuntemattomista lähteistä. Nämä voivat mahdollistaa sisääntunkeutumisen
- käytetyt ohjelmistot etäyhteyksiin. Näitä ei ole oletuksena käytössä, mutta jos ottaa käyttöön nämä pitää osata konfiguroida oikein
- käyttäjän omat virheet, esim. omien salasanojen antaminen eteenpäin. Ilmeisesti kaikki näyttävästi uutisoidut pankkihuijaukset ovat käytännössä näitä.


Kysymykseen siitä, että mistä näkee tunkeutujan:

- riippuen tunkeutujan ohjelmasta lokeja jää
- käsittääkseni Linux-järjestelmässä voi tapahtumia monitoroida varsin hyvin, joten senhetkinen tunkeutuja on havaittavissa koneelta. Eri asia on sitten kuka sitä osaa monitoroida. Voisi ajatella, että tällaisen havaitsemiseen tavallinen käyttäjä tarvitsee jonkun ohjelman, jonka käyttäminen ei ole ongelmatonta sekään (koska tunkeutuja yrittää varmaankin muuttaa tämän ohjelman toimintaa tai vain sammuttaa sen)
- tunkeutuja tuskin on kukaan henkilö. Lisbeth-salander-luokan crakkerit ovat varmaan joillakin muilla koneilla kuin tavallisten kotikäyttäjien koneilla
- tunkeutuja on todennäköisesti jokin botti, automaattinen ohjelma, joka hyödyntää juuri edellä mainittuja asioita, kuten: päivittämättömät ohjelmat, huonot salasanat, avoimeksi jätetyt verkkoyhteydet omassa asennuksessa jne

Tunkeutujalla ei välttämättä ole oikeuksia tehdä mitä hyvänsä, jollei sitten itse ole antanut salasanaansa jollekin muulle, esim. WEB-sivulla.

Nämä asiat kun summataan, niin riski on hyvin pieni tyypillisessä Linux-järjestelmässä jos käyttäjä on  itse toiminut harkitusti.

[Sami Lehtinen]

Suosittelen muuten Security Now pätkiä nörteille. Ei todellakaan tieteellisin tietolähde, mutta ihan hauskaa viihdettä kuunneltavaksi vaikka taustalla ja sitten voi tehdä jatkotutkimusta jos löytyy jotain mielenkiintoista:

Avoin koodi, turvallista? Heh, mm. crypt_blowfish oli 13 vuotta rikki, niin että vain joka neljäs merkki salasanassa käsiteltiin. Oops, silti vian löytäminen kesti noin kauan. Tuosta on juttua jaksossa 311. Olen muuten kunnellut kaikki paitsi 13 viimeisintä, jotka ovat tällä hetkellä kuuntelu jonossa.
GRC / Security Now - https://www.grc.com/securitynow.htm

Kannattaa myös tilata cert-fi tietoturva päivitykset sähköpostiinsa, koska täältä niitä ei tule kuitenkaan katseltua tarpeeksi usein:
https://www.cert.fi/tietoturvanyt.html
https://www.cert.fi/haavoittuvuudet/2012.html

[Sami Lehtinen]

Lisätään tähän sarjaan, että törmäsin juuri tänään uuteen virukseen, joka tuli koneeseen (Windows) hienosti sisään selaimen kautta kysymättä yhtään mitään, roottasi koneen, sulki f-securen ja sellaista kivaa. Menipähän image palautettavaksi. Puuh. Olisi nyt ollut edes vanha Ubuntu-kone joka olisi saanut siipeensä, niin olisi saanut mahtavan tekosyyn uudelleen asentamiseen.

Turvallisia ohjelmistoja ei taida olla olemassa. Jos joku niin kuvittelee, niin todennäköisesti on ummistanut silmänsä aika pahasti nykymenolle.

[Postimies]

Voisi lisätä myös turhien palveluiden karsiminen. Jos ei käytetä sambaa, etäyhteyksiä, ssh, bluetooth, verkkotulostinta niin tuollaiset palvelut pois päältä. Myös java sisältää omat riskinsä. Jos ei tarvetta sekin pois käytöstä. (Mihin tarvitaan?)

Palomuuria en pidä mitenkään pakollisena jos koneessa ei ole palveluita päällä. Jos selaa nettiä portin 80 kautta ei siinä ole mitään merkitystä onko palomuuri päällä tai ei. Jos selaimessa on tietokurva-aukko tai jossain sen lisäosassa ei siinä muuri auta. Itse vieroksun noita lisäosia. Flash toki on ja sitten plugin joka estää sitä toimimasta. Hieman ristiriitaista.

Linux maailmassa tiukat käyttöoikeudet estävät paljon haitakkeiden toimintaa. Vainoharhainen voi tietty tehdä aina chroot vankilan tai vastaavia virityksiä. Kotikansiosta kun pistää pois suoritusoikeuden hankaloittaa jo paljon. Selaimen väliaikaistiedostot eivät enää niin helposti luettavissa kuin Windows koneilla aikoinaan. Monella kuitenkin tapana tallentaa niitä tunnuksia selaimen muistiin ja jopa verkkoon.

 X ohjelmia varsinkaan selainta ei saa käyttää root-oikeuksilla. Suurimmat Windows-ongelmat johtuvat siitä, että normikäyttäjällä on oletuksena oikeus asentaa ohjelmia tai muuten muokata systeemiä.  Ja jo kaupasta ostetusta CD-levystä (ääni) saattoi saada vakoiluohjelman koneelle joka myös esti tekemästä levystä kopioita. Linux systeemissä ohjelmat eivät asennu näin helposti. Jos asentuis niin haittaohjelmia olisi enemmän. Win98, XP ym. tehtyjen tiedossa olevien haittaohjelmien lkm on hirvittävä. Jos Mersu tai vaikka Abloy tekisi vastaavan tuotteen.. niin sitä ei kukaan ostaisi. Windows 98 salasanan ohitus. Painetaan näppäintä 'Esc'. Onneksi kehitystä on tapahtanut parempaan suuntaan. Itsellä yhtä vanha auto ja siinäkin niin raju ajonestojärjestelmä että en usko kenenkään saavan sitä käyntiin. Avaimen kopiointi mahdollista, mutta hyvin hankalaa.

[Sami Lehtinen]

Astetta paranoidimmat voivat myös miettiä sitä vaihtoehtoa, että ohjelmistopäivitykset ovat tietoturvariski. Miksi? Pienempien ohjelmakirjastojen kautta on paljon helpompaa soluttautua koneeseen kuin suurempien. Myös pienemmissä projekteissa varmasti turvallisuus ja valvonta on heikommalla tasolla.

Windows 8 raportoi automaattisesti käytetyistä sovelluksista Microsoftille. Tämä tarkoittaa sitä, että kun koneeseen halutaan hyökätä, ei tarvitse enää ujuttaa softia Microsoftin kautta. Vaan voidaan ihan viattomasti ujuttaa ne backdoorit koneele jonkun muun sovelluksen kautta jossa sinulla on automaattiset päivitykset päällä.

Kuten tiedämme, monen softan päivitys-systeemit on varsin epämääräiset, eikä niitä valvota riittävän hyvin. Pahimmassa tapauksessa softat lataavat vain jostain urlista .exe:n ja suorittavat sen, ilman mitään allekirjoitusten tarkistamista tms.

Tämä on tietysti yleinen uhka ja vaatii melkoisen kierroksen foliota kuupan ympärille, mutta teknisesti varsin mahdollista ja toteuttamiskelpoista. Mikä vielä parasta, kun tuo päivitysten jakelu tehdään joltain random serveriltä, voidaan myös erilaisilla verkkokaappauksilla tai muilla konstein saada osajoukolle konetta ladattua eri koodi kuin muualle. Näin ollen perustelu että koodihan on aina jonkun tarkistamaa on täysin virheellinen. Koska juuri sitä koodia joka koneellesi ladattiin, ei ehkä saanut kuin sata muuta ihmisitä esimerkiksi samassa kohde-organisaatiossa. Kuten tiedämme, hyökkäykset pyritään nykyjään kohdentamaan hyvin huolellisesti, jotta ne eivät paljastuisi.

Semmoset horinat tällä kertaa. Nyt menen kiertämään pari kierrosta lisää folioturbaaniini.

[Ganymedes]

Tuo on ihan totta että alkuperäisessä esityksessä ei erikseen mainita päivityksiä ja ne toki elävät omaa elämäänsä ... siis eivät tule aivan samalla tavalla kuin alkuperäinen asennus. Lisäilen tuosta oman kohtansa jossakin vaiheessa.

Mielestäni siinä on varsin suuri periaatteellinen ero, että tulevatko päivitykset useasta, käytännössä tuntemattomasta, lähteestä vai yhdestä keskitetystä lähteestä (kuten Ubuntulle tulevat tavalliselle käyttäjälle, jolla ei ole mitään erikoista koneella). Sellainenkin päivityksen oma riskinsä tulee mieleen, että jos ohjelma ei ole keskitetystä lähteestä, niin se ei välttämättä päivity ollenkaan, jos sitä ei itse tee manuaalisesti tai että kun jokaisella ohjelmalla on omanlaisensa päivitystapahtuma, käyttäjä voi helposti mokata niiden kanssa ... onhan tuossa monenlaista periaatteellista riskiä.

Käytännössä ei kuitenkaan tule mieleen, että (Windows-maailmassa) olisi pystytty ujuttamaan päivityksiin haittakoodia - yleensä ovat olleet uusia ohjelmia, mahdollisesti kuitenkin päivityksiksi naamioituja ... no, liittyy silloin epämääräisen päivitystapahtuman seurannaisriskeihin - kalastelu ja huijaus on kovasti POP nykyään. Suurin riski lienee kuitenkin se, että ei päivitetä ollenkaan ja se ei ole pelkkä Windows-maailman synti.

[Sami Lehtinen]

Käytännössä ei kuitenkaan tule mieleen, että (Windows-maailmassa) olisi pystytty ujuttamaan päivityksiin haittakoodia.

Stuxnet?

Monien ohjelmistojen päivitykset jaetaan FTP:llä/HTTP:llä ilman mitään allekirjoituksia tai salauksia. Näin ollen lähteen kaappaaminen, tai mikä tahansa verkkomanipulaatio matkalla jolla saadaan syötettyä väärää tietoa clientille, johtaa onnistuneeseen manipuloidun päivityksen toimittamiseen kohteeseen. Ainakin Windowssin VLC on tällainen, ja muistaakseni myös uTorrentin päivitykset. Ladataan vain uusi versio ja pam, isketään se ajoon. Missä oli asianmukaiset varmistusket siitä, että ladattu paketti on yhtään sitä mitä sen pitäisi olla?

Stuxnetissä asia meni käsittääkseni niin, että muokatut päivitykset jaeltiin eri palvelimilta, mutta ne saatiin allekirjoitettua niin että verkkomanipulaatiolla saatiin muutkin koneet lataamaan niitä.

1) Saastumattomat koneet latasivat päivitykset, verkkomanipulaation avulla väärästä lähteestä
2) Ne tarkistivat asiallisesti väärennettyjen ohjelmistojen allekirjoitukset
3) Mitään vikaa ei havaittu ja nuo asennettiin

Tuollaisella tekniikalla olisi mahdollista tehdä varsin massiivisia järjestelmien kaappauksia ja luoda hetkessä suuria botnettejä tai sitten piileskellä taustalla ja varastaa tietoja avainkohteista.

[Ganymedes]

...
Stuxnet?
...

Yep, siinähän se esimerkki tuli. Muutenkin ... kuten Oppenheimer aikoinaan totesi: "Mahdollinen on väistämätöntä." Ohjelmistojen riskeissä ja ongelmissa yleensä kaikki mahdollinen toteutuu, ennemmin tai myöhemmin.

Tuleeko muuten mieleen kuluttajapuolelta jotakin jossa päivitysten kautta olisi saatu ujutettua jotakin sisälle? Kaikenlaistahan on ollut, esim. tehtaalta tulleissa USB-tikuissa on ollut viruksia ja päivitykset sotkevat koneen, mutta ne ovat hieman eri asioita kuitenkin.

[Sami Lehtinen]

Tuleeko muuten mieleen kuluttajapuolelta jotakin jossa päivitysten kautta olisi saatu ujutettua jotakin sisälle?

Kun nyt menit kysymään asiaa, niin vastataan taas. Vaikka Google olisi varmasti tiennyt useampiakin oikeita vastauksia. Tämä oli vaan yksi joka tuli suoraan ulkomuistista: http://www.theinquirer.net/inquirer/news/2109087/utorrent-download-replaced-malware

Uskon että tässä on vähän sama juttu kuin muissakin asioissa, eli skaala jutusta kyse. Jos palvelimesi on Amazonin pilvessä, on se ihan kamalaa jos tulee downtimeä, maailma kaatuu. Mutta jos sitä hostaa kotona kellarinkomerossa, niin sen uptime on taatusti 100% (kunnes ei enää ole) mutta silti se ei ole mikään uutinen.  µTorrent vaan on sen verran yleinen softa, että nuo pääsivät/joutuivat uutisiin sen takia.

Eli noita sattuu varmaankin viikoittain, ellei päivittäin. Mutta kukaan ei niistä uutisoi. Tiedän ainakin erään instanssin jossa tuo oli todella lähellä, hakkereilla oli päivityspalvelimelle jo admin tunnukset, mutta eivät ilmeisesti tajunneet mihin palvelinta käytetään, eivätkä näin ollen ymmärtäneet että valtava määrä koneita hakee siltä jatkuvasti päivityksiä jotka ne asentavat automaattisesti käyttöön. Jos hakkerit olisivat tajunneet tämän, olisivat saaneet kaapattua valtavan määrän lisää koneita todella helposti.

Tässä kuvatut jäävuoren huippu ja skaala-harhat lienee varsin yleisiä kaikissa asioissa joihin arjessa törmäämme.

[Sami Lehtinen]

Java taas loistaa olemassaolollaan: Cert-Fi Java 7

[avanti]

Java taas loistaa olemassaolollaan: Cert-Fi Java 7

Jahas. Java 7:n versio Linuxissa tarkoitti Ubuntu 10.04:n versiota. Suotta poistin. Voin siis hyvin asentaa seiska takaisin tähän 12.04:ään.

ML

[Sami Lehtinen]

Jahas. Java 7:n versio Linuxissa tarkoitti Ubuntu 10.04:n versiota. Suotta poistin. Voin siis hyvin asentaa seiska takaisin tähän 12.04:ään.

Nyt meni kyllä aika metsään sun statement, mutta sellaista sattuu jos ei lue tekstiä ja perehdy asiaan huolellisesti. Kieltämättä tuo uutinen ei ollut ihan selkeimmällä mahdollisella tavalla kirjoitettu.

Anyway, kuten aikaisemmissa viesteissä olen tässä todennut. Turvallisia ohjelmia ei ole, eikä ole tiedossa että tulisi olemaankaan. Joten hyökkäyspinnan minimointi on aina hyvä menetelmä.

Aina naurahdan kun joku menee sanomaan, että versio XYZ tai Selain ABC on turvallinen. Mistähän nuo tilastotieteen mestarit noita väitöksiä vetävät? Se on ihan yhtä fiksua kuin väittää, että päävoiton saaminen lotossa on mahdotonta.  Kuitenkin jos katsotaan vähänkin historiaa, niin nähdään että päävoittoja on jatkuvasti mennyt jollekin.

Vielä koskaan versiota ### turvalliseksi väittänyt ei ole toimittanut riittävää dokumentaatiota osoittaakseen väitteensä todenpitäväksi. Toisaalta, koska näitä väitteitä on esitetty jo pitkään, on taas aika osoittanut noiden väittäjien olevan väärässä, koska em. versioista on jälleen löytynyt jotain korjattavaa.

On siis todella hölmö veto mennä väittämään, että joku ohjelmisto on turvallinen. Todennäköisyys siihen, että sen väittäjä on väärässä, lähestyy rajatta ääretöntä.

Ihan sama väite pätee myös useimpiin algoritmeihin, menetelmä XXX on turvallinen. Kuitenkin kun katsotaan historiaa huolellisesti, on taas jälleen äärimmäisen suuri todennäköisyys siihen, että asian väittäjä on väärässä.

Minä en ainakaan enää koskaan sano että ohjelmisto on turvallinen tai joku salausmenetelmä tms, on turvallinen. Koska se on melko varma tapa failata.

Hesarikin on jo herännyt tähän Java aiheeseen.

P.S. Kerro ihmeessä mistä sait koneeseesi "turvallisen Javan", kun sitä ei ainakaan muiden tietojen mukaan ole olemassa? Teitkö itse patchin? Mistä tiedät että siinä ei ole muita reikiä?

[Tomin]

Java taas loistaa olemassaolollaan: Cert-Fi Java 7

Jahas. Java 7:n versio Linuxissa tarkoitti Ubuntu 10.04:n versiota. Suotta poistin. Voin siis hyvin asentaa seiska takaisin tähän 12.04:ään.

Tuossa oli mainittu vain testatut versiot, eli Cert-Fin kaverit eivät ole vielä siirtyneet uusimpaan, jossa lienee sama versio Javasta. Tosin jos käytät OpenJDK:ta ja sen kaverina IcedTea:a niin ilmeisesti sillä yhdistelmällä et nettiselaimen kautta saa tunkeutujia. Silti suosittelen ottamaan sen väliaikaisesti pois käytöstä ihan varmuuden vuoksi, jos Javalle ei ole muuta käyttöä. Eiköhän sieltä korjaus kohtapuolin tipu.

[Postimies]

Jos ei tarvitse javaa niin sen voi poistaa. Tai vaihtoehtoisesti käyttää kahta selainta. Toisessa on java niitä sivuja varten joissa se on pakollinen. Toisessa selaimessa taas on java poistettu käytöstä ja sitä käytetään normaalisti. Pankin sivulta tuskin saa viruksia, mutta joltain toiselta voi jos vaikka näppäilee nimen vähän väärin..

Ohjelman todistaminen toimivaksi tai turvalliseksi on haasteellinen tehtävä. Muutaman rivin aliohjelma helpohko tapaus. Kun koodia on miljoonia rivejä testaus käytännössä mahdotonta. Jonkun aliohjelman todistuksessa on yleensä syöttessä joku rajoitus. Tyyliin toimii kokonaisluvuilla välillä 1 - 10 000. Tai päivämäärän pitää olla muotoa pp.kk.vvvv tietyllä välillä. Eli toimii kunhan syöte on oikea. Mutta väärää syötettä ei ole testattu..

On paljon fiksumpaa, että suoritettava koodi on palvelimessa, joka luo näkyvän sivun dynaamisesti. Eikä käytäjän koneella ajettaisi suoritettavaa koodia - javaa tai mitään muutakaan.

[Sami Lehtinen]

On paljon fiksumpaa, että suoritettava koodi on palvelimessa, joka luo näkyvän sivun dynaamisesti. Eikä käytäjän koneella ajettaisi suoritettavaa koodia - javaa tai mitään muutakaan.

Tämän suhteen ollaan jatkuvasti menossa yhä kiihtyvällä vauhdilla juuri toiseen suuntaan. Kaikki suorittaminen siirretään käyttäjän koneelle ja palvelin (siis pilvi) toimii vain tietokantana ja jakelualustana.

Client server arkkitehtuuri siis säilyy, mutta clientti siirtyy sovellukseksi selaimeen, joka tuo taas ihan omat riemukkaat tietoturva-ongelmansa.

[Echramath]

Onkos Linux-systeemeissä mikä tilanne sen systeemin kanssa, jota Windows kutsuu Secure Desktopiksi, eli se kun Vista tai seiska vetää näytön tummaksi kun oikeuksia korotetaan? Sen nimittäin käsittääkseni pitäisi huolehtia siitä, että näppäimistöä ei voi lukea kuin järjestelmä itse. Sen sijaan ainakin uusimmassa Xubuntussa näemmä ihan sama millä optioilla esim. gksudoa ajaa, omalla käyttäjätunnuksella oleva screenkey pystyy näkemään salasanan.

[Sami Lehtinen]

Ohjelman todistaminen toimivaksi tai turvalliseksi on haasteellinen tehtävä. Muutaman rivin aliohjelma helpohko tapaus.

Onko? Entäs kun haavoittuvuus on raudassa, käyttöjärjestelmässä, kääntäjässä tai jossain sovelluksen käyttämistä kirjastoista? Tai hyökkäys tehdään tavalla jota ei ole tajuttu ajatella ollenkaan kun koodia on tarkistettu. mm. hash dictionary collision hyökkäykset, jolla saadaan denial-of-service tilanne aikaiseksi, vaikka koodissa ei mitään vikaa olekkaan. Kuka tarkisti hash algoritmin ja varmistui siitä, että se on oikeasti sellainen ettei sitä voida väärinkäyttää. Vaikka syöte olisi todella yksinkertainen ja käsittely myös, niin silti tuohon jää haavoittuvuus. Muistaakseni mm. Pythonin dictionaryn hash collisionia on käytetty DoS hyökkäyksiin. Aivan kuten Apachen range DoS aukko oli ollut sovelluksessa "ikuisesti", eikä sitä ollut kukaan sieltä hiffannut.

Kas kas, ohjelma onkin haavoittuva, vaikka kirjoittamassasi koodissa ei ole yhtään mitään "vikaa".

Kannattaa myös käydä tämä läpi: https://www.grc.com/sn/sn-211.htm <- tuossa käsitellään nimenomaisesti järjestelmiä jotka on alusta asti, myös rauta mukaanlukien suunniteltu turvalliseksi... Ja silti haavoittuvaisia.

Turvallisen tekeminen, on pirun vaikeaa. Koska valitettavasti kaikkein yksinkertaisimmaltakin näyttävät asiat voivat silti olla tehty väärin ja vielä tavalla jota kukaan ei tajua, vaikka koodi auditoitaisiin hyvinkin huolellisesti.

[Postimies]

Ohjelman todistaminen toimivaksi tai turvalliseksi on haasteellinen tehtävä. Muutaman rivin aliohjelma helpohko tapaus.

Onko? Entäs kun haavoittuvuus on raudassa, käyttöjärjestelmässä, kääntäjässä tai jossain sovelluksen käyttämistä kirjastoista? Tai hyökkäys tehdään tavalla jota ei ole tajuttu ajatella ollenkaan kun koodia on tarkistettu. mm. hash dictionary collision hyökkäykset, jolla saadaan denial-of-service tilanne aikaiseksi, vaikka koodissa ei mitään vikaa olekkaan. Kuka tarkisti hash algoritmin ja varmistui siitä, että se on oikeasti sellainen ettei sitä voida väärinkäyttää. Vaikka syöte olisi todella yksinkertainen ja käsittely myös, niin silti tuohon jää haavoittuvuus. Muistaakseni mm. Pythonin dictionaryn hash collisionia on käytetty DoS hyökkäyksiin. Aivan kuten Apachen range DoS aukko oli ollut sovelluksessa "ikuisesti", eikä sitä ollut kukaan sieltä hiffannut.

Kas kas, ohjelma onkin haavoittuva, vaikka kirjoittamassasi koodissa ei ole yhtään mitään "vikaa".

Kannattaa myös käydä tämä läpi: https://www.grc.com/sn/sn-211.htm <- tuossa käsitellään nimenomaisesti järjestelmiä jotka on alusta asti, myös rauta mukaanlukien suunniteltu turvalliseksi... Ja silti haavoittuvaisia.

Turvallisen tekeminen, on pirun vaikeaa. Koska valitettavasti kaikkein yksinkertaisimmaltakin näyttävät asiat voivat silti olla tehty väärin ja vielä tavalla jota kukaan ei tajua, vaikka koodi auditoitaisiin hyvinkin huolellisesti.

Vaikeaa eikö totta? Aliohjelma, jossa on vaikka pari asetuslausetta on minusta helpohko. Mutta jo sisäinen rekursio tai muutama aliohjelmakutsu voi tehdä todistamisen hyvin hankalaksi. Matemaattisia menetelmiä käytetään vähän (hidasta) ja yleensä tyydytään testaamaan toimiiko oikein. Ja testauksessa käytetään usein helppoja syötteitä, joihin on vastaus olemassa.

Käytetty kieli vaikuttaa myös paljon. Paljon käytetyllä C:llä voi kirjoittaa niin hankalaa koodia,
että sen ymmärtäminen on hankalaa. Esim.  lause i = i >> 3; on ihan laillinen eikä edes vaikea. Mutta silti kovin ongelmallinen.