CERTA-2006-AVI-218
Vulnerability from certfr_avis - Published: 2006-05-26 - Updated: 2006-05-26
Plusieurs vulnérabilités ont été identifiées dans Tor. Elles peuvent permettre à un utilisateur d'effectuer des actions malveillantes, comme la modification du processus de journalisation, un déni de service, ou encore la récupéreration d'informations sensibles.
Description
Tor est un réseau de tunnels virtuels permettant de garantir une certaine anonymité au cours de la navigation sur Internet. Chaque utilisateur participe à sa construction. Plusieurs vulnérabilités ont été identifiées dans les versions de Tor antérieures à 0.1.1.20. Parmi celles-ci :
- les chaînes de caractères venant du réseau ne sont pas correctement vérifiées. Un utilisateur malveillant peut altérer l'intégrité des journaux avant qu'ils ne soient affichés.
- les options de pare-feu ne sont pas scrupuleusement respectées. La politique de sécurité peut alors être contournée.
- des attaques de type débordement de mémoire sont possibles quand des éléments sont ajoutés dans la liste courante (ou smartlist).
- les clés de chiffrement ne sont pas renouvelées lorsque l'utilisateur change son adresse IP.
- il est possible de deviner le choix des noeuds internes à partir d'attaques statistiques, connaissant les chemins (ou circuits) ayant des noeuds de sortie.
- il n'est pas possible de choisir, voire d'imposer, une liste de noeuds d'entrée. Ceci favorise alors les attaques de proximité issues de noeuds inconnus.
Solution
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
Toutes les versions de Tor antérieures à 0.1.1.20.
| Vendor | Product | Description |
|---|
| Title | Publication Time | Tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [],
"affected_systems_content": "\u003cP\u003eToutes les versions de Tor ant\u00e9rieures \u00e0 0.1.1.20.\u003c/P\u003e",
"content": "## Description\n\nTor est un r\u00e9seau de tunnels virtuels permettant de garantir une\ncertaine anonymit\u00e9 au cours de la navigation sur Internet. Chaque\nutilisateur participe \u00e0 sa construction. Plusieurs vuln\u00e9rabilit\u00e9s ont\n\u00e9t\u00e9 identifi\u00e9es dans les versions de Tor ant\u00e9rieures \u00e0 0.1.1.20. Parmi\ncelles-ci :\n\n- les cha\u00eenes de caract\u00e8res venant du r\u00e9seau ne sont pas correctement\n v\u00e9rifi\u00e9es. Un utilisateur malveillant peut alt\u00e9rer l\u0027int\u00e9grit\u00e9 des\n journaux avant qu\u0027ils ne soient affich\u00e9s.\n- les options de pare-feu ne sont pas scrupuleusement respect\u00e9es. La\n politique de s\u00e9curit\u00e9 peut alors \u00eatre contourn\u00e9e.\n- des attaques de type d\u00e9bordement de m\u00e9moire sont possibles quand des\n \u00e9l\u00e9ments sont ajout\u00e9s dans la liste courante (ou smartlist).\n- les cl\u00e9s de chiffrement ne sont pas renouvel\u00e9es lorsque\n l\u0027utilisateur change son adresse IP.\n- il est possible de deviner le choix des noeuds internes \u00e0 partir\n d\u0027attaques statistiques, connaissant les chemins (ou circuits) ayant\n des noeuds de sortie.\n- il n\u0027est pas possible de choisir, voire d\u0027imposer, une liste de\n noeuds d\u0027entr\u00e9e. Ceci favorise alors les attaques de proximit\u00e9\n issues de noeuds inconnus.\n\n## Solution\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des\ncorrectifs (cf. section Documentation).\n",
"cves": [
{
"name": "CVE-2006-0414",
"url": "https://www.cve.org/CVERecord?id=CVE-2006-0414"
}
],
"initial_release_date": "2006-05-26T00:00:00",
"last_revision_date": "2006-05-26T00:00:00",
"links": [
{
"title": "D\u00e9tails sur la mise \u00e0 jour de s\u00e9curit\u00e9 de la version 1.1.20 de Tor :",
"url": "http://tor.eff.org/cvs/tor/ChangeLog"
},
{
"title": "Mise \u00e0 jour de Tor :",
"url": "http://tor.eff.org/download.html.fr"
}
],
"reference": "CERTA-2006-AVI-218",
"revisions": [
{
"description": "version initiale.",
"revision_date": "2006-05-26T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "Plusieurs vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 identifi\u00e9es dans Tor. Elles peuvent\npermettre \u00e0 un utilisateur d\u0027effectuer des actions malveillantes, comme\nla modification du processus de journalisation, un d\u00e9ni de service, ou\nencore la r\u00e9cup\u00e9reration d\u0027informations sensibles.\n",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans Tor",
"vendor_advisories": [
{
"published_at": null,
"title": "Bulletin de mise \u00e0 jour Tor du 23 mai 2006",
"url": null
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.