- DownloadManager ของ qBittorrent เพิกเฉยต่อข้อผิดพลาดการตรวจสอบใบรับรอง SSL มาประมาณ 14 ปี 6 เดือน ตั้งแต่ 6 เมษายน 2010 ถึง 12 ตุลาคม 2024 ทำให้โฟลว์ดาวน์โหลดหลายส่วนกลายเป็นพื้นผิวโจมตีในสถานการณ์ที่มีการดักกลางเครือข่าย
- ปัญหานี้ถูกกำหนดเป็น CVE-2024-51774 และการใช้ประโยชน์จำเป็นต้องมีการเข้าถึงแบบ MITM หรือ DNS spoofing
- เส้นทางที่ใช้ DownloadManager เช่น การค้นหา การดาวน์โหลด
.torrent, RSS feed, การดาวน์โหลด favicon ได้รับผลกระทบ และอาจยอมรับใบรับรองที่หมดอายุหรือเป็น self-signed ได้ - พรอมป์ติดตั้ง Python บน Windows และโฟลว์ RSS ตรวจสอบอัปเดต อาจนำไปสู่การดาวน์โหลดไฟล์ปฏิบัติการหรือการแก้ไขลิงก์อัปเดต หากการตอบกลับจาก URL ที่ฮาร์ดโค้ดไว้ถูกเปลี่ยน
- ผู้ใช้ควรอัปเกรดด้วยการ ดาวน์โหลด v5.0.1 ด้วยตนเองโดยตรงผ่านเบราว์เซอร์ มากกว่าการใช้พรอมป์อัปเดตภายในแอป
การข้ามการตรวจสอบใบรับรองที่ดำเนินมานานกว่า 14 ปี
- คลาส DownloadManager ของ qBittorrent เพิกเฉยต่อข้อผิดพลาดการตรวจสอบใบรับรอง SSL ทั้งหมดมาตั้งแต่ commit
9824d86เมื่อวันที่ 6 เมษายน 2010 - พฤติกรรมเริ่มต้นถูกเปลี่ยนให้ตรวจสอบใบรับรองใน commit
3d9e971เมื่อวันที่ 12 ตุลาคม 2024 - รุ่นแพตช์แรกคือ qBittorrent v5.0.1 ซึ่งออกมา 2 วันก่อนเวลาที่เขียนบทความ
- ปัญหานี้ถูกกำหนดเป็น CVE-2024-51774
- เงื่อนไขการใช้ประโยชน์คือ การเข้าถึงแบบ MITM หรือ DNS spoofing
พื้นผิวโจมตีขนาดกว้างที่ DownloadManager สร้างขึ้น
- ขอบเขตการใช้งาน DownloadManager กว้างมาก ทำให้การค้นหา การดาวน์โหลด
.torrent, RSS feed, การดาวน์โหลด favicon และอื่น ๆ ได้รับผลกระทบ - เส้นทางเหล่านี้อาจยอมรับใบรับรองที่หมดอายุ ใบรับรอง self-signed หรือใบรับรองที่เข้าข่ายทั้งสองอย่างได้
- เส้นทางผลกระทบหลักแบ่งเป็นการติดตั้ง Python บน Windows, การอัปเดตซอฟต์แวร์, RSS feed และพื้นผิวโจมตีของไลบรารีแตกไฟล์บีบอัด
การดาวน์โหลดไฟล์ปฏิบัติการในโฟลว์ติดตั้ง Python บน Windows
- บน Windows หากไม่ได้ติดตั้ง Python ที่ใหม่เพียงพอ qBittorrent จะแสดงหน้าต่างถามให้ติดตั้งหรืออัปเดต Python เพื่อใช้ปลั๊กอินค้นหา
- หากผู้ใช้คลิก Yes ซึ่งถูกเลือกไว้เป็นค่าเริ่มต้น หรือกด Enter โปรแกรมจะดาวน์โหลดไฟล์ติดตั้ง Python จาก URL ของ
python.orgที่ฮาร์ดโค้ดไว้ - หลังดาวน์โหลด qBittorrent จะเปลี่ยนชื่อไฟล์นั้นเป็น
.exeแล้วรัน จากนั้นลบไฟล์ชั่วคราวหลังเสร็จสิ้น - พฤติกรรมนี้มีอยู่ตั้งแต่ มิถุนายน 2015 จนถึงปัจจุบัน และกระทบตั้งแต่
v3.2.1ถึงv5.0.0 - ในระบบปฏิบัติการแบบอื่น หากไม่มี Python หรือไม่ใหม่พอ วิดเจ็ตค้นหาจะถูกปิดใช้งาน และดูเหมือนจะไม่เกิดพฤติกรรมเดียวกัน
- ไฟล์ปฏิบัติการอาจถูกบันทึกไว้ในเส้นทางอย่างเช่น
C:\Users\_user_\AppData\Local\Temp\is-G61QK.tmp - อาจเป็นเพราะพฤติกรรมของ
QProcessแต่สามารถเกิดเธรดของไฟล์ปฏิบัติการขึ้นสองเธรด โดยมีเพียงหนึ่งเธรดที่จบการทำงาน ส่วนอีกเธรดคงอยู่ในสถานะ sleeping
การแก้ไข URL ผ่าน RSS ตรวจสอบอัปเดต
- qBittorrent เวอร์ชัน Windows หรือ Linux ที่ติดตั้งแล้วจะตรวจสอบอัปเดตโดยค่าเริ่มต้นเมื่อรัน หากไม่ใช่ไฟล์
appImage - การตรวจสอบอัปเดตทำโดยดาวน์โหลด เอกสาร XML จาก URL RSS ของ Fosshub ที่ฮาร์ดโค้ดไว้ แล้วพาร์สข้อมูลรีลีสของโปรแกรม
- หากพบเวอร์ชันที่สูงกว่าเวอร์ชันที่กำลังรันอยู่ใน XML จะมีโฟลว์ที่ดึง update URL ออกมาและถามผู้ใช้ว่าต้องการไปยัง URL นั้นหรือไม่ โดยไม่มีการกรองหรือตรวจสอบแยกต่างหาก
- หากผู้ใช้ยอมรับพรอมป์ URL ดังกล่าวจะถูกเปิดด้วยเบราว์เซอร์เริ่มต้น
- ผู้ใช้จะคาดหวังไฟล์
.exeภายใต้บริบทความเชื่อถือว่าเป็นลิงก์ที่ซอฟต์แวร์จัดให้ - หากผู้โจมตีพาไปยังเว็บไซต์แชร์ไฟล์อย่าง mediafire ผู้ใช้อาจได้รับไฟล์ปฏิบัติการที่ผู้โจมตีควบคุมเสมือนเป็นการอัปเกรด
- เนื่องจาก qBittorrent เป็นโอเพนซอร์ส จึงง่ายที่จะเพิ่มฟังก์ชัน backdoor ลงในเวอร์ชันล่าสุดแล้วคอมไพล์ใหม่
- นักพัฒนามีคีย์สำหรับตรวจสอบลายเซ็นไบนารีให้ แต่จะมีผลป้องกันก็ต่อเมื่อผู้ใช้ตรวจสอบจริงและ ให้ความสำคัญกับผลการตรวจสอบที่ล้มเหลว
RSS feed และการแทรกลิงก์
- RSS feed ทั้งหมดที่แอปพลิเคชันพาร์สจะผ่าน DownloadManager จึงถูก hijack ได้
- URL ที่เหยื่อเข้าชมสามารถถูกสังเกตและรวบรวมเป็นรายการได้ และโดยธรรมชาติแล้ว RSS URL มักเป็นแบบคงที่และคงอยู่นาน
- องค์ประกอบ
linkของแต่ละรายการจะถูกพาร์สโดยตรง และอาจถูกดาวน์โหลดเมื่อผู้ใช้ดับเบิลคลิก - แม้ไม่มีการแก้ไขผ่าน MITM URL ใด ๆ ที่ผู้เขียนหรือผู้โจมตีที่ปนเปื้อน feed ใส่ไว้ใน RSS feed ที่ผู้ใช้สมัครรับ ก็อาจถูกเปิดได้ด้วยการดับเบิลคลิกเพียงครั้งเดียว
- CVE-2019-13640 เป็นช่องโหว่ที่เคยอนุญาตให้รันคำสั่งระยะไกลผ่าน shell metacharacter ในชื่อ torrent หรือพารามิเตอร์ tracker ปัจจุบัน และเมื่อผู้โจมตีแบบ MITM สามารถใส่ข้อมูลอันตรายใน RSS ได้ ความเสี่ยงจากการนำมาประกอบกันจึงสูงขึ้น
การดาวน์โหลดฐานข้อมูล GeoIP และพื้นผิวโจมตีการแตกไฟล์บีบอัด
- เมื่อรัน qBittorrent จะดาวน์โหลดและแตกไฟล์ ฐานข้อมูล MaxMind GeoIP แบบไบนารีที่มีนามสกุล
.gzโดยอัตโนมัติจาก URL ที่ฮาร์ดโค้ดไว้เป็นค่าเริ่มต้น - หากมีช่องโหว่ในการแตกไฟล์บีบอัดของ zlib ผู้โจมตีสามารถเล็งโจมตีพื้นผิวนี้ด้วยไฟล์ใดก็ได้ขนาดสูงสุด 64MB
- CVE-2022-37434 ที่ยกเป็นตัวอย่างเป็น buffer overflow ระดับ Critical คะแนน CVSS 9.8 ในปี 2022 แต่ในกรณีนี้ไม่ถูกนำมาใช้เพราะไม่มีการเรียกฟังก์ชัน
inflateGetHeader() - โค้ดที่พาร์สฐานข้อมูล MaxMind แบบไบนารีหลังแตกไฟล์ถูกป้องกันไว้อย่างดีในปี 2024 แต่ในอดีตไม่เป็นเช่นนั้น และอาจเคยมีพื้นผิวโจมตีเพิ่มเติม
- ใน commit หนึ่งของฟังก์ชัน
gzip::decompress()บัฟเฟอร์ปลายทางถูกเปลี่ยนจากการจัดสรรแบบสแตติกบน stack ไปเป็นการจัดสรรแบบไดนามิกบน heap และมีการตรวจสอบก่อนเขียน จึงไม่สามารถใช้ประโยชน์ได้
สถานการณ์โจมตีที่ทำให้อัตโนมัติได้
- URL ไฟล์ติดตั้ง Python และ URL RSS feed สำหรับอัปเดตต่างก็ถูก ฮาร์ดโค้ด ทำให้สคริปต์อันตรายในสภาพแวดล้อม MITM สามารถไล่หาเวอร์ชันที่มีช่องโหว่และโจมตีได้
- RSS feed URL ไม่มีเหตุผลที่จะถูกเข้าชมนอกเวลาที่ qBittorrent กำลังทำงาน จึงใช้เป็นลายนิ้วมือของซอฟต์แวร์ได้
- เนื่องจากไม่มีการตรวจสอบใบรับรอง ผู้โจมตีสามารถ spoof เซิร์ฟเวอร์เป้าหมายได้โดยไม่ต้องใช้การกระจายแบบ Man-On-The-Side ที่ซับซ้อนอย่าง QUANTUM
- ด้วยลักษณะของ URL ที่ฮาร์ดโค้ดไว้ ผู้โจมตีสามารถดักเฉพาะคำขอที่ qBittorrent ไม่ตรวจสอบได้ โดยไม่ทำให้เหยื่อเห็นคำเตือนจากการเชื่อมต่อปลอดภัยล้มเหลวในเบราว์เซอร์หรือแอปพลิเคชันอื่น
- หากใช้ตัวเลือก
-sของ mitmproxy ร่วมกับสคริปต์ Python จะทำให้อัตโนมัติสิ่งต่อไปนี้ได้- แทนที่ Python
.exeด้วยไฟล์ปฏิบัติการใดก็ได้: RCE ด้วยคลิกเดียว - แทนที่ URL ใน RSS อัปเดตของ qBittorrent โดยอัตโนมัติ: การ hijack เบราว์เซอร์/RCE ต้องมีปฏิสัมพันธ์จากผู้ใช้ระดับปานกลาง
- แทนที่ลิงก์ทั้งหมดหรือบางลิงก์ใน RSS viewer ของ qBittorrent: RCE จนถึงปี 2019, การ hijack การดาวน์โหลด
- แทนที่ Python
การอัปเกรดและวิธีเลี่ยง
- ต้องอัปเกรดเป็น qBittorrent v5.0.1
- แนะนำให้อัปเกรดด้วยการ ดาวน์โหลดด้วยตนเองโดยตรงผ่านเบราว์เซอร์ ไม่ใช่ผ่านพรอมป์อัปเดตภายในแอป
- ทางเลือกคือใช้ไคลเอนต์อื่นที่ไม่มีช่องโหว่นี้ เช่น Deluge, Transmission
- การโจมตีที่ต้องใช้ MITM ไม่ควรถูกมองว่าเป็นเพียงความเสี่ยงเชิงทฤษฎี และควรพิจารณาประวัติศาสตร์ล่าสุดกับกรณีจริงในบางประเทศ
- มีการติดต่อกับผู้ดูแล repository แล้ว แต่ไม่ได้รับคำตอบว่าตั้งใจจะออก GitHub Security Advisory หรือไม่
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
คลาส DownloadManager ของ qBittorrent เพิกเฉยต่อ ข้อผิดพลาดการตรวจสอบใบรับรอง SSL ทั้งหมดที่เกิดขึ้นบนทุกแพลตฟอร์มมาตลอด 14 ปี 6 เดือน นับตั้งแต่คอมมิต 9824d86 เมื่อวันที่ 6 เมษายน 2010
ดูค่อนข้างร้ายแรงทีเดียว
จุดที่สะดุดตาคือ นี่ไม่ใช่บั๊ก แต่เป็น “ฟีเจอร์”
void downloadThread::ignoreSslErrors(QNetworkReply* reply,QList errors) {
// Ignore all SSL errors
reply->ignoreSslErrors(errors);
}
https://github.com/qbittorrent/qBittorrent/commit/9824d86a3c...
ไม่ได้จะมองช่องโหว่นี้เป็นเรื่องเบา แต่ผมมองว่าการใช้เพียงชุดใบรับรอง TLS ที่ถูกต้องกับชื่อโดเมนที่ถูกต้องเป็นแนวป้องกันเดียวในเส้นทางที่ทำให้เกิด remote code execution ได้นั้นแทบจะเป็นหายนะ
อย่างน้อยถ้าแอปพลิเคชันดาวน์โหลดอะไรบางอย่างจากอินเทอร์เน็ตแล้วนำไปรัน ก็ควรตรึงไว้กับเวอร์ชันเฉพาะ และตรวจสอบ แฮช ของไฟล์ที่ดาวน์โหลดมาก่อนรัน
ถ้าอย่างนั้นก็หมายความว่า อัปเดตอัตโนมัติ เป็นไปไม่ได้หรือ?
ผมมองว่ามาตรฐานขั้นต่ำคือ การตรวจสอบลายเซ็น
ถ้าอัปเดตซอฟต์แวร์บ่อยพอ ก็น่าจะมีโอกาสเปลี่ยนคีย์ได้เพียงพอเช่นกัน
บน Windows สามารถใช้ ใบรับรอง code signing ในเครื่องมือ build แล้วให้ระบบปฏิบัติการตรวจสอบไบนารีที่ดาวน์โหลดมาได้
แต่ต้องใช้ timestamp server กับการเซ็นโค้ดด้วย ไม่เช่นนั้นจะพังหลังใบรับรองหมดอายุ
ในกรณีนี้ ผมมองว่าการตรวจแฮชทำได้ยากเพราะลักษณะของ การโจมตีแบบคนกลาง ที่อาจเกิดขึ้น
หากผู้โจมตีสามารถดูและแก้ไขเนื้อหาคำขอได้ การตรวจแฮชก็ไร้ประโยชน์นอกจากการยืนยันความสมบูรณ์เท่านั้น
โดยรวมแล้ว วิธีที่แอปเดสก์ท็อปส่งคำขออัปเดตอัตโนมัติหรือคำขอตรวจสอบไปยังโดเมนหนึ่ง ๆ ดูเหมือนยังไม่ได้รับความสนใจด้านความปลอดภัยมากพอ
ยังมีสถานการณ์อย่างผู้เขียนต้นฉบับเลิกต่ออายุโดเมนจนถูกยึดไปใช้ในทางร้ายด้วย ซึ่งผมยังไม่พบทางออกที่ดี
ถ้ารู้ได้ว่าตลอดราว 15 ปีที่ผ่านมา มีคนได้รับผลกระทบจากปัญหานี้จริง ๆ กี่คน ก็คงน่าทึ่ง
แม้ในด้านที่ค่อนข้างน่าสงสัยของอินเทอร์เน็ต ก็สงสัยว่า การตรวจสอบ SSL สำคัญแค่ไหนสำหรับผู้โจมตีที่สามารถกลืนไปกับฝูงชนได้
เหตุผลที่หลายอย่าง “แค่ใช้งานได้” ก็เพราะไม่มีใครสนใจ และเมื่อปัญหานี้ถูกฉายแสงแล้ว สถานการณ์สำหรับคนที่ไม่ อัปเดตอัตโนมัติ ก็มีแต่จะแย่ลง
โค้ดนี้มีหน้าที่ดาวน์โหลด Python จาก python.org และแม้จะใช้โจมตีได้ แต่คงต้องเจาะจงเป้าหมายมาก และน่าจะต้องมีสิทธิ์เข้าถึงเป้าหมายในระดับหนึ่งอยู่ก่อนแล้ว
หากจะใช้โจมตีด้วยวิธีอื่น ก็ต้องมีเรื่องอย่างการยึดโดเมน python.org ซึ่งทุกคนน่าจะสังเกตเห็น
ถ้ามีผลกระทบ ก็น่าจะเป็น การโจมตีแบบเจาะจงเป้าหมาย เป็นส่วนใหญ่
บทความส่วนใหญ่ให้ความรู้สึกว่าถูกขยายเกินจริง และใช่ มีบางอย่างผิดปกติ แต่คำว่า “qBittorrent remote code execution” ถึงแม้จะถูกต้องทางเทคนิค ก็ เตือนภัยเกินไป
ดูเหมือนแทบเป็นไปไม่ได้ที่จะได้ข้อมูลจริง แต่ถ้าเห็นได้ก็คงน่าสนุก
ถ้าเคยดูโค้ด qBittorrent จะรู้ว่ามันเป็น โค้ดที่เลวร้ายมาก จริง ๆ
ฟังก์ชันที่ไม่มีคอมเมนต์ยาวต่อกันหลายหน้า ระยะบรรทัดก็แน่นเอี๊ยด และดูเหมือนบันทึกในคุกของผู้ป่วยจิตเวชที่ถูกคุมขังอย่างไม่เป็นธรรม
แค่ส่วนเล็ก ๆ ที่ผมเห็น ประมาณไม่กี่หน้าที่อัดแน่น ก็ไม่มีการตรวจสอบค่าที่คืนกลับมาเลย
จำได้ว่าถ้าใส่ค่าที่ถูกต้องแบบ 3 ตัวอักษรลงในฟิลด์หนึ่งแทนค่าที่ถูกต้องตามปกติแบบ 2 ตัวอักษร โปรแกรมจะ crash หลังจากนั้นราวหนึ่งนาที
เมื่อประมาณ 20 ปีก่อนผมเคยรับเงินเขียนโปรแกรม C++ อยู่สองครั้ง และหลังได้รับข้อความจากผู้ดูแลว่า “งั้นลองไปดูเองสิ” ผมก็เอาไปรันในดีบักเกอร์
ผมตามไปจนถึงจุดที่ค่าไม่ถูกต้องและค่าถูกต้องถูกอ่านจาก GUI ได้ แล้วพอตามค่านั้นต่อไป ก็พบว่า -1 ถูกส่งต่อไปทั่ว และโปรแกรมก็ยังเดินหน้าต่อไปอยู่พักหนึ่ง
สุดท้ายฝั่งที่รันด้วยค่าผิดก็ crash ในฟังก์ชันที่ค่อนข้างไกลออกไป พร้อมข้อความผิดพลาดที่เหมือนมาจากผู้ป่วยจิตเวชที่ถูกคุมขังอย่างไม่เป็นธรรม
หลังจากนั้นหนึ่งในนักพัฒนา qBittorrent ตัวจริงก็แก้ในรีลีสถัดไป แต่ไม่ว่าอย่างไร โค้ดก็เป็นแบบนั้น
ระบุไว้แค่ว่า “BUGFIX: Don't ignore SSL errors (sledgehammer999)”
https://www.qbittorrent.org/news
โดยส่วนตัวผมคิดว่าควรมี ประกาศด้านความปลอดภัย
ต่อให้ตรวจสอบใบรับรองถูกต้อง การดาวน์โหลดไฟล์ปฏิบัติการจากระยะไกลแล้วรัน ตามนิยามก็เป็น ช่องโหว่ remote code execution อยู่ดี
Syncthing ก็ใช้วิธีนี้ ซึ่งคงตรวจสอบใบรับรองอยู่ แต่การอัปเดตอัตโนมัติแบบไร้คนดูแลนั้นในเชิงตรรกะยากจะแยกจาก RAT/โทรจัน
ส่วนที่เป็นช่องโหว่จะเกิดขึ้นเมื่อบุคคลที่สามสามารถนำไปใช้โจมตีได้
ยังไงก็ต้องเชื่อใจผู้ให้บริการซอฟต์แวร์อยู่แล้ว ดังนั้นการอัปเดตอัตโนมัติเองไม่ได้เท่ากับช่องโหว่ remote code execution
แม้จะไม่ใช่สาเหตุโดยตรงของช่องโหว่นี้ แต่แอปพลิเคชันประเภทนี้ที่สื่อสารกับโหนดจำนวนมากซึ่งอาจเป็นอันตราย น่าจะได้ประโยชน์จาก ความปลอดภัยของหน่วยความจำ อย่างมาก
แต่ implementation ปัจจุบันดูเหมือนจะเขียนด้วย C++ ทั้งหมด
ในบทความก็พูดถึงความเป็นไปได้ของช่องโหว่ประเภทนี้ในข้อ 4 ด้วย
แม้แต่ Deluge ที่เขียนด้วย Python ก็ยังพึ่งพา libtorrent ที่เป็น C++
ไม่แน่ใจว่ามีฟอร์กสมัยใหม่ของไคลเอนต์ Azureus เดิมที่เคยใช้ Java หรือไม่
ทุกวันนี้ไคลเอนต์ BitTorrent จำนวนมากแยก GUI ออกจากโปรเซส daemon ที่รับผิดชอบการประมวลผลทอร์เรนต์จริง ดังนั้นถ้าทำ daemon ด้วย Java แล้วเชื่อมกับ GUI แบบเนทีฟ ก็อาจได้สมดุลที่ดีระหว่างความปลอดภัย ประสิทธิภาพ และประสบการณ์ผู้ใช้
ลองค้นคร่าว ๆ ก็เจอ ไลบรารี BitTorrent แบบ Go ล้วน อยู่หลายตัว
มี rqbit ที่เขียนด้วย Rust และไม่พึ่งพา libtorrent: https://github.com/ikatson/rqbit
ถ้าจะถามแบบขี้เกียจแทนที่จะไปค้นเองเพื่อเอามาคุยกัน หากจะสร้างทางเลือกแทน libtorrent ควรเริ่มจากตรงไหนดี?
อยากรู้ด้วยว่าเคยมีความพยายามหรือกรณีที่สำเร็จบ้างไหม และมีไคลเอนต์ที่ใช้งานได้จริงซึ่งใช้ implementation อื่นหรือเปล่า
โดยเฉพาะยิ่งไปถึงรายการท้าย ๆ ยิ่งดู พูดเกินจริง ไปหน่อย
ข้อ 1 “ตัวโหลดไฟล์ปฏิบัติการอันตรายพร้อมฟังก์ชันซ่อนตัว” ก็คือเรื่องที่ไคลเอนต์ดาวน์โหลด Python จาก python.org ผ่าน HTTPS
มันไม่ดีแน่ และโดยเฉพาะการ hard-code ไว้ที่ 3.12.4 ก็เป็นปัญหา แต่ยังไม่เห็นเส้นทางโจมตีที่ชัดเจนซึ่งไม่ต้องอาศัยทั้งการโจมตีแบบคนกลางและการโต้ตอบจากผู้ใช้
ข้อ 2 “ยึดเบราว์เซอร์ + ดาวน์โหลดไฟล์ปฏิบัติการ” ก็คือเรื่องที่ไคลเอนต์ดาวน์โหลดไฟล์ RSS ผ่าน HTTPS แล้วถามผู้ใช้ตามเงื่อนไขว่าจะเปิด URL ในไฟล์นั้นหรือไม่
ความเสี่ยงต่ำกว่าข้อ 1 อีก และแม้จะโจมตีผู้ใช้แบบคนกลางแล้วหลอกให้คลิก “update” ได้ ท้ายที่สุดสิ่งที่แสดงได้ก็เป็นแค่หน้าเว็บเท่านั้น
ข้อ 3 “แทรก URL ใดก็ได้ในฟีด RSS” ดูเหมือนนักวิจัยจะสับสนกับพฤติกรรมที่คาดหวังของไคลเอนต์ RSS
ข้อ 4 “พื้นผิวการโจมตีของไลบรารีคลายการบีบอัด” ถ้าหาช่องโหว่ zlib ได้ ก็เอาไปทำเรื่องที่แย่กว่าการโจมตีไคลเอนต์ทอร์เรนต์ได้มาก
การคลายการบีบอัดอินพุตโดยพื้นฐานถือว่าเป็นงานที่ปลอดภัย
สิ่งที่นึกออกทันทีคือเซิร์ฟเวอร์ HTTP ที่รองรับ stream compression
ใช่
ไม่อยากพูดในแง่ลบเกินไป แต่ดูเหมือน “นักวิจัย” ด้านความปลอดภัยจะคว้าแม้แต่ความเป็นไปได้ที่ริบหรี่สุด ๆ เพื่อชื่อเสียงเล็กน้อย
ถ้าเขียนเอกสารอย่างตรงไปตรงมาคงน่าเคารพกว่านี้ แต่วิธีที่ทำตรงนี้มีแต่ทำให้ขมวดคิ้ว
ถ้าไม่ได้เพิกเฉยต่อข้อผิดพลาดของใบรับรอง รายการเหล่านั้นก็คงเป็นเรื่องเล็กน้อย
เนื่องจากปัญหาดั้งเดิมอยู่ที่การเพิกเฉยต่อข้อผิดพลาด SSL ในทางปฏิบัติจึงเท่ากับว่าการดาวน์โหลดผ่าน HTTPS ทั้งหมดถูก ลดระดับ เป็นการดาวน์โหลดผ่าน HTTP และโจมตีได้แม้ไม่มีการโจมตีแบบคนกลาง
พูดอีกอย่างคือ การไม่มีการตรวจสอบ SSL ทำให้ URL แบบ HTTPS ให้ความสบายใจผิด ๆ แก่ผู้ตรวจสอบราวกับว่ามีความปลอดภัย
เห็นด้วย
การเรียกสิ่งนี้ว่า “ช่องโหว่การรันโค้ดจากระยะไกล” นั้นพูดเกินจริงอย่างเหลือเชื่อ
คราวหน้าจะบอกว่าเว็บเบราว์เซอร์มี “ช่องโหว่การรันโค้ดจากระยะไกล” เพราะมันยอมให้ดาวน์โหลดและรันโปรแกรมจากเว็บไซต์ใด ๆ ที่อาจปลอดภัยหรือไม่ปลอดภัยก็ได้หรือเปล่า?
หรือจะประกาศใหม่ด้วยไหมว่าถ้าอยู่ในประเทศเผด็จการ รัฐบาลก็อาจทำเรื่องไม่ดีได้?
qBittorrent เป็นไคลเอนต์ที่ ประสิทธิภาพดีกว่า 1000 เท่า เมื่อเทียบกับตัวเลือกอื่น ๆ ที่กล่าวในบทความ น่าตกใจที่คุณภาพของปัญหาเหล่านี้ต่ำขนาดนี้
ตัวที่ทำให้ได้ประสิทธิภาพคือ libtorrent-rasterbar(libtorrent.org)
หากต้องการคอมไพล์และรันเวอร์ชันล่าสุด https://github.com/userdocs/qbittorrent-nox-static เป็นสคริปต์ช่วยที่ดีซึ่งใช้ Docker สร้าง ไบนารีแบบสแตติก ให้
ผมอยากรัน 5.0.0 โดยใช้ libtorrent 1.2 และสคริปต์นี้เป็นวิธีที่ง่ายที่สุดอย่างท่วมท้น