Kysymys:
Pitäisikö minun enää vaivautua puskurin ylivuotojen opettamiseen?
Fixee
2011-03-01 09:42:06 UTC
view on stackexchange narkive permalink

Opiskelijat ovat epäileviä siitä, että ei-suoritettavien pinojen sammuttaminen, kanariansaarten sammuttaminen ja ASLR: n sammuttaminen edustavat realistista ympäristöä. Jos PaX, DEP, W ^ X jne. Pysäyttävät tehokkaasti puskurin ylivuotohyökkäykset, onko niistä vielä arvokasta oppia?

@Fixee Tulen olemaan raa'asti rehellinen täällä, jos todella kyseenalaistat ajatuksen puskurin ylivuotojen opettamisesta, en todellakaan usko, että sinun pitäisi "opettaa" luokkaa turvallisuudesta. Koska puskurin ylivuotojen on oltava yksi alkeellisimmista ja yleisimmistä turvallisuushyödykkeistä, niiden tulisi olla olennainen osa minkä tahansa järjestelmän hyökkäyksen ymmärtämistä ja opettamista.
@mrnap Olen opettanut puskurin ylivuotoja ja shell-koodien kirjoittamista 13 vuoden ajan. Kuten useimmat ihmiset tietoturva-areenalla tietävät, tämä oli kerran haavoittuvuus # 5–10 vuotta sitten, ja muut heikkoudet ovat sen jälkeen syrjäyttäneet sen. Esitin yllä olevan kyselyn ammattilaisille näiden tekniikoiden opettamisen jatkuvasta arvosta (joka vie paljon aikaa), kun muut aiheet ovat yhä tärkeämpiä. Kritisoit minua edes kysymyksen esittämisestä: uskokaa minua, jos en kyseenalaista jatkuvasti opettamieni vaikutuksia, en tee työtäni.
@Fixee Ymmärrän mielipiteesi, mutta uskon silti alkuperäisen näkemykseni siitä, että ne ovat hyväksikäytön perustekijä. Jokainen, joka on ajan tasalla ja lukee mitä tahansa teollisuudesta tai ymmärtää tietoturvaa kaikin perustein, ymmärtää, että BO: t ovat olemassa niin kauan kuin huono koodaus on olemassa. Luulisin, että kyllä-kakofonian perusteella tämän seuraaminen olisi melko ilmeistä.
@mrnap Saamme 10 viikkoa opettaa turvallisuusluokan
@mrnap, onko selkeä vastaus selkeästi "KYLLÄ" vai ei, se on * aina * perusteltu kysymys. Itse asiassa joku, joka * ei * kyseenalaista jatkuvasti nykyistä tavanomaista viisautta, on se, jonka ei pitäisi opettaa luokkaa turvallisuudesta. Kuten me kaikki tiedämme, oletusten kyseenalaistaminen on yksi parhaista työkaluista työkalupakissamme ja johtaa useimmiten haavoittuvuuksien löytämiseen.
@avid sanoi hienosti! @mrnap,, huomioi myös usein kysytyt kysymykset: * Ole mukava. Kohtele muita samalla kunnioituksella kuin haluat heidän kohtelevan sinua. * :)
Mistä lähtien autosi käyttöjärjestelmä on käyttänyt PaX: ää?Milloin viimeksi näit NIC-laiteohjelmiston, jossa oli W ^ X?Näitkö koskaan MIPS32-reititintä, jossa on DEP?Vaikka suurilla turvotetuilla työasemilla ja palvelimilla voi olla nämä suojaukset, ** kaikki modernit laitteet eivät ole. **
Kahdeksan vastused:
#1
+49
ReinstateMonica Larry Osterman
2011-03-01 12:47:53 UTC
view on stackexchange narkive permalink

Ehdottomasti. ASLR ja DEP ovat perusteellisia puolustustoimia. On olemassa hyökkäyksiä, jotka voivat ohittaa ne kaikki (todellisessa esimerkissä, katso Peter Vreugdenhilin Pwn2Own-hyväksikäyttö, jota hän käytti IE: tä vastaan ​​).

Kaikki mitä tarvitset bypass ASLR for Windows on tietojen paljastamiseen liittyvä haavoittuvuus, joka ilmoittaa sinulle ladatun DLL-tiedoston perusosoitteen prosessissa (se oli ensimmäinen Vreugdenhilin hyväksikäyttö). Siitä voit käyttää ret-to-libc -hyökkäystä kutsumaan minkä tahansa kyseisen DLL: n toiminnon.

Viimeinen rivi: pinon (ja kasan) ylivuodot ovat ehdottomasti edelleen ajankohtaisia. Niitä on vaikeampaa hyödyntää kuin ennen, mutta ne ovat silti merkityksellisiä.

Muutamassa erityisessä tilanteessa puskurin ylivuotoja voi olla helpompi hyödyntää [muistin asettelu vuotojen, esim. ytimissä] (http://security.stackexchange.com/questions/69054/does-kaslr-really-provide-more-security-against-exploits). Heartbleedin aiheutti myös puskurin ylivuoto, ja tämä tapahtuu uudestaan, koska kirjoitamme edelleen ja jatkamme matalan tason koodin kirjoittamista laitteistoliitännöille ja käyttöjärjestelmäkirjastoille ...
#2
+18
AviD
2011-03-01 17:58:13 UTC
view on stackexchange narkive permalink

@ Larryn ja @ SteveS: n erinomaisen ytimekkään vastauksen lisäksi haluan tuoda esiin erittäin tärkeän asian:

Opiskelijat ovat skeptisiä siitä, että ei-suoritettavien pinojen sammuttaminen, kanarien sulkeminen ja kääntäminen off ASLR edustaa realistista ympäristöä.

Toivottavasti tämä pätee oppilaidesi järjestelmiin.
Muualla maailmassa tämä on kuitenkin valitettavasti edelleen hyvin yleistä. Niiden alustojen lisäksi, jotka eivät tue näitä, on aina huonosti rakennettuja tuotteita, jotka edellyttävät näiden sulkemista, käyttöjärjestelmän vanhemmat versiot ja jopa vain huonot väärät määritykset.
Ikävä hyvin realistinen, valitettavasti.

Kaiken tämän lisäksi 2 muuta kommenttia kouluttajalta:
1. Joku on rakennettava nuo puolustukset, eikö?
2. Vaikka oletettavasti he olisivat olleet oikeassa - tarvitset vain osoittimia C / C ++: ssa , ei tarkoita, että Java-kehittäjän ei pitäisi oppia miten nämä asiat toimivat tietokoneen sisällä, eikö?

+1 # 2: lle. Ehdottomasti kaivattu lisäys.
#3
+17
Thomas Pornin
2011-03-01 18:30:03 UTC
view on stackexchange narkive permalink

Kyllä. Sen lisäksi, että puskurin ylivuoto johtaa onnistuneeseen hyödyntämiseen, puskurin ylivuotojen täydelliset selitykset ovat aina loistava tapa osoittaa, kuinka sinun pitäisi ajatella turvallisuudesta. Sen sijaan, että keskityttäisit sovelluksen suorittamiseen, katso, mitä voidaan tehdä sovelluksen ajamiseksi raiteilta.

Puskurin ylivuoto on vika riippumatta pinon suorituksesta ja siitä, kuinka monta huutavaa kanaria asennat . Kaikki nämä turvaominaisuudet yksinkertaisesti muuttavat virheen seurauksia : etäkäytön sijaan saat "vain" välittömän sovelluksen kaatumisen. Sovelluksen kaatumisten (etenkin kauko-ohjattavien kaatumisten) välittäminen on parhaimmillaan erittäin huolimaton ohjelmointi. Ei kellossani!

Täydellisyyden vuoksi ei-suoritettavat pinot ja kanariansaaret eivät estä puskurin ylivuotoja; he vain sulkivat joitain helppoja tapoja hyödyntää puskurin ylivuotoja. Perinteinen puskurin ylivuoto tarkoittaa palautusosoitteen korvaamista osoittimella haitalliseen koodiin, joka ladataan osana puskurin ylivuotavaa dataa; haitallinen koodi suoritetaan, kun toiminto palaa. Suoritettava pino tarkoittaa, että hyökkääjä ei voi sijoittaa koodiaan pinoon (hänen on järjestettävä hyppy johonkin kirjastokoodiin, esim. execve () -toteutus vakiokirjastossa ). Kanariansaari estää paluuosoitteen käytön, jos pino-puskuri oli ylivuodossa (olettaen, että ylivuoto on "yksinkertainen": vierekkäinen tiedonkappale). Mutta ylivuoto voi myös korvata joitain muita tietoja, mukaan lukien toiminto-osoittimet (erityisesti C ++: n yhteydessä).

Suuri viesti, muutama lisäpiste: 1. Ihmisten on opittava kirjoittamaan vähemmän vikakoodia, ei sokeasti turvautumaan lievityksiin (kuten kirjoittaja oikein totesi, pinopohjaisia ​​puskurin ylivuotoja ei ole poistettu, vain vaikeutettu). 2. Kuinka heidän on ymmärrettävä, mitä DEP, ASLR tekevät, jos he eivät ymmärrä hyökkäyksiä, jotka ovat tehneet ensinnäkin nämä suojaukset tarpeellisiksi? 3. Virheiden etsiminen tekee heistä paremman kooderin, koska he luottavat vähemmän itseensä ja järjestelmään ja kiinnittävät siten huomiota käyttäytymiseen, joka tapahtuu paitsi silloin, kun asiat toimivat oikein, myös silloin, kun ne menevät pieleen.
#4
+10
Steve
2011-03-01 11:11:43 UTC
view on stackexchange narkive permalink

Ehdottomasti. Ei pitäisi riittää, että he tietävät, että nämä ovat ratkaisuja ongelmaan, heidän pitäisi tietää, miten ja miksi ne ovat ratkaisuja ongelmaan.

Kaikki alustat eivät myöskään tue näitä tekniikoita.

#5
+7
Jeremy Powell
2011-04-09 10:14:56 UTC
view on stackexchange narkive permalink

Täällä on jo hyviä vastauksia, joten en yritä peittää niitä uudelleen. Koska puhumme kuitenkin mekanismeista, jotka estävät puskurin ylivuotoa, haluaisin korostaa jotain, jonka haluat ehkä välittää opiskelijoille:

Pelkästään siksi, että ohjelma on kirjoitettu Java-muodossa, ei tarkoita, että puskurin ylivuotoja ei ole. Itse Java-virtuaalikonetta ei ole toteutettu Java-sovelluksessa; se on toteutettu (todennäköisesti) C tai C ++, jotka ovat yhtä alttiita puskurin ylivuoteille kuin muutkin ohjelmat.

Tämän lisäksi monia JVM: n toteutuksia on. Jokaisesta korjaamastasi on vielä kymmenen muuta, jotka ovat todennäköisesti edelleen haavoittuvia.

Toivon, että en vain kompastunut koko saippualaatikkoni läpi .... :-)

#6
+7
SunnyNewb
2012-07-06 16:15:49 UTC
view on stackexchange narkive permalink

Haluaisin vastata opiskelijan näkökulmasta, joka on äskettäin alkanut oppia perusteellisesti puskurin ylivuotohyökkäyksistä. Minulla oli samat huolenaiheet ja epäilin puskurin ylivuoto-iskujen oppimisen eduista, mutta kun otetaan huomioon, kuinka paljon olen oppinut pääsemään sen lihaan, olen erittäin iloinen, että päätin tehdä sen.

Minun on toistaiseksi pitänyt:

  1. oppia x86-kokoonpanoa - lähinnä Ubuntu-pohjainen
  2. oppia C-ohjelmointia
  3. Ryhdy ninjaksi gdb: llä
  4. Shell-koodin ymmärtäminen
  5. Etsi kaikki mahdolliset IT-turvallisuusfoorumit ja opi ohjelmistojen / käyttöjärjestelmien turvallisuuden parantaminen

Nämä taidot ovat hyvin siirrettävissä, enkä ole pahoillani. Valitettavasti minulla ei ole ketään, joka opettaa minulle tätä. Olen joutunut karkeasti selvittämään sitä video-oppailla ja esimerkkikoodeilla maisterihankkeelleni. Puskurin ylivuotohyökkäykset saattavat olla vähemmän tietoturvaongelmia kuin 5-10 vuotta sitten, mutta ne voivat varmasti toimia askeleena oppia monimutkaisemmista tai nykyaikaisimmista uhista.

#7
+3
pierce
2012-07-07 11:20:06 UTC
view on stackexchange narkive permalink

Ei, älä opeta puskurin ylivuotoja. Opeta muistivirheitä. Opeta hyödyntämään primitiivejä. Kyllä, heidän täytyy tuntea myös historia, mutta sen ei pitäisi viedä yli puolta luokasta. Sanon todellisista kotitehtävistä, että annat heille haasteita, joissa kaikki muistisuojaukset ovat käytössä, mutta ehkä heikentävät haavoittuvaa palvelinta. Jotkut muistinpaljastukset antavat vihjeitä erilaisiin siirtymiin.

Niiden tulisi myös ymmärrä, että monet muistisuojaukset ovat enimmäkseen temppuja, ja usein "satunnaiset siirtymät" eivät ole niin satunnaisia ​​kuin luulet niiden olevan. Heidän tulisi oppia tunnistamaan vikoja ja käyttämään vikoja, joita heidän on tunkeuduttava tuntemiinsa asioihin, jotta he voivat päästä kohti haluamiaan asioita.

Heidän tulisi ajatella toimintojen osoittimien korvaamista pikemminkin. kuin palautusosoitteet, ja hyppää tunnettuun suoritettavaan koodiin (ret2libc, ROP) pikemminkin kuin hyppää pinon / kasan kuorikoodiin.

#8
+1
Todd-ProNoob
2012-07-06 21:53:24 UTC
view on stackexchange narkive permalink

Koska olen opiskelija tuoreena c ++ -luokasta, kyllä, tiedän, että se ei ole sama .., mutta professorini kiinnitti erityistä huomiota puskurin ylivuotojen ja niiden estämisen opettamiseen, ja kannustan sinua todella jatka puskurin ylivuotojen opettamista kaikilla kursseilla, joilla opetat ohjelmointia. Se ei voi vahingoittaa heitä tekemään niin.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 2.0-lisenssistä, jolla sitä jaetaan.
Loading...