Kirjoittaja Aihe: shellshock  (Luettu 14746 kertaa)

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3401
    • Profiili
Vs: shellshock
« Vastaus #20 : 29.09.14 - klo:12.23 »
Joo, tiedetään. Ja samaa mieltä myös epäloogisuudesta.  
Lainaus
Esim. dhclient vastaanottaa ympäristömuuttujia dhcp-serveriltä ja välittää ne ajamilleen bash-skipteille

Jos dhcp-serveri lähettää clientille korruptoituneita ympäristömuuttujia niin minä osoittelen kyllä silloin ensisijaisesti dhcp-serveriä. Toki client voi myös filtteröidä mitä laittaa ympäristöön (jos se muuttaa sitä ennen scriptien kutsua).

Yksi hyvä asia näissä ympäristöissä kuitenkin on:  Ne periytyvät eli ongelma ei "valu ylöspäin" ja prosessin loppuessa sen ympäristö hävitetään.  Silti tuossa on suuri vaara _jos_ ympäristöön pääsee käsiksi ei toivotulla tavalla. Seuraava samasta ympäristöstä käynnistys ajaa koodin.
« Viimeksi muokattu: 29.09.14 - klo:12.48 kirjoittanut ajaaskel »
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

kuutio

  • Vieras
Vs: shellshock
« Vastaus #21 : 29.09.14 - klo:12.59 »
Jos dhcp-serveri lähettää clientille korruptoituneita ympäristömuuttujia niin minä osoittelen kyllä silloin ensisijaisesti dhcp-serveriä. Toki client voi myös filtteröidä mitä laittaa ympäristöön (jos se muuttaa sitä ennen scriptien kutsua).
Ilman muuta ongelman "lähde" tässä tapauksessa on verkossa toimiva murrettu tai tietoisesti pahantahtoinen palvelin, joka vastailee dhcp-kutsuihin.

Mutta tietoturvaongelmat, jotka saattavat olla käyttäjän oman hallinnan ulkopuolella on lähtökohtaisesti vakavampia kuin omin toimin korjattavissa/hallittavissa olevat ongelmat. Tietoturvan lähtökohta (tai tavoite) on, että käyttäjä voi omin toimin tehdä koneestaan turvallisen (mihin ei tietenkään koskaan täysin päästä).

EIhän tämä bugi tietysti ainoa ongelma ole, jos kone sattuu saamaan dhcp-vastauksia pahantahtoiselta lähteeltä esim. avoimessa verkossa.

SuperOscar

  • Käyttäjä
  • Viestejä: 4063
  • Ocatarinetabellatsumtsum!
    • Profiili
    • Legisign.org
Vs: shellshock
« Vastaus #22 : 29.09.14 - klo:14.08 »
Mutta on hyvin vaikea uskoa, että tarkoituksella olisi luotu ominaisuus, joka suorittaa funktiomäärityksen perään ympäristömuuttujaan ympätyt komennot, koska muuten ympäristömuuttujiin asetettuja komentoja ei suoriteta. Eli tämä osa on mielestäni ihan selvästi bugi eikä "dokumentoimaton ominaisuus".

Toisaalta funktion määrittely voi vaatia ajamaan ne ohjelmat. Siinä mielessä voihan se olla ollut haluttukin ominaisuus, jonka turvavaikutuksia vain ei loppuun saakka ollut mietitty.

En tiedä enkä nyt ehdi tarkistaa, onko Bashissa samanlaista funktion viivästettyä latausta kuin zsh:ssa, missä ”autoload -U funktio” vain merkitsee funktion sisällön ladattavaksi silloin, kun sitä tarvitaan.
pöytäkone 1, NUC: openSUSE Leap 15.6, kannettavat 1–3: Debian GNU/Linux 12; pöytäkone 2: openSUSE Tumbleweed; RPi 1: FreeBSD 14-RELEASE; RPi 2: LibreELEC 11

kuutio

  • Vieras
Vs: shellshock
« Vastaus #23 : 29.09.14 - klo:16.19 »
Mutta on hyvin vaikea uskoa, että tarkoituksella olisi luotu ominaisuus, joka suorittaa funktiomäärityksen perään ympäristömuuttujaan ympätyt komennot, koska muuten ympäristömuuttujiin asetettuja komentoja ei suoriteta. Eli tämä osa on mielestäni ihan selvästi bugi eikä "dokumentoimaton ominaisuus".

Toisaalta funktion määrittely voi vaatia ajamaan ne ohjelmat. Siinä mielessä voihan se olla ollut haluttukin ominaisuus, jonka turvavaikutuksia vain ei loppuun saakka ollut mietitty.
Mahdollista? Totta kai (en mä väitä tietäväni, mitä koodaajan pään sisällä on liikkunut), mutta eikös lähes kaikissa tapauksissa olisi järkevintä laittaa ne "vaadittavat" komennot sinne funktion sisään?

Enkä mä ainakaan itse olis jättänyt tuollaista ominaisuutta dokumentoimatta, jos olisin sen tarkoituksella jostain syystä lisännyt.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: shellshock
« Vastaus #24 : 29.09.14 - klo:17.32 »
Tässä taas yhdenlaista näkemystä tähän:
https://weev.livejournal.com/409835.html

Sekä viimeisntä infoa Viestintävirastosta:
https://www.viestintavirasto.fi/tietoturva/tietoturvanyt/2014/09/ttn201409291547.html

SuperOscar

  • Käyttäjä
  • Viestejä: 4063
  • Ocatarinetabellatsumtsum!
    • Profiili
    • Legisign.org
Vs: shellshock
« Vastaus #25 : 29.09.14 - klo:18.47 »
Enkä mä ainakaan itse olis jättänyt tuollaista ominaisuutta dokumentoimatta, jos olisin sen tarkoituksella jostain syystä lisännyt.

Dokumentointi on ollut monessa isoksi kasvaneessa projektissa kompastuskivi – jopa koko UNIXia on aikanaan aiheesta moitittu siitä, että ainoa käyttöopas on ollut lähdekoodi ::)
pöytäkone 1, NUC: openSUSE Leap 15.6, kannettavat 1–3: Debian GNU/Linux 12; pöytäkone 2: openSUSE Tumbleweed; RPi 1: FreeBSD 14-RELEASE; RPi 2: LibreELEC 11

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: shellshock
« Vastaus #26 : 29.09.14 - klo:18.56 »
että ainoa käyttöopas on ollut lähdekoodi

En yhtään ihmettele, musta ainakin useissa projekteissa dokumentoinnin ylläpitäminen on kaikkein rasittavin homma, varsinkin jos sitä dokumentointia on liikaa, liian monessa paikassa ja niissä on cross referenssejä ja samaa asiaa moneen kertaan vähän eri tavalla. Jotain man tyylistä sivua vielä just pystyy ja jaksaa ylläpitää, mutta laajempi dokumentointi, uuh ääh. No sitä voi ylläpitää joku dokumenointi-osasto josta seuraa se, että dokumentointi on kuitenkin aina väärin.

Mä erityisesti vältän monesti dokumentoimasta asioita, joita pelkään että pitäisi jatkuvasti jatkossa päivittää. Kun asiakkaat ei kuitenkaan halua maksaa dokumentoinnin päivittämisestä jne.

AimoE

  • Käyttäjä
  • Viestejä: 2782
    • Profiili
Vs: shellshock
« Vastaus #27 : 29.09.14 - klo:19.15 »
Minulla oli joskus vaihe jolloin dokumentointi tökkäsi aina siihen kun aloin ihmetellä miksi mä tämmöstä joudun selostamaan - aika monta parannusta tuli tehtyä koodiin ihan vaan siksi ettei tarvi selitellä. Mutta se riippuu rojektista tietty.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: shellshock
« Vastaus #28 : 29.09.14 - klo:19.33 »
aika monta parannusta tuli tehtyä koodiin ihan vaan siksi ettei tarvi selitellä.

Toinen hyvä tyyli olisi pitää DRY asenteesta tiukasti kiinni. Aina kun jotain kysytään, jos se puuttuu dokumentaatiosta se lisätään sinne, eikä kysymyksiin vastata. Sitä kautta saisi järjestelmällisesti 'lazy' tyyliin saatettua dokumentaation ajantasalle. Eikä tarvitsisi vastata (samoihin) kyselyihin, uudelleen ja uudelleen.


AimoE

  • Käyttäjä
  • Viestejä: 2782
    • Profiili
Vs: shellshock
« Vastaus #29 : 29.09.14 - klo:20.07 »
Opiskeluaikana itselläni oli onni päätyä kesätyöhön jossa jouduin tekemään ylläpitoa, jossa ei ollut tarkoitus muuttaa toiminnallisuutta toiseksi. Tein siis puhtaita refactoring-muutoksia. Tein niitä isossa ohjelmistossa. Kaiken huipuksi annettu refactoring-tehtävä koski io-moduleiden kutsuja, eli jouduin korjausta tehdessäni pitämään silmällä ohjelmiston peruslogiikkaa. Jouduin tarkistamaan missä kohdassa luetaan indeksoitua tiedostoa peräkkäin pääavaimella, missä kohdassa sivuavaimella, jne. Minun piti huolehtia siitä että logiikka ei seonnut. Tämä harjaannutti hahmottamaan vierasta koodia tavalla jota en mitenkään muuten olisi voinut oppia. Ylläpito opettaa paljon enemmän kuin se että aina väännetään uutta koodia uusien hienojen menetelmien mukaan.

Tuosta kesätyöstä asti olen aina ajatellut että ihan jokainen ohjelmoija pitäisi opiskeluvaiheessa panna refactoring-sulkeisiin. Vain sillä taattaisiin että kukin oppii hahmottamaan ohjelmiston rakennetta ja laatimaan testitapauksia jatkuvaa testausta varten. Voi kai koodia hakea vaikka GitHubista ja käydä sitä läpi refactoring-tekniikalla vaikkei olisikaan aikeissa palauttaa korjauksia mihinkään, kunhan vaan ottaa sormituntumaa ihan harjoituksen vuoksi. Ja nyt kun eteen tulee näitä heartbleed ja shellshock -tapauksia, löydän itseni pohtimasta ihan vakavasti sitä kuinka paljon vikoja voitaisiin löytää ja korjata ihan ohimennen jos opiskelijoilla teetettäisiin refactoring-sulkeisia avoimen koodin kanssa.

Jossain määrin samaa voisi soveltaa dokumentteihinkin, ehkä.

ajaaskel

  • Palvelimen ylläpitäjä
  • Käyttäjä
  • Viestejä: 3401
    • Profiili
Vs: shellshock
« Vastaus #30 : 29.09.14 - klo:20.41 »
Lainaus
En tiedä enkä nyt ehdi tarkistaa, onko Bashissa samanlaista funktion viivästettyä latausta kuin zsh:ssa, missä ”autoload -U funktio” vain merkitsee funktion sisällön ladattavaksi silloin, kun sitä tarvitaan.
Ei ole vakiona mutta pystyy lisäämään erikseen "enable -f" kautta lisämodulina.

http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/x6632.html
Autamme ilolla ja ilmaiseksi omalla ajallamme.  Ethän vaadi, uhoa tai isottele näin saamasi palvelun johdosta.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: shellshock
« Vastaus #31 : 03.10.14 - klo:17.01 »
Tein siis puhtaita refactoring-muutoksia.

Tuo refactoring juuri kuten kuvasit, olisi todella hienoa. Mutta tämän asian saa yleensä menemään totaalisen pieleen ne asiakkaat. Yleensä mielenkiintoa maksaa määrittelyistä, dokumentoinnista, testaukseta, ei tahdo löytyä. Löytyy vain mielenkiintoa saada joku koodinkikkare tehtyä mahdollisimman halvalla ja nopeasti. Kukapa maksaisi refactoringista yhtään mitään, miksi kukaan haluaisi tehdä sitä, eihän sillä saavuteta mitään 'lisäarvoa'.

Yleensä tavoitteena on mm. lisätä uusia ominaisuuksia törkeillä kludgeilla mahdollisimman nopeasti. Sillä ei ole mitään väliä jos nuo tuottavat tietoturva tai suorituskyky ongelmia. Kunhan saadaan jotain 'toimivaa' nopeasti ulos.

Nimimerkillä, been there, done that.

Jos sanot että nyt haluttais käyttää 10-50 euroa siihen, että vähän mietiskellään tätä teidän koodia. Niin asiakkaat nauraa sut heti pihalle.

No niin foorumilaiset? Kuka haluaa sponsoroida Open Source / Linux koodin refaktorointia kymppitonnilla? Anyone? Luulen vaan että vähän hiljaista pitää.

Monesti puhutaan että IT projektien laatu on kuraa ja hommat tehdään vähän sinne päin ja huonosti. No kyllä, useinmiten se tuntuu olevan myös tilaajan ensisijainen tavoite, valitettavasti.

Tuollainen shellshockin kaltainen ominaisuus voi ihan hyvin tulla siitä että ääääh, ei hitto, tätä ei pysty hoitamaa nyt tämän kautta kun... Mutta hei, jos mä modaan tuota koodia niin että voin suorittaa siellä vapaavalintaista koodia, niin sitten voin syöttää datassa sen koodin ja voin tehdä tosi kätevästi kaikenlaisia virivirejä, mitä muut sanoi että on kauhean hankalaa muka tehdä. Jees, no niin, nyt tää on hoidettu, ähäkutti. ;)

Sitä siis saa, mitä tilaa. Lisäksi tuollaisen ominaisuuden implementointia voi jopa pitää suorastaan nerokkaana, kaikki muut tollot väitti että homma on jotenkin vaikeeta, mutta nyt sujuu nää asiat tosi kätevästi. Eikä enkä juuri siinä kyseisessä tilanteessa ollut mahdollista syöttää suoraan käyttäjien antamaa dataa.

Jos menet kertomaan että projektin tietoturvasertifiointi maksaa vaikka 50000 euroa, niin vastaus on hyvin nopeasti, että me ei tarvita sitä, eikä meitä kiinnosta. Kuhan se nyt vaan 'toimii'. Ja toimimisella ei todellakaan tarkoiteta mitään kokonaisvaltaista testausta, vaan sitä, että se jotenkuten täyttää liiketoiminta tarpeet, eikä aiheuta kohtuuttomia ongelmia, vaikka ei toimisikaan edes noiden osa-alueiden osalta ihan aukottomasti. Joten, ketä kiinnostaa tietoturva? Useimpia ei kiinnosta, piste. Tämä sama kuvio toistuu jatkuvasti uudestaan ja uudestaan, joten ei pitäisi todellakaan tulla kenellekään yllätyksenä.

AimoE

  • Käyttäjä
  • Viestejä: 2782
    • Profiili
Vs: shellshock
« Vastaus #32 : 03.10.14 - klo:17.14 »
Tein siis puhtaita refactoring-muutoksia.

Tuo refactoring juuri kuten kuvasit, olisi todella hienoa. Mutta tämän asian saa yleensä menemään totaalisen pieleen ne asiakkaat. Yleensä mielenkiintoa maksaa määrittelyistä, dokumentoinnista, testaukseta, ei tahdo löytyä.

Juuri siksi puhuinkin koulutuksesta - opiskelijoista, jotka eivät ole vielä kiinni noissa paineissa. Kun vanhaa koodia muokataan (onko sanalle refactoring kunnon suomennosta?), siinä nimenomaan oppii välttämään hölmöyksiä jotka pitää jälkeenpäin korjata. Oppii välttämään tyypillisimpiä ja harvinaisempiakin hölmöilyjä. Varsinkin niitä jotka tehdään jonkin hienon menetelmän nimissä. Omassa hommassani löysin aika paljon erilaisia historiallisia kerrostumia koodista, ja siinä todella oppi asioita joita ei voi oppia kirjoista lukemalla tai luentoja kuuntelemalla.

Mutta jotta homma toimisi koulutuksessa, tarvitaan opettajia jotka osaavat suunnitella refactoring-projektin oikein. Jokaisella refactoring-urakalla pitää olla selvä tavoite. Jos esimerkiksi haetaan vikaa, motivaatio refactoring-muutoksien tekemiseen loppuu heti kun vika on löydetty. Tiedän sen omasta kokemuksesta. Urakan pitää myös olla oikein mitoitettu. Jne jne jne. Uuden koulutusajattelun opettelussa on iso työ, mutta sillä olisi hyvin suuri tuottovaikutus pidemmällä tähtäimellä. Olisi yritysten etu vaatia sitä oppilaitoksilta. Mutta kuinkahan moni yritysjohtaja ymmärtää softatuotantoa sillä tasolla...

AimoE

  • Käyttäjä
  • Viestejä: 2782
    • Profiili
Vs: shellshock
« Vastaus #33 : 03.10.14 - klo:17.52 »
(onko sanalle refactoring kunnon suomennosta?)

Lähdin etsimään suomennosta ja löysinkin suomenkielistä keskustelua siitä miten refactoring ymmärretään väärin, siis että johtajien mielestä on ajanhaaskausta tehdä pelkkää refactoring-hommaa. Vitsi onkin siinä että pelkkä paljas refactoring on tuottavaa vain silloin kun hommaan pannaan kokematon jannu oppimaan. Mutta opetuksen tavoite olisikin se, että työelämässä, tai yhtä hyvin open source-projektissa, koodia tehdään sitten tehokkaasti. Tehokkaalla tarkoitan että ihan normaalissa koodauksessa aina jokainen versionhallintaan menevä muutos on joko puhdas refactoring-muutos (testataan regressiotestillä) tai puhdas toiminnallinen muutos (testataan uudella testitapauksella), ja käytännössä niitä refactoring-muutoksia tehdään pitkä sarja ennen kuin ollaan valmiita muutamaan uuteen toiminnalliseen muutokseen. Siis jos tehdään ihan täysin kurinalaisesti.

Open source -projekteista löytyy ihan varmasti hyvää materiaalia refactoring-koodauksen opetteluun.

John Hilly

  • Käyttäjä
  • Viestejä: 319
    • Profiili
Vs: shellshock
« Vastaus #34 : 03.10.14 - klo:19.02 »
Mites olisi suomennos refactoring - jälkituotteistaminen?

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: shellshock
« Vastaus #35 : 03.10.14 - klo:19.05 »
Mites olisi suomennos refactoring - jälkituotteistaminen?

Ei hyvä, tuolla kun ei ole tuotteistamisen kanssa mitään tekemistä.

AimoE

  • Käyttäjä
  • Viestejä: 2782
    • Profiili
Vs: shellshock
« Vastaus #36 : 03.10.14 - klo:19.35 »
Mites olisi suomennos refactoring - jälkituotteistaminen?

Ei hyvä, tuolla kun ei ole tuotteistamisen kanssa mitään tekemistä.


Joo, ei todellakaan mitään. Eikä oikeastaan edes olio-ohjelmoinnin kanssa, vaikka Martin Fowler käyttääkin Java-esimerkkejä kirjassaan Refactoring. Oliokielellä se on ehkä helpompaa, mutta kyllä vaikkapa muuttujia voi nimetä uudelleen ihan missä tahansa kielessä.

Koodinhuolto on hieman lähempänä, mutta huolto kuulostaa siltä että sitä tehdään erillään koodauksesta.