isec-tugraz/file-notification-attacksArtefacts de recherche pour les attaques par canal auxiliaire de notification de fichiers sur Linux, Windows et macOS, démontrant la fuite via inotify/FSEvents, le timing des frappes clavier et l'empreinte de sites web.
Ce dépôt contient les artefacts (encore en cours de révision !) pour l'article « File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS », accepté à CCS '26.
Consultez le site web avec les démos à l'adresse : https://inoti.fyi/
Lisez l'article à l'adresse : https://snee.la/pdf/pubs/file-notification-attacks.pdf ou http://inoti.fyi/pubs/file-notification-attacks.pdf
Dans le cadre de l'évaluation des artefacts à CCS'26 (encore en cours !), nous avons fourni une VM Debian 13 + KDE Plasma 6 avec un noyau pré-patché. Cette VM n'a pas été utilisée pour produire les résultats d'évaluation de l'article et n'est pas destinée à reproduire leur magnitude exacte. Ce dépôt pourra être mis à jour pour intégrer les relectures et retours de nos évaluateurs d'artefacts. Nous rendrons la VM publiquement accessible lorsque notre évaluation d'artefacts sera terminée.
Nous avons employé Claude (Opus 4.8) pour envelopper notre code dans des artefacts correctement documentés et performants (par exemple, celui pour Windows était un peu lent). Cependant, le code, les scripts et les makefiles qu'il a générés étaient basés sur
Les instructions ci-dessous pour tester le code Linux sont spécifiques à
l'exécution de commandes dans la VM. Veuillez plutôt consulter le code dans
Linux/.
La VM existe purement par commodité, afin que le montage de chaque attaque ne nécessite pas une configuration d'environnement à partir de zéro ni une rétrogradation du noyau. Le mécanisme sous-jacent démontré dans la VM est identique à celui décrit dans l'article, mais veuillez noter que nous n'avons pas utilisé la VM pour produire les chiffres rapportés dans l'article. Les timings absolus peuvent différer en raison de l'environnement virtualisé et du matériel sous-jacent.
Les résultats sont reproduits dans une VM Debian 13 (linux-vm/), installée à
partir de l'ISO live officielle Debian avec KDE Plasma 6 (Wayland) installé avec
un noyau antérieur au correctif
fsnotify.
inotify-tools, les en-têtes de développement Qt6 et pkexec sont installés.
Rien d'autre n'est mis à jour, et le noyau n'est jamais touché après
l'installation. Veuillez NE PAS exécuter apt upgrade ni tenter de mettre à
jour le noyau. Cette image de VM est délibérément ancienne, n'est pas à jour
et ne dispose pas des derniers correctifs de sécurité. Cette image de VM est
uniquement destinée à une validation et des tests rapides !
Le code, les attaques et les démonstrations situés dans la VM sont reproduits
dans Linux/.
Remarque : Nous indiquons sous quel utilisateur exécuter les commandes en
haut de chaque bloc de commandes. Il y a [host], qui est la machine hôte qui
exécute la VM, [user] qui est la victime des attaques dans la VM, et
[spyuser] qui doit être configuré et qui sera l'attaquant dans la plupart des
attaques Linux.
L'image disque est fournie sous le nom linux-vm-upload.qcow2, compressée avec
zstd. Renommez-la en linux-vm.qcow2 avant d'exécuter run.sh (qui attend ce
nom de fichier) :
# Run As: [host]
cd linux-vm/
mv linux-vm-upload.qcow2 linux-vm.qcow2
./run.sh
La lecture d'un qcow2 compressé avec zstd nécessite qemu-img/qemu-system-x86_64
version 5.2 ou supérieure (2020+), vérifiez avec qemu-img --version. Si vous
êtes bloqué sur un QEMU plus ancien et qu'il échoue à ouvrir l'image, décompressez-la
d'abord en un qcow2 plat :
qemu-img convert -O qcow2 linux-vm-upload.qcow2 linux-vm.qcow2
4 cœurs, 4 Go de RAM, affichage graphique. Les identifiants sont :
root, mot de passe password,user, mot de passe password,spyuser, mot de passe password (ne vous connectez pas en tant que spyuser !)La VM fournie exécute déjà un noyau vulnérable et pré-patché
(6.12.43+deb13-amd64), donc aucune rétrogradation n'est nécessaire pour
l'utiliser. Vous aurez besoin de QEMU pour exécuter cette image (qui dispose
d'une interface graphique). L'artefact se trouve à
/home/user/Linux-File-Notification-Attacks dans la VM.
Une seule commande configure tout à neuf dans la VM : (i) un compte spyuser
non privilégié (non-sudo), (ii) sa propre copie du répertoire d'artefacts (un
compte non privilégié distinct ne peut autrement pas traverser le répertoire
personnel de user), (iii) et tous les scripts rendus exécutables dans les deux
copies.
# In the VM, Run As: [user]
sudo bash ~/Linux-File-Notification-Attacks/setup_attacks.sh
Chaque attaque ci-dessous s'exécute en tant que spyuser (su - spyuser, mot
de passe password), sauf auth-ui-redress, qui s'exécute en tant que user
(expliqué ci-dessous).
Démontre que les notifications d'opérations sur fichiers sont délivrées pour des fichiers qui ne peuvent pas être lus directement, tant que leur répertoire parent est lisible.
# Run As: [spyuser]
# To switch to spyuser, in a new terminal type `su - spyuser`. The password
# is `password`.
cd ~/Linux-File-Notification-Attacks/unreadable-file-bypass
./watch-syslog.sh
Laissez-le s'exécuter, puis générez une ligne de journal depuis un autre
terminal en tant que user :
# Run As: [user]
logger "hello"
Cette image Debian 13 n'a pas rsyslog, donc il n'y a pas de fichier
/var/log/syslog comme montré dans l'article. Le script se rabat sur la
surveillance de /var/log/journal/<machine-id>/ à la place. C'est la même idée,
car les fichiers .journal surveillés appartiennent à root (utilisateur) et
systemd-journal (groupe), dont aucun n'est spyuser.
Mesure le délai de notification d'inotify.
# Run As: [user], ensure numpy is installed (or pip3)
sudo apt install python3-numpy
# Run As: [spyuser]
cd ~/Linux-File-Notification-Attacks/temporal-resolution
./run.sh
watcher ouvre une surveillance inotify sur un fichier de test et horodate
chaque IN_ACCESS qu'il reçoit. accessor lit ce même fichier 1000 fois avec un
délai aléatoire de 5 à 10 ms entre les lectures, en horodatant lui-même chaque
lecture. stats.py compare les deux enregistrements d'horodatage et affiche le
délai moyen/écart-type/minimum entre le moment où la lecture a lieu et l'arrivée
de la notification, c'est-à-dire la résolution temporelle d'inotify.