اٽڪل هڪ ڪمزوري ۾ ...

هڪ سال اڳ، مارچ 21، 2019، ۾ بگ باونٽي پروگرام Mail.Ru هڪ تمام سٺو آيو HackerOne ڏانهن بگ رپورٽ от وڌ ۾ وڌ. جڏهن هڪ صفر بائيٽ (ASCII 0) متعارف ڪرايو POST پيرا ميٽر ۾ هڪ ويب ميل API جي درخواستن مان جيڪو هڪ HTTP ريڊائريڪٽ واپس ڪيو، غير شروع ٿيل ميموري جا ٽڪرا ريڊائريڪٽ ڊيٽا ۾ نظر آيا، جن ۾ GET پيرا ميٽرز جا ٽڪرا ۽ ٻين درخواستن جا هيڊر. ساڳيو سرور.

هي هڪ نازڪ خطرو آهي ڇاڪاڻ ته ... درخواستون پڻ سيشن ڪوڪيز تي مشتمل آهن. ڪجهه ڪلاڪن بعد، هڪ عارضي حل ڪيو ويو جيڪو صفر بائيٽ کي فلٽر ڪيو (جيئن ته اهو بعد ۾ ظاهر ٿيو، اهو ڪافي نه هو، ڇاڪاڻ ته اتي اڃا تائين CRLF / ASCII 13، 10 انجڻ جو امڪان هو، جيڪو توهان کي هيڊرز کي ترتيب ڏيڻ جي اجازت ڏئي ٿو ۽ HTTP جواب جي ڊيٽا، اهو گهٽ نازڪ آهي، پر اڃا به ناپسنديده). ساڳئي وقت، مسئلو سيڪيورٽي تجزيه نگارن ۽ ڊولپرز ڏانهن منتقل ڪيو ويو ته بگ جي سببن کي ڳولڻ ۽ ختم ڪرڻ لاء.

Mail.ru ميل هڪ تمام پيچيده ايپليڪيشن آهي؛ مختلف فرنٽ-اينڊ/پئڪ-اينڊ حصن جو هڪ وڏو تعداد، ٻئي اوپن سورس (سڀني مفت سافٽ ويئر ڊولپرز جي مهرباني) ۽ اندروني ترقي يافته، جواب پيدا ڪرڻ ۾ ملوث ٿي سگهن ٿا. اسان nginx ۽ openresty کانسواءِ سڀني حصن کي خارج ڪرڻ ۾ مدد ڪئي ۽ ڪال ڪرڻ کان اڳ مسئلي کي مقامي بڻايو ngx.req.set_uri() هڪ OpenResty اسڪرپٽ ۾ جيڪو توقع جي مطابق عمل نه ڪيو ويو (جي اي ٽي پيراميٽر ذريعي null بائيٽ يا لائن فيڊ داخل ڪرڻ ngx_http_rewrite_module ۾ ٻيهر لکڻ سان، جيڪو، دستاويزن جي مطابق، استعمال ڪيو ويو آهي، ۽ اهو لڳي ٿو، بلڪل ساڳئي طريقي سان ڪم ڪرڻ گهرجي، ڪم نه ڪيو). ممڪن نتيجن کي ختم ڪيو ويو، فلٽرنگ کي ممڪن طور تي سختي سان شامل ڪيو ويو، ۽ سڀني ممڪن ویکٹر کي ختم ڪرڻ لاء فلٽرنگ جي تصديق ڪئي وئي. پر اهو ميکانيزم جيڪو ميموري جي مواد جي ليڪ ٿيڻ جو سبب بڻيو هڪ راز رهيو. هڪ مهيني بعد، بگ رپورٽ کي بند ڪيو ويو جيئن حل ڪيو ويو، ۽ بگ جي سببن جو تجزيو بهتر وقت تائين ملتوي ڪيو ويو.

OpenResty هڪ تمام مشهور پلگ ان آهي جيڪو توهان کي nginx اندر Lua اسڪرپٽ لکڻ جي اجازت ڏئي ٿو، ۽ اهو ڪيترن ئي Mail.ru منصوبن ۾ استعمال ڪيو ويو آهي، تنهنڪري مسئلو حل نه ڪيو ويو. ۽ ڪجهه وقت کان پوء، اهي آخرڪار ان ڏانهن واپس آيا، صحيح سببن، ممڪن نتيجن کي سمجهڻ ۽ ڊولپرز لاء سفارشون ٺاهڻ لاء. ماخذ ڪوڊ جي کوٽائي ۾ حصو ورتو Denis Denisov и نيڪولائي ارميشڪين. اهو معلوم ٿيو ته:

• nginx ۾، جڏهن صارف جي ڊيٽا سان ٻيهر لکڻ استعمال ڪيو وڃي ٿو، اتي ڪجهه ترتيبن ۾ ڊاريڪٽري ٽرورسل (۽ شايد SSRF) جو امڪان آهي، پر اهو هڪ ڄاڻايل حقيقت آهي ۽ ان ۾ جامد ترتيب جي تجزيه ڪندڙن طرفان معلوم ٿيڻ گهرجي. Nginx Amplify и گِڪسِي Yandex کان (ها، اسان اهو پڻ استعمال ڪندا آهيون، مهرباني). OpenResty استعمال ڪرڻ وقت، ھي خصوصيت ياد ڪرڻ آسان آھي، پر اھو اسان جي ترتيب تي اثر انداز نه ٿيو.

  تشڪيل مثال:

  location ~ /rewrite {
      rewrite ^.*$ $arg_x;
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  اثر

  curl localhost:8337/rewrite?x=/../../../../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

• نينگڪس ۾ هڪ بگ آهي جيڪو ميموري کي لڪائڻ جو سبب بڻائيندو آهي جيڪڏهن ٻيهر لکڻ واري لائن ۾ نول بائيٽ شامل آهي. جڏهن هڪ ريڊائريڪٽ جاري ڪيو ويندو آهي، nginx هڪ نئين ميموري بفر کي مختص ڪري ٿو جيڪو لڪير جي پوري ڊيگهه سان لاڳاپيل آهي، پر لڪير کي نقل ڪري ٿو اتي هڪ لائن فنڪشن ذريعي جنهن ۾ صفر بائيٽ هڪ لائن ٽرمينيٽر آهي، تنهنڪري لڪير صرف صفر تائين نقل ڪئي وئي آهي. بائيٽ؛ باقي بفر ۾ اڻڄاتل ڊيٽا شامل آهي. تفصيلي تجزيو ڳولي سگھجي ٿو هتي.

  تشڪيل جو مثال (^@ صفر بائيٽ)

  
  location ~ /memleak {
      rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  اثر
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...


• نينگڪس GET پيٽرولر کي سروس جي ڪردارن جي انجڻ کان بچائيندو آهي ۽ اهو ممڪن بڻائي ٿو ته صرف GET پيٽرولز کي ٻيهر لکڻ ۾ استعمال ڪيو وڃي. تنهن ڪري، اهو ممڪن ناهي ته nginx ۾ صارف-ڪنٽرول ٿيل پيٽرولن ذريعي انجڻ جو استحصال ڪرڻ. پوسٽ پيٽرولر محفوظ نه آهن. OpenResty توهان کي GET ۽ POST پيٽرولر ٻنهي سان ڪم ڪرڻ جي اجازت ڏئي ٿو، تنهنڪري جڏهن OpenResty ذريعي POST پيٽرولر استعمال ڪندي، خاص ڪردارن کي انجڻ ڪرڻ ممڪن آهي.

  تشڪيل مثال:

  location ~ /memleak {
      rewrite_by_lua_block {
          ngx.req.read_body();
          local args, err = ngx.req.get_post_args();
          ngx.req.set_uri( args["url"], true );
      }
  }
  
  location / {
      root html;
      index index.html index.htm;
  }
  

  نتيجو:

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Location: http://localhost:8337/{...может содержать secret...}
...


وڌيڪ ردعمل

مسئلو nginx ۽ OpenResty جي ڊولپرز کي ٻڌايو ويو، ڊولپر ان مسئلي کي nginx ۾ حفاظتي بگ نه سمجهندا آهن، ڇاڪاڻ ته nginx ۾ خود خاص ڪردارن جي انجڻ ذريعي غلطي کي استحصال ڪرڻ جو ڪو طريقو ناهي، درست ڪريو ياداشت جي ظاهر ڪرڻ 16 ڊسمبر تي شايع ٿيو. رپورٽ کان وٺي 4 مهينن ۾، OpenResty ۾ ڪابه تبديلي نه ڪئي وئي آهي، جيتوڻيڪ اتي هڪ سمجھ هئي ته ngx.req.set_uri() فنڪشن جو هڪ محفوظ نسخو گهربل هو. 18 مارچ 2020 تي اسان معلومات شايع ڪئي، 21 مارچ تي OpenResty جاري ڪيو نسخو 1.15.8.3، جيڪو URI جي تصديق کي شامل ڪري ٿو.

پورٽس ويگر لکيو سٺو مضمون ۽ OpenResty ۽ Nginx کان تبصرو ورتو (جيتوڻيڪ اهو تبصرو آهي ته ياداشت جو صرف هڪ ننڍڙو ٽڪرو بي نقاب ڪيو ويو آهي غلط ۽ گمراهه ڪندڙ آهي، اهو طئي ڪيو ويو آهي لڪير جي ڊيگهه هيٺ ڏنل نل بائيٽ ۽، واضح پابنديون جي غير موجودگي ۾. ڊگھائي، حملو ڪندڙ طرفان ڪنٽرول ڪري سگھجي ٿو).

پوءِ غلطي ڪهڙي هئي ۽ ان کي روڪڻ لاءِ ڇا ٿي سگهي ٿو؟

nginx ۾ ڪو بگ هو؟ ها، اهو هو، ڇاڪاڻ ته ميموري مواد کي لڪائڻ ڪنهن به صورت ۾ هڪ غلطي آهي.

ڇا OpenResty ۾ ڪو بگ ھو؟ ها، گهٽ ۾ گهٽ مسئلو OpenResty پاران پيش ڪيل ڪارڪردگي جي سيڪيورٽي جي تحقيق ۽ دستاويز نه ڪئي وئي آهي.

ڇا OpenResty سان ڪا ترتيب/استعمال غلطي هئي؟ ها، ڇاڪاڻ ته هڪ واضح بيان جي غير موجودگيء ۾، هڪ غير تصديق ٿيل مفروضو استعمال ڪيو ويو ڪارڪردگي جي سيڪيورٽي بابت.

10000 ڊالر جي فضل سان انهن مان ڪهڙن مسئلن ۾ حفاظتي خطرو آهي؟ اسان لاء، اهو عام طور تي اهم ناهي. ڪنهن به سافٽ ويئر ۾، خاص طور تي ڪيترن ئي حصن جي چونڪ تي، خاص طور تي جيڪي مختلف منصوبن ۽ ڊولپرز پاران مهيا ڪيل آهن، ڪو به ڪڏهن به ضمانت نه ٿو ڏئي سگهي ته انهن جي ڪم جون سڀئي خاصيتون ڄاڻايل ۽ دستاويز ٿيل آهن ۽ انهن ۾ ڪا به غلطي ناهي. تنهن ڪري، ڪنهن به سيڪيورٽي جي خطري کي يقيني بڻائي ٿي جتي اهو سيڪيورٽي کي متاثر ڪري ٿو.

ڪنهن به صورت ۾، اهو سٺو عمل آهي ته جيترو ممڪن هجي ان پٽ ڊيٽا کي عام ڪرڻ يا محدود/فلٽر ڪيو وڃي جيڪو ڪنهن خارجي ماڊل/API ۾ وڃي، جيستائين واضح هدايتون ۽ واضح سمجهه نه هجي ته اها گهربل نه آهي.

ايراتا

تجربي مان اڳوڻو مضمونٻوليءَ جي پاڪيزگي کي بچائڻ خاطر:

بگ انعام - بگ شڪار جو مقابلو
بگ رپورٽ - غلطي جي اطلاع
ريڊائريڪٽ ڪرڻ - ورجائي
کليل ذريعو - کليل ذريعو
غلطي - غلطين تي ڪم

جو ذريعو: www.habr.com