זהו מאמר מערכת של שינובי, מחנך אוטודידקט בחלל הביטקוין ומנחה פודקאסט ביטקוין בעל אוריינטציה טכנולוגית.
בפעם השנייה בתוך כחודש, נוצל באג ב-btcd/LND שגרם להם לסטות בקונצנזוס מ-Bitcoin Core. שוב, בורק היה המפתח שהפעיל את הפגיעות הזו - הפעם ברור שזה היה מכוון - ושוב, זו הייתה בעיה עם קוד לניתוח עסקאות ביטקוין מעל שכבת הקונצנזוס. כפי שדיברתי בשלי חלק על הבאג הקודם שבורק הפעיל, לפני Taproot היו מגבלות על גודל התסריט והעדים בעסקה. עם ההפעלה של Taproot, המגבלות הללו הוסרו והותירו רק את המגבלות על מגבלת גודל הבלוק עצמו כדי להגביל את החלקים הללו של עסקאות בודדות. הבעיה עם הבאג האחרון הייתה שלמרות העובדה שקוד הקונצנזוס ב-btcd שודרג כהלכה כדי לשקף את השינוי הזה, הקוד המטפל בשידור עמית לעמית - כולל ניתוח נתונים לפני שליחה או בעת קבלה - לא השתדרג כראוי. אז בלוקי עיבוד הקוד והטרנזקציות לפני שהוא הועבר למעשה לאימות לקונצנזוס נכשלו בנתונים, מעולם לא העבירו אותם ללוגיקה של אימות הקונצנזוס והבלוק המדובר לא הצליח אי פעם לעבור אימות.
דבר דומה מאוד קרה הפעם. מגבלה נוספת בסעיף עמית לעמית של בסיס הקוד הייתה אכיפת הגבלה על נתוני העד באופן שגוי, הגבלתה למקסימום של 1/8 מגודל הבלוק בניגוד לגודל הבלוק המלא. בורק יצר א עסקה עם נתוני עדים רק יחידת משקל אחת מעבר למגבלה הקפדנית ושוב נתקעו צמתי btcd ו-LND בגובה הבלוק הזה. עסקה זו הייתה עסקה לא סטנדרטית, מה שאומר שלמרות שהיא תקפה לחלוטין על פי כללי קונצנזוס, היא לא תקפה על פי מדיניות ברירת המחדל של mempool ולכן צמתים לא יעבירו אותה ברחבי הרשת. זה בהחלט אפשרי להכניס אותו לכרייה לבלוק, אבל הדרך היחידה לעשות זאת היא לספק אותו ישירות לכורה, וזה מה שבורק עשה בעזרת F2Pool.
זה באמת מעלה את הנקודה שכל פיסת קוד שמטרתה לנתח ולאמת נתוני ביטקוין חייבת לעבור ביקורת קפדנית על מנת להבטיח שהוא תואם את מה שהביטקוין קור יעשה. זה לא משנה אם הקוד הזה הוא מנוע הקונצנזוס ליישום צומת או רק קטע קוד שמעביר עסקאות לצומת Lightning. הבאג השני הזה היה ממש מעל זה מהחודש שעבר בבסיס הקוד. זה אפילו לא התגלה על ידי אף אחד ב-Lightning Labs. AJ Towns דיווחה על כך ב-11 באוקטובר, יומיים לאחר שהבאג המקורי הופעל על ידי עסקת מולטי-סיג של 998 מתוך 999 של Burak. זה פורסם בפומבי ב- Github במשך 10 שעות לפני שנמחק. לאחר מכן בוצע תיקון, אך לא שוחרר, מתוך כוונה לתקן בשקט את הבעיה במהדורה הבאה של LND.
כעת, זהו הליך די סטנדרטי עבור פגיעות רצינית, במיוחד עם פרויקט כמו Bitcoin Core שבו פגיעות כזו יכולה למעשה לגרום לנזק רציני לרשת/פרוטוקול השכבה הבסיסית. אבל במקרה הספציפי הזה, זה הציג סיכון רציני לכספים של משתמשי LND, ובהתחשב בעובדה שהוא היה ממש ליד הבאג הקודם שהיה לו אותם סיכונים, הסיכויים שהוא יימצא וינוצל היו גבוהים מאוד, כפי שהדגים בורק. זה מעלה את השאלה האם גישת התיקון השקט היא הדרך ללכת בכל הנוגע לנקודות תורפה כמו זו שעלולות להשאיר משתמשים פתוחים לגניבת כספים (מכיוון שהצומת שלהם לא מסוגל לזהות מצבי ערוצים ישנים ולהעניש אותם כראוי).
כפי שנכנסתי לקטע שלי על הבאג האחרון, אם שחקן זדוני היה מוצא את הבאגים לפני מפתח בעל כוונות טובות, הם היו יכולים באופן טקטי לפתוח ערוצים חדשים לצמתים פגיעים, לנתב את כל התוכן של הערוצים האלה בחזרה לעצמו ואז ניצל את הבאג. משם, הכספים האלה יהיו בשליטתם וגם יוכלו לסגור את הערוץ עם המצב ההתחלתי, ממש להכפיל את כספם. מה שבורק עשה בניצול פעיל של בעיה זו בצורה אירונית למעשה הגן על משתמשי LND מפני התקפה כזו.
ברגע שזה נוצל, משתמשים היו פתוחים להתקפות כאלה מעמיתים קיימים שכבר היו להם ערוצים פתוחים איתם, אבל הם לא היו מסוגלים יותר להיות ממוקדים במיוחד עם ערוצים חדשים. הצמתים שלהם נתקעו ולעולם לא יזהו או יעבדו תשלומים דרך ערוצים שמישהו ניסה לפתוח אחרי החסימה שתקע את הצומת שלהם. אז למרות שזה לא הסיר לחלוטין את הסיכון של ניצול משתמשים, זה הגביל את הסיכון לאנשים שכבר היה להם ערוץ איתם. הפעולה של בורק הפחיתה את זה. באופן אישי אני חושב שסוג זה של פעולה בתגובה לבאג היה הגיוני; זה הגביל את הנזק, גרם למשתמשים להיות מודעים לסיכון והוביל לתיקון מהיר.
גם LND לא היה הדבר היחיד שהושפע. של נוזל גם תהליך ההצמדה נשבר, המחייב עדכונים לבעלי תפקידים של הפדרציה כדי לתקן את זה. גרסאות ישנות יותר של Rust Bitcoin הושפעו גם כן, מה שגרם לסטייה להשפיע על כמה חוקרים בלוק ומופעי electrs (יישום של שרת הקצה האחורי עבור ארנק Electrum). כעת, למעט היתד של Liquid שבסופו של דבר חושפת כספים למפתחות שחזור החירום שבידי Blockstream לאחר פקיעת זמן נעילת זמן - ובאופן ריאלי בעלילת הסרט בסגנון השוד שבו בלוקסטרים גנבה את הכספים האלה, כולם יודעים בדיוק אחרי מי ללכת - האחרים האלה. בעיות לעולם לא מסכנות את הכספים של אף אחד בשום שלב. כמו כן, Rust Bitcoin למעשה תיקן את הבאג הספציפי הזה בגרסאות חדשות יותר, מה שככל הנראה לא הוביל לתקשורת כלשהי עם מתחזקים של בסיסי קוד אחרים כדי להדגיש את הפוטנציאל לבעיות כאלה. זה היה רק הניצול הפעיל של הבאג בשידור חי ברשת שחשף באופן נרחב שהבעיה קיימת במספר בסיסי קוד.
זה מעלה כמה בעיות גדולות בכל הנוגע לפרצות כמו זה בתוכנת Layer 2 בביטקוין. ראשית, הרצינות שבה בסיסי הקוד הללו נבדקים לאיתור באגי אבטחה וכיצד זה מתעדף לעומת שילוב של תכונות חדשות. אני חושב שזה מאוד מעיד על כך שלא תמיד יש עדיפות לאבטחה בהתחשב בכך שהבאג השני הזה אפילו לא נמצא על ידי מנהלי בסיס הקוד שבו הוא היה קיים, למרות שהוא היה ממש ליד הבאג הראשוני שהתגלה בחודש שעבר. לאחר באג גדול אחד שהעמיד את כספי המשתמשים בסיכון, לא נעשתה ביקורת פנימית של בסיס הקוד הזה? לקח מישהו מחוץ לפרויקט כדי לגלות את זה? זה לא מעיד על עדיפות לשמירה על כספי המשתמשים על פני בניית תכונות חדשות כדי למשוך יותר משתמשים. שנית, העובדה שהבעיה הזו כבר תוקנה ב-Rust Bitcoin מוכיחה חוסר תקשורת בין מתחזרי קוד שונים בכל הקשור לבאגים כמו זה. זה די מובן, שכן היותם בסיסי קוד שונים לחלוטין לא גורם למישהו שמצא באג באחד לחשוב מיד, "אני צריך ליצור קשר עם צוותים אחרים שכותבים תוכנות דומות בשפות תכנות שונות לחלוטין כדי להזהיר אותם לגבי הפוטנציאל לבאג כזה." אתה לא מוצא באג בווינדוס ואז מיד חושב ללכת לדווח על הבאג למנהלי ליבת לינוקס. ביטקוין כפרוטוקול לקונצנזוס מבוזר ברחבי רשת גלובלית הוא חיה שונה מאוד, עם זאת; אולי מפתחי ביטקוין צריכים להתחיל לחשוב בכיוון הזה בכל הנוגע לנקודות תורפה בתוכנת ביטקוין. במיוחד כשמדובר בניתוח ופרשנות של נתונים הקשורים לקונצנזוס.
לבסוף, אולי כשמדובר בפרוטוקולים כמו Lightning, התלויים בצפייה בבלוקצ'יין בכל עת כדי להיות מסוגלים להגיב למצבי ערוצים ישנים על מנת לשמור על אבטחה, ניתוח ואימות נתונים עצמאיים צריכים להישמר למינימום מוחלט - אם לא הוסר לחלוטין והאצל ל-Bitcoin Core או לנתונים שנגזרו ממנו ישירות. Core Lightning מעוצב בצורה זו, מתחבר למופע של Bitcoin Core ותלוי לחלוטין בזה לצורך אימות בלוקים ועסקאות. אם LND פעל באותה צורה, אף אחד מהבאגים הללו ב-btcd לא היה משפיע על משתמשי LND באופן שמעמיד את הכספים שלהם בסיכון.
בכל דרך שבה הדברים מטופלים - או מיקור חוץ מלא של אימות או פשוט מזעור אימות פנימי וניגשים אליו בזהירות רבה יותר - האירוע הזה מראה שמשהו צריך להשתנות בגישה לסוגיה של האופן שבו תוכנת Layer 2 מטפלת באינטראקציה עם נתונים הקשורים לקונצנזוס. שוב, לכולם יש מזל שזה לא נוצל על ידי שחקן זדוני, אלא על ידי מפתח שמוכיח נקודה. עם זאת, ביטקוין לא יכול לסמוך על מזל או בתקווה ששחקנים זדוניים לא קיימים.
מפתחים ומשתמשים צריכים להיות ממוקדים בשיפור התהליכים כדי למנוע מאירועים כאלה להתרחש שוב, ולא לשחק במשחק של לזרוק אשמה כמו תפוח אדמה לוהט.
זהו פוסט אורח מאת Shinobi. הדעות המובעות הן לגמרי שלהם ואינן משקפות בהכרח את הדעות של BTC Inc או Bitcoin Magazine.
