มีความปลอดภัยแค่ไหนในการรวบรวมซอร์สโค้ดจากคนแปลกหน้าแบบสุ่ม? [ปิด]


41

สมมติว่าฉันกำลังตรวจสอบรหัสที่ผู้สมัครงานส่งเพื่อพิสูจน์ทักษะของพวกเขา เห็นได้ชัดว่าฉันไม่ต้องการเรียกใช้โปรแกรมปฏิบัติการที่พวกเขาส่ง ไม่ชัดเจนฉันไม่ต้องการเรียกใช้ผลลัพธ์ของการคอมไพล์รหัสของพวกเขา (ตัวอย่างเช่นJava อนุญาตให้ซ่อนโค้ดที่รันได้ในความคิดเห็น )

สิ่งที่เกี่ยวกับการรวบรวมรหัสของพวกเขา? ฉันต้องการคอมไพเลอร์คำเตือนถ้ามี แต่จะเกิดอะไรขึ้นถ้ารหัสของพวกเขามีลำดับตัวละครที่ฉลาดซึ่งใช้ประโยชน์จากคอมไพเลอร์ของฉันและคอมไพเลอร์ของฉันประนีประนอมเครื่องของฉัน?

เมื่อฉันใช้ Google สำหรับ "ช่องโหว่ของคอมไพเลอร์" ความนิยมที่ฉันได้รับนั้นเกี่ยวกับการเพิ่มประสิทธิภาพคอมไพเลอร์และการปล่อยโค้ดและว่าโค้ดที่ปล่อยออกมานั้นปลอดภัยพอ ๆ กับซอร์สโค้ดดั้งเดิมหรือไม่

โดยทั่วไปแล้วคอมไพเลอร์จะได้รับการตรวจสอบเพื่อให้แน่ใจว่าพวกเขาจะไม่ประนีประนอมเครื่องของผู้ใช้เมื่อทำการรวบรวมโค้ดที่ฉลาด การรวบรวมโค้ดจากคนแปลกหน้าปลอดภัยแค่ไหน?


40
เพียงแค่ใช้เครื่องเสมือน ...
Florian Margaine

14
หากคุณกำลังตรวจสอบรหัสจริง ๆ แล้วมันก็ค่อนข้างยากที่จะรับบางสิ่งที่ยากพอ ๆ กับ "pwning the user machine" ผ่านโดยไม่สังเกตเห็นใช่ไหม?
RemcoGerlich

17
ดังนั้นคุณจะตัดสินทักษะของพวกเขาได้อย่างไร ฉันถามสิ่งนี้เพราะฉันมักจะตรวจสอบรหัสที่ส่งถึงเราโดยผู้สมัครงาน แต่ฉันเพิ่งอ่านเสมอไม่เคยรู้สึกว่าจำเป็นต้องดำเนินการใด ๆ
RemcoGerlich

9
Java อนุญาตให้ซ่อนโค้ดที่รันได้ในความคิดเห็น ไม่ใช่ Java IDEs ทั้งหมดที่ทำการแปลง Unicode เมื่อทำการเน้นไวยากรณ์ซึ่งไม่ใช่สิ่งเดียวกันจากระยะไกล
Pete Kirkham

68
อย่าแม้แต่อ่านรหัส พวกเขาสามารถโจมตีช่องโหว่ในสมองของคุณได้
Henrik

คำตอบ:


34

มันขึ้นอยู่กับ.

makefile ส่วนนี้สามารถลบไดเรกทอรีบ้านของคุณ:

all:
    rm -rf ~

ดังนั้นหากคุณต้องการใช้เครื่องมือ (เช่นระบบ cmake หรือ makefile) แสดงว่าไม่ปลอดภัย ขึ้นอยู่กับว่า coder เป็นอันตรายเพียงใด

ในอีกด้านหนึ่งคอมไพเลอร์ถูกโปรแกรมโดยคนดังนั้นพวกเขาจึงมีข้อบกพร่อง ดังนั้นอาจเป็นไปได้ว่าบางคนพบวิธีที่จะรันโค้ดที่เป็นอันตรายในระหว่างการรวบรวม

ตามที่แนะนำในความคิดเห็นหากคุณต้องการให้แน่ใจว่าไม่มีสิ่งที่ตลกทำกับเครื่องของคุณให้ใช้เครื่องเสมือน


32
"ใช้เครื่องเสมือน" - และหากคุณหวาดระแวงจริงๆโปรดจำไว้ว่าการใช้ประโยชน์จากข้อบกพร่องหลายอย่างมัลแวร์อาจไต่ขึ้นมาจาก VM ของคุณและบีบคอคุณ ( venom.crowdstrike.com )
Steve Jessop

23
@SteveJessop ใช่ใช้ VM ที่ซ้อนกันได้ดีกว่า;) โอกาสคือ coder ไม่ทราบว่าการแตกออกจาก VM หนึ่งเขาก็ยังอยู่ข้างใน
Ruslan

3
หรือเพียงใช้แล็ปท็อปเครื่องเก่าเพื่อทดสอบโค้ด ตราบใดที่มันไม่มีความสามารถด้านเครือข่ายคุณก็มั่นใจได้ว่ามัลแวร์จะไม่โดดออกไป นอกเสียจากว่าข้อบกพร่องของซอฟต์แวร์จะปรากฏเป็นข้อบกพร่องจริง ๆ อย่างแน่นอน
เสา

5
@Ruslan: แฮกเกอร์ส่วนใหญ่เห็น Inception
Steve Jessop

2
@Ruslan นี่คือแท็บที่ฉันเปิดก่อนหน้านี้: matrix.wikia.com/wiki/Matrix_in_a_Matrix_theoryที่ฉันอ่านเพราะคำถามที่ไม่เกี่ยวข้องในเว็บไซต์ SciFi SE
armani

23

ฉันค่อนข้างมั่นใจว่าบางแห่งในธุรกิจมีผู้ชายที่ฉลาดบางคนที่สร้างแฮ็คสำหรับภาษาเฉพาะและคอมไพเลอร์แล้ว สถานที่โปรดของฉันที่จะมองหาบางอย่างเช่นนี้อาจเป็นการประกวด International Obfuscated C - (ไม่ทราบว่ามีบางสิ่งที่เทียบเท่ากับ Java หรือไม่) อย่างไรก็ตามในความเป็นจริงคุณคิดว่ามีความเสี่ยงสูงแค่ไหน

  • ผู้สมัครสร้างความประทับใจที่มีเหตุผลกับคุณเขาต้องการงานที่ บริษัท ของคุณจริงๆ (ไม่ใช่คดี)

  • คนที่แต่งตัวประหลาดไม่ทราบว่าการตรวจสอบจะทำกับคุณมากเพียงใด

  • เขา / เธอไม่ทราบว่าคุณใช้คอมไพเลอร์เวอร์ชั่นใด

  • เขา / เธอไม่ทราบว่าคุณใช้สภาพแวดล้อมเสมือนจริงหรือคอมไพเลอร์ออนไลน์เพียงเพื่อความปลอดภัย

  • คุณไม่ยอมรับโปรแกรมที่มีขนาดใหญ่เกินกว่าที่จะตรวจสอบได้อย่างมีประสิทธิภาพ

  • คุณไม่ได้รวบรวมสิ่งที่น่าสงสัยสำหรับคุณ

  • มีคนไม่มากนักในโลกที่รู้วิธีการทำภารกิจดังกล่าวให้สำเร็จ (และ googling เพียงอย่างเดียวจะไม่ให้ "การอ้างอิงด่วน" หรือการสอนเกี่ยวกับสิ่งนี้ตามที่คุณได้ค้นพบแล้ว)

ดังนั้นแม้ว่าการรวบรวมจะไม่ "ปลอดภัยอย่างสมบูรณ์" ในทางทฤษฎี IMHO ในความเป็นจริงความเสี่ยงต่ำมากที่ "ผู้รวบรวมของคุณได้รับ pwned"


15
obfuscated เป็นสิ่งที่ดี เล่ห์เหลี่ยมจะดีกว่า underhanded-c.org

11
"ผู้สมัครต้องการทำงานที่ บริษัท ของคุณจริงๆ (ไม่ใช่คดี)" ไม่ชัดเจนว่าคนแปลกหน้าที่ส่งใบสมัครต้องการงานจริงๆ
คริสเตียน

@ คริสเตียน: แน่นอน แต่ฉันเดาว่า OP จะไม่ลงทุนตลอดเวลาในการตรวจสอบรหัสของผู้สมัครหากหลังไม่ได้เกิดขึ้นอย่างน้อยก็มีลักษณะที่เป็นไปได้เกี่ยวกับการของานของเขา และยังมีคนแปลกหน้าที่ไม่ต้องการถูกฟ้อง ประเด็นของฉันคือ: ทุกจุดที่กล่าวมาข้างต้นด้วยตัวเองอาจถูกหลบเลี่ยง แต่ทั้งหมดเข้าด้วยกัน? นั่นเป็นความเสี่ยงที่ค่อนข้างต่ำ
Doc Brown

13

เราต้องแยกแยะหลายกรณี:

  1. ข้อบกพร่องในคอมไพเลอร์ เช่นเดียวกับทุกโปรแกรมที่ซับซ้อนคอมไพเลอร์อาจมีข้อบกพร่องและหนึ่งในข้อบกพร่องเหล่านั้นอาจเป็นประโยชน์
  2. ม้าโทรจัน ผู้โจมตีอาจให้คุณรันโค้ดโดยอำเภอใจบางส่วนซึ่งเป็นส่วนหนึ่งของกระบวนการรวบรวม A Makefile, a build.xml, configureshell script ฯลฯ โดยทางเทคนิคนี่ไม่ใช่การรวบรวมรหัสของผู้โจมตี แต่เป็นการตั้งค่าสภาพแวดล้อมการคอมไพล์
  3. ภาษาที่อนุญาตให้ใช้รหัสโดยพลการในเวลารวบรวม ภาษามาโครของ Scala คือ Scala, ภาษามาโคร Lisp ทั่วไปคือ Common Lisp, ภาษามาโคร Haskell ของเทมเพลตคือ Haskell Scala ยังมีปลั๊กอินคอมไพเลอร์ซึ่งเป็นรหัสสกาล่าอีกครั้งที่ทำงานในเวลารวบรวม F # มีผู้ให้บริการประเภท
  4. ภาษาที่อนุญาตให้ทำการคำนวณทัวริง ณ เวลารวบรวม ระบบชนิดของ Scala และ Haskell นั้นสมบูรณ์แบบทัวริงเหมือนกับเทมเพลตของ C ++ คุณสามารถรับคอมไพเลอร์เพื่อทำการคำนวณทัวริงโดยพลการ ณ เวลารวบรวมรวมถึง แต่ไม่ จำกัด เพียงลูปไม่ จำกัด โปรดทราบว่าทัวริงสมบูรณ์เท่านั้นหมายความว่าคุณสามารถคำนวณทุกฟังก์ชั่นคำนวณทัวริงมันไม่ได้หมายความว่าคุณสามารถเข้าถึงระบบไฟล์หรือสิ่งที่ต้องการ แต่คุณสามารถสร้างโปรแกรมที่จะใช้เวลานานในการรวบรวม
  5. เวลาในการรวบรวมนานมาก ตัวอย่างเช่นกฎของ C # สำหรับการแก้ปัญหาการโอเวอร์โหลดนั้นซับซ้อนมากจนคุณสามารถเข้ารหัสปัญหา 3-SAT ใด ๆ ได้เช่นการแก้ปัญหาการโอเวอร์โหลด C # แน่นอนว่า 3-SAT นั้นเป็น NP-complete ที่มีชื่อเสียง กล่าวอีกนัยหนึ่งตามความรู้ปัจจุบันของเรามันเป็นไปไม่ได้ที่จะหาอัลกอริทึมที่มีประสิทธิภาพสำหรับการแก้ปัญหาการโอเวอร์โหลดใน C # คุณไม่สามารถรวบรวมได้นานนัก แต่มันไม่ได้ใช้โปรแกรมขนาดใหญ่ในการรวบรวมใช้เวลานานกว่าอายุการใช้งานของเอกภพซึ่งเป็นสิ่งเดียวกัน

# 4 และ # 5 จะให้ผลสูงสุดในการปฏิเสธการบริการ จวนคอมไพเลอร์ C ++ และสกาล่า จำกัด จำนวนของการเรียกซ้ำที่คุณสามารถทำได้เพื่อที่ว่ามันไม่ได้เป็นจริงที่เป็นไปได้ที่จะเขียนวง จำกัด ใน Scala นั้นเป็นเพียงข้อ จำกัด ในการนำไปใช้ แต่ใน C ++ มันได้รับอนุญาตอย่างชัดเจนจาก spec

# 2 ในทางเทคนิคอยู่นอกขอบเขตของคำถามเพราะคำถามเกี่ยวกับการรวบรวมรหัสไม่ทำงาน (OTOH มีคำถามเชิงลึก: หากการตรวจสอบประเภทโปรแกรม Haskell สามารถทำการคำนวณโดยทัวริงเป็นการรวบรวมหรือเรียกใช้โปรแกรมได้หรือไม่)

# 1 ไม่น่าเป็นไปได้ ในอีกด้านหนึ่งคอมไพเลอร์การผลิตมีความซับซ้อนมากดังนั้นโอกาสของข้อผิดพลาดจึงสูง ในอีกทางหนึ่งพวกเขาจะทดสอบอย่างเข้มงวดหลังจากทั้งหมดการจัดการการป้อนข้อมูลที่ไม่ดีขึ้นอย่างสง่างามเป็นส่วนหนึ่งของรายละเอียดงานของคอมไพเลอร์ แม้ว่าพวกเขาจะไม่ได้ทดสอบพวกเขาก็จะถูกโจมตีด้วยรหัสที่ไม่เหมาะสมแต่ทว่า ... ดูคำถาม StackOverflow สำหรับตัวอย่างของสิ่งที่ผู้คนทิ้งขยะใส่คอมไพเลอร์ของพวกเขา!

สิ่งนี้ทำให้เรามี 3 คอมไพเลอร์บางคนอาจ จำกัด ชนิดของการเข้าถึงรหัสเวลาคอมไพล์ที่มีต่อระบบ แต่สำหรับบางกรณีการใช้งานการเข้าถึงแบบเต็มไม่สามารถหลีกเลี่ยงได้ ตัวอย่างเช่นวัตถุประสงค์ของผู้ให้บริการประเภท F # คือประเภทสังเคราะห์ "ปลอม" สำหรับข้อมูลที่ระบบประเภทไม่ตรงกับ F # เพื่อให้คุณสามารถโต้ตอบพูดบริการเว็บที่มีสคีมา WSDL ในรูปแบบที่รุนแรง แฟชั่น. อย่างไรก็ตามในการดำเนินการนี้ผู้ให้บริการพิมพ์จำเป็นต้องเข้าถึงทรัพยากร WSDL schema บนระบบไฟล์หรือบนเว็บดังนั้นจึงจำเป็นต้องมีการเข้าถึงระบบไฟล์และเครือข่าย

ดังนั้นปลอดภัยหรือไม่ ในทางเทคนิคไม่มี มีความเสี่ยงหรือไม่? ไม่ได้จริงๆ


1
C ++ เป็นการจำกัดความลึกของอินสแตนซ์ของเท็มเพลตตามค่าการนำไปใช้งานบางอย่าง เคยเป็นไม่กี่โหล การใช้งานที่ทันสมัยได้เพิ่มขีด จำกัด ไปหลายร้อย ถึงกระนั้นก็ยังเป็นเรื่องเล็กน้อยที่จะเพิ่มจำนวนเทมเพลตเป็นสองเท่าต่อระดับดังนั้น 100 ระดับจะต้องใช้คอมไพเลอร์เพื่อสร้างแม่แบบ 2 ^ 100 นั่นเป็นเพียงแค่การโจมตี DoS
MSalters

3

ไม่ควรมีความเสี่ยงใด ๆ เพียงแค่รวบรวมรหัส ในทางทฤษฎีอาจมีข้อผิดพลาดในคอมไพเลอร์ที่แฮ็กเกอร์ที่ฉลาดสามารถใช้ประโยชน์จาก แต่ก็ฟังดูไม่น่าจะเป็นไปได้

โปรดทราบว่าอาคารอาจไม่ปลอดภัย ตัวอย่างเช่นใน C # 'build event' ช่วยให้คุณระบุบรรทัดคำสั่งโดยพลการเพื่อดำเนินการก่อนและหลังการสร้างซึ่งเห็นได้ชัดว่าเป็นอันตรายและง่ายต่อการใช้ประโยชน์มากกว่าการพูดบัฟเฟอร์มากเกินไปในโค้ดคอมไพเลอร์


3
Scala, Template Haskell, Lisps เกือบทั้งหมดสามารถรันโค้ดโดยพลการได้ในเวลารวบรวม ทุกภาษาที่มีระบบประเภททัวริงสมบูรณ์ (Scala, Haskell) สามารถทำการคำนวณแบบทัวริงได้ตามอำเภอใจ ณ เวลารวบรวมซึ่งรวมถึง แต่ไม่ จำกัด เฉพาะวงวนอนันต์ ระบบเทมเพลตของ C ++ นั้นเสร็จสมบูรณ์อีกครั้งทำให้คุณสามารถทำการ compution โดยพลการรวมถึงลูป infinite ในเวลาคอมไพล์ ความละเอียดเกินพิกัดของ C # นั้นเทียบเท่ากับ 3-SAT ดังนั้น NP-complete ซึ่งไม่ใช่ทัวริงสมบูรณ์ แต่จะยังให้คุณแขวนคอมไพเลอร์ตลอดชีวิตของจักรวาลหากคุณต้องการ
Jörg W Mittag

3
ระบบชนิดทัวริงสมบูรณ์ไม่อนุญาตให้คุณ pwn คอมพิวเตอร์ ที่แย่ที่สุดมันจะทำให้คอมไพเลอร์หยุดทำงานถ้าคุณเอาเปรียบมัน แต่ใช่ถ้าคุณมีภาษาที่ขั้นตอนการรวบรวมอาจใช้รหัสโดยอำเภอใจแล้วแน่นอนว่าคุณไม่ควรรวบรวมรหัสที่ไม่น่าเชื่อถือ
JacquesB

3

แทนที่จะคาดเดาฉันใส่ใจที่จะทำวิจัยบางอย่างในหัวข้อนี้ก่อนที่จะตอบกลับไปยังแหล่งข้อมูลที่เชื่อถือได้มากที่สุดที่ฉันสามารถนึกได้ ( CVE Details ) รายการที่ครอบคลุมของช่องโหว่ความปลอดภัยที่เปิดเผยต่อสาธารณะอาจเป็นสิ่งที่ดีที่สุดที่เราสามารถทำได้เพื่อประเมินระดับการคุกคามของซอฟต์แวร์ประเภทต่างๆ

ฉันไม่ได้ใช้เวลาในการอ่านเนื้อหาที่มีอยู่ทั้งหมดแต่ฉันเลือกคอมไพเลอร์ "หลัก" สองสามตัว IDE และตัวแก้ไขข้อความเพื่อให้เกิดการประเมินภัยคุกคามตัวอย่าง หากคุณจริงจังเกี่ยวกับการใช้งานซอฟต์แวร์ใด ๆ เลยอย่างน้อยคุณควรดูว่ามีภัยคุกคามใดบ้าง นอกจากนี้โปรดทราบว่าโดยทั่วไปแล้วซอฟต์แวร์รุ่นเก่ามักจะเป็นซอฟต์แวร์ที่ขายดีกว่าซอฟต์แวร์ที่ใหม่กว่าดังนั้นการใช้งานล่าสุดของสิ่งที่คุณใช้งานนั้นเหมาะอย่างยิ่ง

อันดับแรกเราสามารถดูที่เครื่องมือแก้ไขข้อความต่างๆ ดูเหมือนว่าบรรณาธิการที่ดีที่สุดนั้นเรียบง่ายที่สุด ถ้าคุณใช้ Linux เชลล์หรือ Notepad ถ้าคุณใช้ Windows บางสิ่งที่ไม่มีความสามารถในการจัดรูปแบบไม่มีการแยกวิเคราะห์เพียงแค่ดูข้อมูลแบบตรงไปข้างหน้าและยกเลิกการแยกวิเคราะห์โดยอัตโนมัติหากอักขระตัวเดียวอยู่นอกรูปแบบการเข้ารหัสปัจจุบัน แม้แต่ Notepad ++ ก็มีช่องโหว่อยู่เล็กน้อย หลีกเลี่ยงสิ่งที่ซับซ้อนเมื่อดูไฟล์ที่ไม่น่าเชื่อถือ

ประการที่สองเราสามารถดู IDEs หากคุณเลือกที่จะเปิดไฟล์ใน IDE คุณควรระวังว่า IDE บางตัวได้รายงานข้อบกพร่องแล้ว เห็นได้ชัดว่า Visual Studio มีการหาประโยชน์ผ่านกลไกส่วนขยายดังนั้นการเปิดโซลูชันอาจเป็นปัญหาได้ การหลีกเลี่ยง IDEs หลีกเลี่ยงปัญหาทั้งหมดระหว่างคุณและรหัสที่ไม่น่าเชื่อถือ การเกาะติดกับ VI นั้นปลอดภัยกว่ามาก

ประการที่สามเราสามารถดูคอมไพเลอร์จริง ฉันเรียกดูบางอย่างรวมถึง Adobe, Microsoft, Java และ GNU ของ C / C ++ และพบว่าโดยทั่วไปการพูดการคอมไพล์โค้ด (และแม้แต่การสร้างโดยสมมติว่าไม่มีไฟล์ที่สร้างขึ้นเอง) นั้นค่อนข้างปลอดภัย แต่คอมไพเลอร์แต่ละตัว มีช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้นจากการรันไบนารีที่คอมไพล์แล้ว กล่าวอีกนัยหนึ่งก็คือพวกเขาไม่สามารถนำระบบของคุณไปได้ง่ายๆโดยการรวบรวม แต่พวกเขาทำได้โดยใช้รหัส

ดังนั้นโดยสรุปสมมติว่าวิธีการจัดส่งไม่ได้ขโมยระบบของคุณ (เช่นไคลเอนต์อีเมลของคุณถูกแฮ็กหรือไดรฟ์ USB ที่ติดมานั้นติดไวรัส ... ) การอ่านซอร์สโค้ดและการคอมไพล์ซอร์สโค้ดน่าจะปลอดภัย . โดยการค้นคว้าซอฟต์แวร์เฉพาะของคุณคุณสามารถทำให้ปลอดภัยยิ่งขึ้นโดยพูดว่าการตรวจสอบไฟล์นั้นอยู่ในหน้ารหัสที่ถูกต้อง ฯลฯ การรันโค้ดควรทำบนฮาร์ดแวร์ที่คุณไม่สนใจ ไม่ใช่ VM แต่เป็นคอมพิวเตอร์ที่แตกต่างกันทั้งตัวโดยไม่มีการเข้าถึงเครือข่ายและไม่มีไฟล์หรืออุปกรณ์ภายนอกที่ละเอียดอ่อน แม้ว่าคุณจะคิดว่าคุณเข้าใจโค้ด แต่งานวิจัยง่าย ๆ ก็แสดงให้เห็นว่าแม้แต่คอมไพเลอร์ก็มีบั๊กที่อาจทำให้บัฟเฟอร์ล้นที่ซ่อนอยู่นั้นแอบซ่อนตัวจากด้านหลังและรันโค้ดตามอำเภอใจ แต่ถ้าคุณเลือกที่จะเรียกใช้หรือดีบักโปรแกรม การรวบรวมจริงควรปลอดภัย


2

ฉันจะเริ่มต้นด้วย "ตรวจสอบรหัสของพวกเขา" ทำไมจึงจำเป็นต้องเรียกใช้รหัสจริง

นอกจากนั้นยังมีคอมไพเลอร์ออนไลน์มากมายที่คุณสามารถใส่รหัสและคอมไพล์และ / หรือรันมันได้ คุณสามารถทำข้อกำหนดได้: มันรวบรวมในคอมไพเลอร์นี้และออนไลน์

นี่คือตัวอย่างของหน้าเว็บที่มีคอมไพเลอร์ออนไลน์ : คอมไพเลอร์ออนไลน์

รหัสสำหรับการตรวจสอบการสัมภาษณ์งานไม่ควรมีขนาดใหญ่ แต่อย่างใดสำหรับคุณที่จะไม่เข้าใจสิ่งที่เกิดขึ้น


3
"ทำไมจึงจำเป็นต้องเรียกใช้รหัสจริง" หากต้องการตรวจสอบว่าเป็นเรื่องที่ดีแน่นอนรีวิวเท่านั้นบอกคุณว่ามันเป็นความล้มเหลว :-) "ระวังข้อผิดพลาดในโค้ดด้านบน; ฉันได้พิสูจน์แล้วว่าถูกต้องเท่านั้นไม่ใช่ลองใช้" - Knuth
Steve Jessop

2

โดยทั่วไปแล้วคอมไพเลอร์จะตรวจสอบความถูกต้องเพื่อให้แน่ใจว่าพวกเขาจะไม่ส่งเครื่องผู้ใช้เมื่อทำการรวบรวมโค้ดที่ฉลาด

โดยทั่วไปแล้วมันซับซ้อนเกินไปและมักเขียนโดยใช้ภาษาที่ไม่สามารถพิสูจน์คุณสมบัตินี้ได้

อาจไม่ได้มีเจตนาที่เฉพาะเจาะจงนี้ แต่อย่างน้อยความคิดของคอมไพเลอร์ทดสอบฟัซซี่ก็เป็นที่รู้จักกันอย่างน้อยตอนนี้ LLVM สามารถทดสอบตัวเองได้ การทดสอบความตั้งใจที่จะจับการป้อนข้อมูลที่เกิดปัญหาคอมไพเลอร์เนื่องจากข้อบกพร่องคอมไพเลอร์จะมีแนวโน้มที่จะยังเปิดขึ้นข้อบกพร่องโหว่

โดยปกติคุณต้องดูว่าคอมไพเลอร์เฉพาะที่คุณสนใจนั้นได้รับการทดสอบหรือทดสอบแบบฟัซซี่เพื่อหาข้อผิดพลาดที่อาจเกิดขึ้นหรือไม่ Rule of thumb คือหากมีปัญหาใด ๆ ที่เลวร้ายยิ่งกว่าข้อยกเว้นหน่วยความจำที่ไม่ได้ตรวจสอบแล้วโดยไม่ต้องตรวจสอบรายละเอียดเพิ่มเติมคุณต้องพิจารณาความเป็นไปได้ที่ร้ายแรง

การรวบรวมโค้ดจากคนแปลกหน้าปลอดภัยแค่ไหน?

น่าเสียดายที่สตริงยาวเท่าไหร่ โดยหลักการแล้วอีเมลอาจใช้ประโยชน์จากโปรแกรมรับส่งเมลของคุณหรือซอร์สโค้ดอาจใช้ประโยชน์จากโปรแกรมแก้ไขข้อความหรือ cppcheck ก่อนที่จะถึงคอมไพเลอร์ของคุณ ข้อเสนอแนะของเซบาสเตียนในการแสดงความคิดเห็นในการใช้คอมไพเลอร์ออนไลน์นั้นค่อนข้างดี แต่แน่นอนว่าโค้ดต้องอยู่ในรูปแบบที่คอมไพเลอร์จะยอมรับ

ภาษาหรือคอมไพเลอร์ใด ๆ ที่มีสิ่งอำนวยความสะดวกสำหรับการเรียกใช้เวลารวบรวมรหัสทั่วไปนั้นเป็นที่สงสัยอย่างมาก เทมเพลต C ++ นั้นใช้งานได้อย่างสมบูรณ์ แต่ไม่มีการเข้าถึงระบบ (ตั้งใจ) ดังนั้นมันจึงค่อนข้างมีความเสี่ยงต่ำ BЈовићระบุmakeว่ามีความเสี่ยงสูงมาก (เนื่องจากมีการใช้งานโค้ดของคนแปลกหน้าเป็นเพียงว่าโค้ดที่เขียนขึ้นเป็นmakeภาษาไม่ใช่ใน C ++) หากคอมไพเลอร์จะทำงานsystemแล้วคุณจะอยู่ในเรือลำเดียวกัน ฉันเคยทำงานกับแอสเซมเบลอร์ว่าถ้าฉันจำได้ถูกต้องสามารถทำการคอมไพล์โค้ดเวลาโดยพลการ มันมีไว้สำหรับการคำนวณตารางการค้นหา แต่ฉันไม่คิดว่าจะมีอะไรทำให้คุณโทรออกได้

ในทางปฏิบัติหากรหัสดูโอเคสำหรับฉันและฉันคิดว่าฉันเข้าใจแล้วฉันจะพิจารณาว่ามีความเสี่ยงต่ำมากในการรวบรวมความเสี่ยงต่ำกว่าการพูดว่า "ท่องอินเทอร์เน็ตด้วยเบราว์เซอร์ที่ถูกล็อค" ฉันทำสิ่งที่เสี่ยงกว่าเป็นประจำบนเครื่องที่ใช้งานทั่วไปของฉัน แต่ส่วนมากฉันจะไม่ทำเช่นในห้องปฏิบัติการไวรัสหรือบนเซิร์ฟเวอร์ที่สำคัญ หากรหัสดูตลกหรือสับสนอย่างชัดเจนฉันอาจไม่เสี่ยงในการรวบรวมเพราะนอกเหนือจากความเสี่ยงมันอาจมีช่องโหว่ที่ซ่อนอยู่ในถังขยะที่อ่านไม่ได้มันเป็นรหัสขยะ รหัสที่อยู่ภายใต้รหัสผ่านทำได้ยาก แต่เป็นไปได้ รหัสซ่อนเร้นที่ pwns เครื่องผ่านทางคอมไพเลอร์ใช้ประโยชน์จากความต้องการที่จะมีไม่น่ารำคาญน้ำหนักบรรทุกปฏิบัติการเพื่อให้เป็นมากยาก

หากคุณต้องการตรวจสอบเพิ่มเติมลองถามคนที่เป็นเจ้าภาพรวบรวมคอมไพเลอร์ออนไลน์ หากยังไม่ได้ดำเนินการกับพวกเขา (ยกเว้นคุณมาถึงความสนใจของ NSA หรือเทียบเท่า) คุณสามารถสันนิษฐานได้ว่ามันจะไม่ทำเพื่อคุณ พวกเขาใช้ความพยายามในการใช้คอมไพเลอร์ในกล่องทรายที่เหมาะสมซึ่งอาจมีความพยายามมากกว่าที่คุณเต็มใจจะไป แต่อย่างน้อยพวกเขาก็สามารถบอกคุณได้ว่ากล่องทรายนั้นช่วยให้พวกเขาเดือดร้อนบ่อยแค่ไหน


เนื่องจากการทำงานของศาสตราจารย์ John Regehr ที่ University of Utah เสียงดังกราวและ gcc ต้องผ่านการทดสอบฟัซซี่ที่ค่อนข้างเข้มงวดทำให้เกิดข้อบกพร่องหลายร้อยข้อที่อาจทำให้คอมไพเลอร์หยุดทำงานหรือแม้แต่สร้างรหัสที่แตกต่างจากคอมไพเลอร์อื่น ๆ สิ่งที่จะมองหาคือบั๊กที่ยังคงเปิดอยู่และไม่ว่าจะเป็นภัยคุกคามเพียงพอหรือไม่
Phil Miller

@Novelocrat: เห็นด้วยและขอบคุณสำหรับข้อมูลที่เฉพาะเจาะจง ความกลัวของฉันอยู่ที่คอมไพเลอร์ทีม dev อาจประเมินข้อบกพร่องเป็นลำดับความสำคัญต่ำเพราะ "ไม่มีใครเลยที่จะเขียนโค้ดที่" และพวกเขายังไม่ได้รับการแก้ไขเลยในขณะที่เมื่อคุณกำลังความคิดของคอมไพเลอร์เป็นผู้ทำร้ายผิวคุณจะพิจารณา พวกเขาสำคัญ ใจคุณหวังว่าจะมีความภาคภูมิใจจะให้แน่ใจว่าคอมไพเลอร์นักเขียนจะไม่ปล่อยให้อะไรบางอย่างที่น่าอายเป็นขาตั้งหน่วยความจำล้นเขียน ;-)
สตีฟเจสซอพ

1

แม้ว่าโดยทั่วไปจะเป็นข้อกังวล แต่ฉันคิดว่าปัญหานี้ไม่มีอยู่เนื่องจากการตั้งค่า

ผู้สมัครส่งรหัสต้นฉบับมาให้คุณ มันเกิดขึ้นได้อย่างไรหรือทำไม?

เห็นได้ชัดว่ามีเพียงสามความเป็นไปได้:

  1. คุณให้ผู้สมัครได้รับมอบหมายเพื่อแก้ปัญหาเฉพาะ (ที่กำหนดไว้อย่างดี) เพื่อประเมินทักษะของเขา
  2. ผู้สมัครต้องการอวดสิ่งที่เขาเขียน
  3. ผู้ยื่นคำขอเป็นกระตุกหรือเป็นสายลับหรือบุคคลที่เป็นอันตรายและไม่สนใจที่จะได้รับการว่าจ้าง สิ่งที่เขาหวังคือคุณจะโง่พอที่จะเรียกใช้รหัสของเขา

ประมาณ 2) และ 3)

ความเสี่ยงหลักคือความแตกต่างระหว่าง 2) และ 3) โอกาสสูงว่าถ้าสิ่งที่เขาเขียนนั้นดูน่าสนใจมันเป็นสิ่งที่คุณสามารถได้รับซอร์สโค้ดสำหรับออนไลน์ (จากแหล่ง "เป็นกลาง") และคุณอาจคุ้นเคยกับมันอยู่แล้วหรือเป็นสิ่งที่คุณสวมใส่จริง ๆ ไม่ต้องการดูเพราะคุณจะละเมิดทรัพย์สินทางปัญญาของคู่แข่ง (อดีตนายจ้าง) คนหลังจะหมายความว่าคุณไม่ต้องการจ้างคนนั้นอยู่ดี
หากคุณสามารถรับแหล่งที่มาออนไลน์ทำเช่นนั้น หากคุณสามารถตรวจสอบผลงานของผู้สมัครกับซอฟต์แวร์ที่รู้จักกันดี (รวมถึงซอฟต์แวร์ที่เป็นกรรมสิทธิ์) โดยใช้ชื่อของเขาในเครดิตให้ทำเช่นนั้น
ในกรณีอื่น ๆ เพียงเพิกเฉยสิ่งที่เขาส่งมาให้คุณ มันอาจไม่คุ้มค่าที่จะดูหรือผิดกฎหมายหรือมีความเสี่ยงสูง

ประมาณ 1)

ผู้สมัครส่งบางอย่างให้คุณเพราะคุณมอบหมายงานให้เขา หากคุณมีความสามารถใด ๆ (ซึ่งฉันคิดว่าคุณทำ!) จากนั้นสำหรับการมอบหมายการเขียนโปรแกรมทั่วไป (... ที่คุณเลือกด้วยตัวเอง!) คุณจะสามารถบอกได้ว่ามันเป็นวิธีการแก้ปัญหาที่เป็นไปได้ โดยการดูซอร์สโค้ดน้อยกว่า 30 วินาที (น่าจะมากกว่า 10 วินาที)

หากคุณไม่สามารถบอกได้ว่าโปรแกรมนั้นอาจใช้งานได้ (หรือสิ่งที่กำลังทำอยู่) ภายใน 30 วินาทีผู้ที่เขียนมันไม่ใช่คนที่คุณต้องการจ้าง fullstop คุณต้องการคนที่เขียนโค้ดที่คนอื่นสามารถเข้าใจและรักษาได้ คุณไม่ต้องการให้ใครบางคนที่พยายามทำให้สมาร์ทมาหาคุณหรือคนที่ชนะการประกวด C ที่สับสนอย่างสม่ำเสมอ มันไม่สำคัญว่าโปรแกรมจะทำงานหรือไม่ ทันทีที่บุคคลอื่นไม่เข้าใจโค้ดมันจะไม่ "ทำงาน"
หากโปรแกรมดูเหมือนว่ามันอาจจะใช้งานได้ แต่คุณจะพบสิ่งใดที่มีลักษณะ "แปลก" (เช่น Java unicode escape sequences, สตริงตัวอักษรสตริง C ++ ดิบ, สิ่งที่ดูเหมือน trigraphs, อะไรก็ตาม) ให้ถือว่าการมอบหมายเป็น "ล้มเหลว", ย้าย ไปยังผู้สมัครต่อไป ไม่จำเป็นต้องรวมสิ่งที่ชอบไว้ใน 99% ของโปรแกรมทั้งหมด (และแน่นอนว่าไม่ใช่ในการมอบหมายของคุณ - ฉันควรหวัง) ดังนั้นหากคุณพบสิ่งที่ "แปลก" เช่นนั้นผู้สมัครไม่ใช่คนที่คุณต้องการจ้าง

หากรหัสผ่านการทดสอบครั้งแรกนั้นคุณอาจต้องใช้เวลาอีก 2-3 นาทีเพื่อดูให้ละเอียดยิ่งขึ้น หากคุณยังคงพอใจกับสิ่งที่คุณเห็นหลังจากนั้นคุณอาจเรียกใช้งานผ่านตัววิเคราะห์แบบคงที่และรวบรวมในเครื่องเสมือนในระดับการเตือนที่สูง

สิ่งนี้จะทำให้เกิดปัญหาที่คุณอาจพลาดขณะอ่านแหล่งที่มา (เช่นการเรียกใช้พฤติกรรมที่ไม่ได้กำหนดหรือการแปลงให้แคบลง)
การคอมไพล์ก่อนอื่นจะบอกคุณว่าผู้สมัครมีความขยันและใส่ใจในรายละเอียดหรือไม่ไม่มากนักว่าเขามีทักษะการเขียนโปรแกรมหรือไม่ เช่นเดียวกับการเขียนชื่อนายจ้างอย่างถูกต้องในใบสมัครของคุณและตรวจสอบ CV ของคุณก่อนที่จะส่งมอบให้คุณควรตรวจสอบให้แน่ใจว่าซอร์สโค้ดที่คุณส่งมานั้นคอมไพล์โดยไม่มีข้อผิดพลาด (และดีกว่าโดยไม่มีคำเตือน) หากมีคนล้มเหลวในการทำเช่นนั้นคุณไม่ต้องการจ้างเขา

ความเสี่ยงของสิ่งชั่วร้ายที่เกิดขึ้น ณ จุดนี้ (การใช้ประโยชน์จากคอมไพเลอร์และการแตกออกจาก VM) เป็นสิ่งที่ไม่ควรพิจารณาเนื่องจากคุณได้ทำการตรวจสอบความน่าเชื่อถือผ่านโค้ดแล้ว จะไม่เกิดขึ้น


0

หากเป็นไปได้ให้คุณกังวลนำเครื่องเก่าขึ้นมา (ไม่ใช่พวกเราส่วนใหญ่มีที่นั่งไม่กี่รอบ) ติดตั้ง Linux และคอมไพเลอร์เวอร์ชั่นปัจจุบันคัดลอกซอร์สโค้ดไปที่ถอดสายเคเบิลเครือข่าย (หรือปิด WiFi ) และทำการคอมไพล์ หากสิ่งที่น่ารังเกียจเกิดขึ้นมันจะไม่ส่งผลกระทบต่อสิ่งอื่น

และสำหรับมัลแวร์ใน Makefile ให้รันด้วยแฟล็ก -n (IIRC, RTMF) เพื่อดูว่ามันจะทำอะไรโดยไม่ทำเช่นนั้น

* ยกเว้นกรณีที่โปรแกรมเมอร์ของคุณเข้ารหัสมัลแวร์เพื่อให้รอการเชื่อมต่อใหม่ แต่ในกรณีนี้คุณก) เช็ดเครื่อง และ b) ส่งต่อเรซูเม่ของผู้ชายไปที่ NSA เพราะเขาสูญเปล่าในโลกธุรกิจ :-)


0

บรรทัดล่างคือว่ามีคือความเสี่ยง ความเสี่ยงมีขนาดค่อนข้างเล็กดังคำตอบอื่น ๆ ที่ทราบ แต่มีความเสี่ยง นั่นหมายความว่าคุณต้องถามคำถามสองข้อ:

  1. ฉันจะทำอย่างไรเพื่อลดความเสี่ยง
  2. ความเสี่ยงสูงพอที่ฉันควรจะใส่ใจไหม?

ข้อที่สองคือสิ่งที่คุณได้โพสต์ไว้ที่นี่ในคำถามนี้ แต่เป็นการเน้นที่ผิดสำหรับกรณีนี้โดยเฉพาะ คำตอบที่จะลดความเสี่ยงที่มีความชัดเจนและพร้อม: ไม่คอมไพล์รหัสบนเครื่องของคุณ คุณมีวิธีการรวบรวมสองวิธีที่ชัดเจนโดยไม่ต้องใช้เครื่อง:

  1. ใช้เครื่องเสมือน (ตามที่ @FlorianMargaine ชี้ให้เห็นทันทีในความคิดเห็น) คุณเพียงแค่ทำการจับภาพก่อนทำการคอมไพล์จากนั้นทำการคืนค่าสแน็ปช็อตเมื่อเสร็จสิ้น
  2. ใช้บริการโฮสต์ (เช่นคอมไพเลอร์ออนไลน์)

วิธีการลดความเสี่ยงของคุณเหล่านี้มีความชัดเจนราคาถูกและเข้าถึงได้ง่ายซึ่งไม่คุ้มค่าที่จะเสียเวลาไปกับการพยายามวิเคราะห์ความเสี่ยงที่มีขนาดใหญ่ เพียงแค่ทำอย่างใดอย่างหนึ่งของพวกเขาและทำได้ด้วย


0

Visual Studio จะเตือนคุณหากคุณเปิดโครงการจากสถานที่ที่ไม่น่าเชื่อถือ (e, g, ดาวน์โหลดหรือแบ่งปันเครือข่าย)

ตัวอย่างหนึ่งว่าการใช้ช่องโหว่นี้จะเป็นอย่างไรกับโครงการ WPF: คุณสามารถอ้างอิงคลาส. NET จาก XAML และเพื่อมอบ IntelliSense, VS load และเรียกใช้คลาสที่อ้างถึง ณ เวลาออกแบบ

นั่นหมายความว่าผู้โจมตีสามารถปล่อย. dll ที่เป็นอันตรายลงในไดเรกทอรี bin เปลี่ยนรหัสต้นฉบับด้วยรหัสที่ไม่เป็นอันตรายและในขณะออกแบบ DLL จะถูกดำเนินการ หลังจากการสร้างครั้งแรกของคุณทุกร่องรอยของไบนารีที่เป็นอันตรายจะหายไป

ดังนั้นแม้ว่าโค้ดที่ให้ไว้ทั้งหมดจะ "สะอาด" คอมไพเลอร์ก็ไม่มีข้อผิดพลาดและแน่นอนคุณไม่ต้องดำเนินการใด ๆ ด้วยตนเอง. EXE ที่ให้มาด้วยตนเอง (เพื่อความปลอดภัยจากการโจมตีเฉพาะนั้นคุณสามารถตรวจสอบให้แน่ใจว่าไม่มีไบนารีในไดเรกทอรีต้นไม้ก่อนเปิดโซลูชันจากนั้น VS จะแจ้งให้คุณสร้างโซลูชันก่อนที่จะให้ IntelliSense ในขณะออกแบบ)

เวกเตอร์ที่คล้ายกันอาจมีอยู่กับภาษา / OS อื่น ๆ


0

การอ่านซอร์สโค้ด: ปลอดภัยอย่างแท้จริง รวบรวมซอร์สโค้ด: ปลอดภัยโดยสิ้นเชิง การดำเนินการไบนารีที่รวบรวมได้: อืม ... นั้นขึ้นอยู่กับ

การคอมไพล์เป็นเพียงคอมพิวเตอร์ที่อ่านซอร์สโค้ดและการเขียนที่เทียบเท่าในรูปแบบไบนารี หลังจากรวบรวมคุณมีเอกสาร 2 ฉบับคือหนึ่งที่มนุษย์สามารถอ่านได้และอีกหนึ่งเครื่องที่อ่านได้โดยคอมพิวเตอร์ ถ้าคุณไม่ให้คอมพิวเตอร์อ่าน (เช่นเรียกใช้) เอกสารที่ 2 จะไม่มีอะไรเกิดขึ้น


3
คำอธิบายว่าทำไมการรวบรวมมีความปลอดภัยโดยสิ้นเชิง? หนึ่งสามารถ pwn เซิร์ฟเวอร์โดยการส่งข้อความที่สร้างขึ้นอย่างชาญฉลาด - ทำไมเขาไม่สามารถรวบรวมคอมไพเลอร์ด้วยการให้มันป้อนข้อมูลที่สร้างขึ้นอย่างชาญฉลาด?
sharptooth

2
ฉันคิดว่าคุณจะสังเกตเห็นรหัส crafter อย่างชาญฉลาดที่ออกแบบมาเพื่อหาช่องโหว่ในเซิร์ฟเวอร์หรือคอมไพเลอร์ แต่การทำสิ่งนี้ให้สุดขีดทำไมถึงเสี่ยงต่อการดูโค้ดเลย! มีหลายการหาประโยชน์ในการแก้ไขที่สามารถใช้ประโยชน์เพียงแค่มีการดูไฟล์
gbjbaanb

2
คำตอบนี้คือซึ่งพูดพล่อยๆทั้งหมด ไม่มีเหตุผลเลยว่าทำไมคอมไพเลอร์จะปลอดภัยโดยเนื้อแท้หรืออย่างน้อยก็ปลอดภัยกว่าสิ่งที่ทำได้ง่ายเช่นการตั้งค่าการเชื่อมต่อ SSL แต่เมื่อเร็ว ๆ นี้ห้องสมุดยอดนิยมก็มีช่องโหว่ ฉันจะเถียงว่าเพราะคอมไพเลอร์โดยทั่วไปไม่ได้ใช้ในสภาพแวดล้อมที่เป็นมิตร (เช่นอินเทอร์เน็ต) พวกเขาจะถูกตรวจสอบน้อยกว่าสำหรับช่องโหว่และดังนั้นจึงมีแนวโน้มที่จะมีพวกเขา
Dorus

1
ไม่แน่ใจเกี่ยวกับการคอมไพล์โค้ดอย่างปลอดภัย แม้แต่ใน Java ด้วย Maven (เช่น) ประมาทmvn packageสามารถดึงข้อมูลและทำงานด้วยปลั๊กอินเพิ่มเติมที่คุณอาจไม่รู้ได้ง่าย ฉันแน่ใจว่าเดียวกันสามารถนำไปใช้กับระบบการสร้างอื่น ๆ
บรูโน่

1
ภาษาทัวริงที่สมบูรณ์อาจอนุญาตให้โปรแกรมใช้เวลาในการคอมไพล์ไม่ได้หากคอมไพเลอร์ได้รับอนุญาตให้รันในระยะเวลาที่ไม่ จำกัดแต่คอมไพเลอร์จำนวนมากจะสร้างจำนวนเธรดที่ถูก จำกัด โดยไม่คำนึงถึงสิ่งใด ๆ โค้ดที่ถูกคอมไพล์หมายความว่าโหลด CPU จากการพยายามคอมไพล์ครั้งละหนึ่งโปรแกรมจะถูก จำกัด ปัญหาที่ใหญ่กว่านั้นอาจเป็นข้อกำหนดของพื้นที่ดิสก์ เป็นไปได้อย่างสมบูรณ์ว่าไฟล์ต้นฉบับ 1KB อาจสร้างรหัสวัตถุจำนวนมาก
supercat

-1

ฉันคิดว่าคุณกังวลเกี่ยวกับหนึ่งในสองรสชาติ:

  • มัลแวร์ที่มีความซับซ้อนและใช้ประโยชน์จากการโจมตี : ไม่น่าเป็นไปได้โดยเฉพาะอย่างยิ่งเพราะสิ่งเหล่านี้มีเป้าหมายอยู่ที่ฮาร์ดแวร์และ / หรือซอฟต์แวร์ที่เฉพาะเจาะจงและ [ตามคำถามของคุณ] ผู้โจมตีของคุณอาจไม่มีความรู้ระดับระบบ
  • สิ่งที่เข้ากับสภาพแวดล้อมของคุณ : คำสั่งการเล่นตลกที่เป็นอันตราย (เช่นการลบไดเรกทอรีบ้านของคุณ) หรือคำสั่งไม่แยแส / ไร้ความสามารถที่เปลี่ยนพฤติกรรมของระบบของคุณ (เช่นการเขียนเส้นทางตัวแปรสภาพแวดล้อมหรือเส้นทางใหม่)

บางคนได้แนะนำเครื่องเสมือนหรือระบบเก่า แต่ผมจะนำเสนอวิธีการแก้ปัญหาที่ง่ายมาก: คอมไพล์เป็นผู้ใช้ที่แตกต่างกันกับการลดสิทธิ์ / ที่แตกต่างกัน ง่ายกว่าการตั้งค่าเครื่องเสมือนหรือคอมพิวเตอร์เฉพาะ

หากไม่น่าเป็นไปได้ที่ระบบของคุณจะถูกโจมตีด้วยการคอมไพล์เวลารวบรวมให้เรียกคืนจากการสำรองข้อมูล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.