le code Rust vérifie que c'est bien le cas et accepte d'agir en mon nom (je le mandate)
C’est une façon particulière de décrire le problème.
C’est une privilege escalation dans le sens ou l’attaquant arrive à faire des choses qu’il n’est pas censé pouvoir faire. Mais quand on dit privilège escalation, la plupart des gens comprennent que l’attaquant élève les privilèges de code qu’il contrôle, ce qui n’est pas le cas ici.
Rust ne va pas vérifier que la personne qui a "fait la requête" a le droit de l’effacer. Rust ne va rien vérifier du tout, par définition rust ne peut que vérifier que les permissions du binaries sont ok, pas celles de l’utilisateur. Le système va verifier que le binaire a les permissions pour effacer le répertoire, c’est tout. Tu ne mandate pas (forcément) le programme, il essaye juste d’effacer un répertoire avec les permissions qu’il a.
pour exploiter ça sur des données auxquelles l’attaquant n’a pas accès, il faut:
- un programme qui tourne sous un compte plus élevé que le sien (setuid ou autre)
- que le programme essaye d’effacer quelque chose donné par l’utilisateur
Le premier point, ça va. Le deuxième, sorti d’exceptions très rares (j’ai du mal à voir le cas d’usage, pour être honnête, sorti de choses genre deluser et assimilé), est un très gros problème de sécurité, même sans ce bug.
Un programme root ou assimilé qui accepte de détruire des données sur la requête de n’importe qui, c’est un accident qui attend d’arriver comme ils disent outre quebin.
Le fond du problème, c’est plutôt ça a mon avis.
Après, oui, ca reste un gros bug pas beau du tout, parce que même sans élévation de privilèges, effacer des données, c’est dangereux. Mais ta description du problème prête à malentendu.
[^] # Re: La description n'est pas claire je trouve.
Posté par groumly . En réponse au journal Une CVE dans le compilateur rust. Évalué à 4.
C’est une façon particulière de décrire le problème.
C’est une privilege escalation dans le sens ou l’attaquant arrive à faire des choses qu’il n’est pas censé pouvoir faire. Mais quand on dit privilège escalation, la plupart des gens comprennent que l’attaquant élève les privilèges de code qu’il contrôle, ce qui n’est pas le cas ici.
Rust ne va pas vérifier que la personne qui a "fait la requête" a le droit de l’effacer. Rust ne va rien vérifier du tout, par définition rust ne peut que vérifier que les permissions du binaries sont ok, pas celles de l’utilisateur. Le système va verifier que le binaire a les permissions pour effacer le répertoire, c’est tout. Tu ne mandate pas (forcément) le programme, il essaye juste d’effacer un répertoire avec les permissions qu’il a.
pour exploiter ça sur des données auxquelles l’attaquant n’a pas accès, il faut:
- un programme qui tourne sous un compte plus élevé que le sien (setuid ou autre)
- que le programme essaye d’effacer quelque chose donné par l’utilisateur
Le premier point, ça va. Le deuxième, sorti d’exceptions très rares (j’ai du mal à voir le cas d’usage, pour être honnête, sorti de choses genre deluser et assimilé), est un très gros problème de sécurité, même sans ce bug.
Un programme root ou assimilé qui accepte de détruire des données sur la requête de n’importe qui, c’est un accident qui attend d’arriver comme ils disent outre quebin.
Le fond du problème, c’est plutôt ça a mon avis.
Après, oui, ca reste un gros bug pas beau du tout, parce que même sans élévation de privilèges, effacer des données, c’est dangereux. Mais ta description du problème prête à malentendu.