שורה אחת ביומן הגרסאות של AnyDesk ללינוקס, מיוני האחרון, הודיעה שתוקן באג שעלול לגרום לקריסה. זה כל מה שהיצרן כתב, לפי הדיווח של The Hacker News: בלי מספר CVE, בלי התראת אבטחה, בלי לרמוז שמדובר באבטחה בכלל. בשמונה באוקטובר פרסם צוות המחקר של V12 את הניתוח הטכני המלא של מה שהתיקון ההוא סגר, ומסתבר שזה לא היה באג של קריסה. זו חולשה שמאפשרת לתוקף מרוחק להריץ פקודה על המכונה עם הרשאות root, לפני שמישהו לחץ "אשר" בחלונית החיבור.

את החולשה, שהחוקרים קראו לה AnyPwn, מצא Rick de Jager מצוות V12 בעזרת מנוע סקירת הקוד שהחברה מפתחת. היא קיימת בגרסה 8.0.2 של AnyDesk ללינוקס ותוקנה ב-8.0.3. בהמשך נעבור על מה שהשירות הזה עושה על המכונה שלכם, איך חישוב פשוט של 32 ביט שהתהפך פותח את הדלת, ולמה דווקא השקט של היצרן הוא החלק המטריד.

מה רץ שם, ועם אילו הרשאות

AnyDesk הוא כלי שליטה מרחוק: מתקינים אותו, ומישהו מהצד השני יכול לראות את המסך ולהפעיל אותו. בלינוקס הוא מותקן כ-service של המערכת, והשירות הזה רץ בדרך כלל עם הרשאות root. הוא מאזין לחיבורים ישירים על פורט TCP/7070, וכאן מתחיל העניין: עוד לפני שהתוכנה מציגה למשתמש את הבקשה לאשר או לדחות, היא כבר מפרסרת את מה שהצד השני שלח לה. כל קוד שמטפל בנתונים בשלב הזה הוא קוד שתוקף יכול להגיע אליו בלי שום הרשאה.

זו גם לא הפעם הראשונה שהגרסה של AnyDesk ללינוקס סובלת מבעיה מהסוג הזה. CVE-2020-13160 הייתה חולשת format string בגרסאות שלפני 5.5.3 בלינוקס וב-FreeBSD, וגם היא אפשרה הרצת קוד מרחוק. הרעיון חוזר: פרוטוקול בינארי שנכתב להיות מהיר, שמקבל קלט מהרשת לפני כל בדיקת זהות.

החשבון שהתהפך

המנגנון עצמו פשוט להסביר, וזה מה שהופך אותו למלמד. הפרוטוקול של AnyDesk מעביר את נתוני הסשן בחבילות שכל אחת מהן מצהירה בתוכה על אורך התוכן שהיא נושאת. השרת קורא את האורך המוצהר, מוסיף לו 16 בתים של כותרת שהוא צריך לאובייקט הפנימי, ומבקש מהמערכת זיכרון בגודל הזה. הבעיה היא שהחישוב הזה נעשה בחשבון של 32 ביט, בלי לבדוק אם התוצאה גלשה מעל הגבול.

אז מה קורה כשהחבילה מצהירה על אורך של בדיוק 0xFFFFFFF0 בתים? הוספת 16 מחזירה את המונה לאפס. השרת מקצה חוצץ באורך אפס, אבל האובייקט עצמו ממשיך לזכור את האורך הגדול שהוצהר, ומצביע הנתונים שלו מצביע למקום הרגיל. התוצאה היא שכל בית אחד של נתונים שהתוקף שולח נכתב מחוץ לשטח שהוקצה. לטכניקה הזאת קוראים גלישת מספר שלם (integer overflow), והיא זו שמייצרת כאן גלישת חוצץ בערמת הזיכרון (heap buffer overflow).

החוקרים מדגישים נקודה שקל לפספס: התוקף לא צריך לשלוח ארבעה ג'יגה-בייט כדי שזה יעבוד. החבילה החיצונית נשארת קטנה לגמרי. רק השדה שמצהיר על האורך הוא זה שמייצר את הגלישה בחשבון, והגוף הקטן של אותה חבילה מספק את הבתים שנכתבים מעבר לגבול. כל טווח הערכים מ-0xFFFFFFF0 ועד 0xFFFFFFFF מייצר הקצאה של אפס עד 15 בתים בלבד.

למה הניצול לא תמיד מצליח

מכתיבה של בתים מחוץ להקצאה ועד הרצת פקודה יש עוד דרך, והיא לא ודאית. הכתיבה דורסת שדות באובייקט שיושב בזיכרון מיד אחרי החוצץ המוקטן, וכדי שזה יהיה שימושי צריך שהאובייקט ה"נכון" יהיה שם בדיוק באותו רגע. לפי הניתוח של V12, הקוד שפורסם מסדר את הערמה מראש בשני שלבים: קודם הוא שולח מאות אובייקטים בגדלים מדורגים כדי למלא את מחלקות הגודל של מקצה הזיכרון, ואחר כך פותח עשרה חיבורי לקוח נוספים שמניחים אובייקטי מטרה בין ההקצאות המסודרות.

גם אחרי כל זה, ההצלחה היא הסתברותית. אם האובייקט המיועד לא נפל צמוד לחוצץ, השירות קורס במקום להריץ את הפקודה. השלב האחרון בשרשרת מכוון את זרימת הביצוע לרצף קצר של הוראות קיימות בתוך הבינארי עצמו, מה שמכונה ROP, עד לקריאה לפונקציה שמריצה פקודת מערכת. ההיסטים המדויקים בקוד שפורסם מכוונים לבנייה אחת ספציפית של AnyDesk 8.0.2 על x86_64, וכל בנייה אחרת תדרוש התאמה מחדש.

כלומר זה לא כלי שמישהו מפעיל בלחיצה על אוכלוסייה שלמה. זה כן מופע עובד שמראה שהחולשה אמיתית, והוא מספק לכל מי שמתעניין את כל המידע הדרוש כדי לבנות גרסה משלו.

אז החולשה מוגבלת לחיבורים ישירים, או לא?

כאן המקורות לא מסכימים, וכדאי להציג את שני הצדדים כפי שהם. AnyDesk אמרה ביוני, בציטוט שמופיע בדיווח של The Hacker News, שהבעיה "מוגבלת לחיבורים ישירים בלינוקס, חיבורים שאינם עוברים דרך הרילייים שלנו", וש-Windows ו-macOS אינם חשופים. זו הצהרה שמצמצמת מאוד את החשיפה בפועל, כי רוב המשתמשים מתחברים דרך שרתי התיווך של החברה ולא ישירות.

החוקרים אומרים משהו אחר. בניתוח שלהם הם כותבים שאותו נתיב קוד פגיע בפרוטוקול הסשן נגיש גם דרך חיבורי הרילי של AnyDesk, ושהם אימתו את זה בעזרת טריגר מינימלי בכלי אינסטרומנטציה. מה שהם לא עשו זה להדגים את שרשרת הניצול המלאה דרך הרילי: הקוד שפורסם מדגים אותה רק על חיבור ישיר ב-TCP/7070, והחוקרים מסבירים שזו החלטה של חיסכון בזמן פיתוח ולא מגבלה של החולשה. אף גורם עצמאי לא הכריע בין שתי הגרסאות. מי שמעריך את החשיפה שלו כרגע צריך להחזיק בראש ששאלת הרילי פתוחה.

תיקון בלי שם

החלק שיישאר רלוונטי גם אחרי שכולם יעדכנו הוא לא הגלישה בחשבון, אלא מה שקרה סביב התיקון. רשומות ה-CVE של AnyDesk במאגר NVD נעצרות ב-21, והאחרונה שבהן, CVE-2026-15681 מיולי 2026, היא חולשת מניעת שירות מקומית בהקלטת המסך. לחולשה שמאפשרת הרצת קוד כ-root מרחוק, בלי אימות, אין שם במאגר. כלום.

למי שמנהל מערכות זה לא ניואנס אקדמי. תהליכי ניהול הגרסאות בארגונים בנויים סביב מספרי CVE: סורק מריץ בדיקה מול מאגר, מוציא רשימה, והרשימה היא מה שנכנס לתור הטיפול. חולשה בלי CVE ובלי התראה לא מופיעה באותה רשימה, ולכן מנהל שהתקין את 8.0.2 וראה ביומן הגרסאות שתוקן באג של קריסה לא היה לו שום סיבה למהר. ארבעה חודשים עברו בין התיקון ביוני לפרסום הניתוח באוקטובר. בכל הזמן הזה, מי שלא עדכן לא ידע שהוא חשוף.

יש עוד פרט קטן בניתוח של V12 שמספר סיפור בעצמו. החוקרים כותבים שהיצרן כנראה מחק את בניית 8.0.2 מעמוד ההורדות אחרי שהם פרסמו את סרטון ההדגמה שלהם, והם מוסיפים בחצי חיוך שהעברת הקוד לגרסה אחרת נשארת כתרגיל לקורא. (הבנייה עדיין מופיעה ביומן הגרסאות, מה שאומר שההסתרה חלקית בלבד.)

מה זה אומר בפועל

אם יש לכם AnyDesk מותקן על מכונות לינוקס, בדקו גרסה והשלימו ל-8.0.3 לפחות. זו בדיקה שצריך לעשות ידנית או דרך מלאי הגרסאות שלכם, כי שום סורק חולשות לא יסמן לכם את זה בלי CVE להיתפס עליו. מי שלא יכול לעדכן מיד יכול לצמצם חשיפה בחסימת גישה לפורט TCP/7070 מכל מי שלא אמור להתחבר ישירות, אבל בהתחשב במחלוקת על נתיב הרילי, זה אמצעי ביניים ולא תחליף לעדכון.

ושווה לקחת מכאן גם משהו רחב יותר על כלי שליטה מרחוק: הם רצים כ-service עם הרשאות גבוהות, מאזינים לרשת, ומפרסרים פרוטוקול בינארי משל עצמם לפני כל אימות. ככה נראית מטרה אטרקטיבית, וראוי שהם יופיעו ברשימת המערכות שאתם עוקבים אחרי העדכונים שלהן באופן יזום.