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

שבעה חוקרים מהמכון לאבטחת מידע (ISEC) באוניברסיטה הטכנית של גרץ שבאוסטריה הפכו את ההתנהגות הזאת למתקפה שמזהה בזמן אמת באילו אתרים גולש המשתמש השני. על אלף האתרים הפופולריים ביותר הם מדווחים על ציון F1 של 97.8%, מדד שמעניש גם על החמצות וגם על זיהויים שגויים, בלי אף זיהוי שגוי אחד. העבודה שלהם, File Notification Attacks, התקבלה לכנס CCS 2026 שייערך בהאג בנובמבר, והיא בוחנת את אותו רעיון על לינוקס, ווינדוס, אנדרואיד ומק. נעבור על מה שמנגנון ההתראות מוסר בכל אחת מהן, ועל מה שהיצרניות ענו לחוקרים.

מה המנגנון הזה עושה, ולמה הוא קיים בכלל

לכל מערכת הפעלה מודרנית יש שירות שתוכנה יכולה להירשם אליו כדי לדעת מתי קובץ נפתח, נכתב, נסגר או נמחק. עורך טקסט משתמש בו כדי לרענן קובץ שהשתנה מתחתיו, כלי גיבוי כדי לדעת מה להעלות, וסביבת פיתוח כדי לבנות מחדש אחרי שמירה. בלינוקס קוראים לשירות הזה inotify והוא קיים מאז קרנל 2.6.13 בשנת 2005, בווינדוס זה ה-API בשם ReadDirectoryChangesW שקיים מאז Windows 2000, במק זה File System Events מאז Mac OS X 10.5 בשנת 2007, ובאנדרואיד המחלקה FileObserver מ-2008, שהיא עטיפה ל-inotify.

מה שהמנוי מקבל הוא שם הקובץ, סוג הפעולה והרגע המדויק שבו היא קרתה. את התוכן הוא לא מקבל, ובדרך כלל גם אין לו הרשאה לקרוא אותו. כאן מתחילה הבעיה: גם בלי התוכן, רצף אירועים עם חותמות זמן מדויקות מספר מה המשתמש עושה. למדידה עקיפה כזאת, שמסגירה מידע שלא הייתה אמורה להסגיר, קוראים ערוץ צדדי (side channel). התוכן נשאר סגור. העיתוי נפתח.

איך ספירת אירועים הופכת לשעון עצר על המקלדת

בלינוקס, ניסיון להציב מעקב על קובץ שאין לכם הרשאת קריאה אליו נכשל בשגיאת הרשאות. ניסיון להציב מעקב על התיקייה שמכילה אותו, כשאותה כן מותר לקרוא, מצליח, ומאותו רגע מגיעים דיווחים על כל הקבצים שבתוכה, גם על אלה שחסומים. התיקייה המעניינת כאן היא /dev/input, שבה יושבים קבצי ההתקן של המקלדת והעכבר. איזה מקש נלחץ לא דולף. רק שנלחץ מקש, ומתי בדיוק.

זה מספיק. הזמן שעובר בין הקשה להקשה אינו אחיד, כי הוא תלוי באיזו אצבע מקלידים, במרחק בין המקשים ובמילה עצמה, ולכן הוא מסגיר גם מי מקליד וגם, בתנאים מסוימים, מה הוקלד. על הרעיון הזה יש יותר משני עשורים של מחקר, מ-Song ושותפיו ב-2001 ועד Qiu ושותפיו ב-2025. הצוות מגרץ בדק אותו מול שישה מקלידים שלא ראו את הטקסט מראש, בקצב של 2.9 עד 6.25 תווים בשנייה, ומול מקליד אחד שתרגל את הטקסט חמש פעמים. ציון ה-F1 נע בין 93.1% ל-100%, ההתראה הגיעה בממוצע בין 0.05 ל-3.5 מילישניות אחרי ההקשה, ו-66% מהמקשים זוהו בתוך מילישנייה אחת.

הגרסה המרוחקת מטרידה יותר. כששני משתמשים מחוברים לאותו שרת ב-SSH, כל עדכון של הטרמינל מייצר אירועים על ה-pseudo-terminal שב-/dev/pts, ואת מספר ה-pts של המשתמש השני אפשר לשלוף מהפקודה who. בניסוי הקליד אדם 402 תווים לתוך session של SSH בקצב ממוצע של 7.21 תווים בשנייה, ותהליך לא מורשה בצד השרת זיהה כל אחת מההקשות, בלי טעות אחת לכאן או לכאן, בסטייה ממוצעת של 2.9 מילישניות מהזמן האמיתי.

בכל מה שתואר עד כאן התוקף רק מקשיב. המתקפה הרביעית שהחוקרים הדגימו פעילה. ב-KDE Plasma 6 מעל Wayland, הרכיב pkexec של PolicyKit הוא זה שמקפיץ את חלון הסיסמה כשתוכנה מבקשת הרשאות מנהל, והקובץ שלו קריא לכל משתמש. התראת גישה אליו אומרת בסבירות גבוהה שחלון סיסמה עומד לעלות למסך, למשל כש-KDE Discover מתקין עדכונים. באותו רגע התוקף, תהליך של אותו משתמש, מצייר חלון סיסמה מזויף מעל האמיתי.

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

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

אז איך דולפים האתרים שגלשתם בהם?

כדי להגיע לאתרים בלינוקס החוקרים נאלצו ללכת סביב, כי שמות הקבצים החסומים לא מגיעים אליהם. כשפיירפוקס מצייר עמוד הוא טוען פונטים מהמערכת, מהתיקייה /usr/share/fonts/, וכל אתר טוען צירוף אחר של קבצים. על מכונת הבדיקה היו 1,448 קבצי פונט. target.com ניגש להכי הרבה מהם, 657 בממוצע לכל ביקור, בעוד discord, yahoo ו-samsung נגעו ב-24 עד 26 קבצים בלבד. החוקרים הריצו 30 ביקורים על כל אחד ממאה האתרים הפופולריים, הוסיפו 750 אתרים נוספים כדי לבדוק גם מקרים שהמסווג לא אומן עליהם, וקיבלו ציון F1 של 87.9%.

בווינדוס לא צריך את העקיפה הזאת, כי השם מגיע ישירות. פיירפוקס פותח תיקייה נפרדת לכל אתר שמשתמש באחסון מקומי, ב-IndexedDB או ב-cache של הדפדפן, וזה קורה ב-95.7% מהאתרים שנבדקו. דפדפנים מבוססי Chromium, ובהם Edge, פותחים תיקייה כזאת רק עבור IndexedDB, ולכן רק ב-32% מהאתרים. ההבדל הזה מסביר את הפער בתוצאות: 97.8% על פיירפוקס מול 48.5% על Edge, בשני המקרים בלי אף זיהוי שגוי.

אנדרואיד: התיקייה שנראית ריקה וממשיכה לדווח

באנדרואיד לכל אפליקציה יש תיקייה פרטית תחת /sdcard/Android, ושכבת FUSE של המערכת דואגת שאפליקציות אחרות לא יראו מה יש בה. אפליקציה לא מורשית שקוראת ל-File.listFiles על תיקיית המדיה של וואטסאפ, /sdcard/Android/media/com.whatsapp/WhatsApp, מקבלת תיקיות ריקות בלבד. ההגנה הזאת לא הורחבה להתראות: אותה אפליקציה בדיוק, בלי אף הרשאה, מצליחה להציב על אותה תיקייה FileObserver ולקבל דיווח על כל אירוע שקורה בתוכה, כולל שם הקובץ.

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

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

מה ענו היצרניות

הדיווח יצא לצוותי האבטחה של לינוקס, אנדרואיד, ווינדוס ומק בין אוגוסט לאוקטובר 2025, ול-KDE בנובמבר. בלינוקס העבודה מול צוות האבטחה הבשילה לתיקון בדצמבר 2025 שהופץ בתחילת 2026 בקרנלים 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65 ו-6.18.3, וקיבל את המזהה CVE-2025-68788. התיקון חלקי במוצהר: הוא מבטל את אירועי הגישה והשינוי על קבצי התקן בלבד, כלומר סוגר את המקרה של /dev/input, וכל שאר הקבצים במערכת עדיין חשופים לאותה עקיפה דרך תיקיית האב.

מיקרוסופט ענתה שההתנהגות היא by design. באתר המחקר החוקרים מנסחים את התשובה כ"פיצ'ר לא מתועד", ולפי המאמר הטענה של מיקרוסופט היא שמדובר בחשיפה של שמות ונתיבים בתיקיית הפרופיל של משתמש אחר בלבד. החוקרים חולקים על ההערכה הזאת, ומראים ששמות ונתיבים לבדם מספיקים כדי לעקוב אחרי גלישה בציון 97.8%. מנגנון שכן חוסם את ההתנהגות קיים בווינדוס מאז אפריל 2025, מדיניות רישום בשם EnforceDirectoryChangeNotificationPermissionCheck שנוספה בעקבות דיווחים נפרדים של Sébastien Huneault, אלא שהיא כבויה כברירת מחדל, ולכן כל המתקפות שבמאמר עובדות על התקנת ווינדוס סטנדרטית בלי לשנות דבר. (התשובה הזאת הועמדה לבחירה בקטגוריית תגובת הספק העלובה ביותר בפרסי Pwnie לשנת 2026.) לאנדרואיד ולמק אין תיקון.

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

המתקפות האלה אינן מרחוק. הן דורשות קוד שכבר רץ על המכונה תחת משתמש אחר, למשל service שנפרץ, או חבילת תוכנה שהגיעה דרך שרשרת אספקה מורעלת, ולכן היעדים הריאליים הם שרתים משותפים, עמדות עבודה עם כמה משתמשים ומכונות פיתוח שמריצות חבילות צד שלישי. מי שמריץ לינוקס יכול לבדוק אם הקרנל שלו כבר מתוקן בפקודה inotifywait -m -e access,modify /dev/input, ואם הקשה על המקלדת לא מייצרת שורות, המיגון קיים. בווינדוס המדיניות שחוסמת מעקב אחרי כונן שלם קיימת אבל כבויה, וכדאי שמי שמנהל עמדות רב-משתמשיות יפעיל אותה ביודעין. באנדרואיד אין מה להפעיל, וזה בדיוק המקום לזכור שאפליקציה שלא ביקשה שום הרשאה אינה בהכרח אפליקציה שלא רואה כלום. קוד ההדגמה של החוקרים פורסם לכל ארבע המערכות.