CERTA-2001-AVI-104
Vulnerability from certfr_avis - Published: - Updated:
Un utilisateur mal intentionné peut contourner une configuration restreignant les adresses IP de connexion au serveur ou les commandes autorisées sur ce dernier.
Description
Le fichier ˜/.ssh/authorized_keys2, de chaque utilisateur autorisé à se connecter via SSH, permet de restreindre les actions permises et/ou l'adresse du client par l'ajout d'options à chaque clé publique listée.
Ces limitations sont souvent utilisées lorsque le client distant est invoqué automatiquement (tâche programmée,...) et que par conséquent sa clé privée n'est pas protégée par un mot de passe.
Dans certains cas particuliers, ces restrictions peuvent être contournées :
- si le serveur sftp (ftp sécurisé introduit avec la version 2) est lancé, il peut être invoqué malgré la restriction sur les commandes autorisées, et, selon les droits du client, être utilisé pour modifier le fichier ˜/.ssh/authorized_keys2 dans le but d'obtenir un shell, par exemple.
- si 2 clés de nature différente (i.e. RSA et DSA) se suivent au sein de ce fichier, alors les options sur la seconde clé s'appliquent également à la première, ce qui peut conduire au non respect de restrictions sur l'adresse source du client pour la première clé.
Contournement provisoire
- Désactiver le lancement du sous-système sftp sur le serveur (usuellement dans le fichier sshd_config) dans le premier cas.
- Commenter l'une des clés ou créer de nouvelles clés de manière à unifier le type, dans le second cas.
Solution
-
Télécharger et compiler la dernière version d'OpenSSH depuis le site officiel :
http://www.openssh.org -
Télécharger et installer le port/paquetage correspondant à la distribution lorsqu'il sera disponible.
-
Linux Mandrake :
http://www.linux-mandrake/en/security/2001/MDKSA-2001-081.php3 -
Linux Red Hat :
http://www.redhat.com/support/errata/RHSA-2001-114.html -
Linux Trustix :
http://www.trustix.net/errata/misc/2001/TSL-2001-0026-openssh.as.txt
-
OpenBSD, FreeBSD, toute distribution Linux et tout système utilisant OpenSSHv2 dans une version inférieure à la 2.9.9.
| Vendor | Product | Description |
|---|
| Title | Publication Time | Tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [],
"affected_systems_content": "\u003cP\u003eOpenBSD, FreeBSD, toute distribution Linux et tout syst\u00e8me utilisant OpenSSHv2 dans une version inf\u00e9rieure \u00e0 la 2.9.9.\u003c/P\u003e",
"content": "## Description\n\nLe fichier \u02dc/.ssh/authorized_keys2, de chaque utilisateur autoris\u00e9 \u00e0 se\nconnecter via SSH, permet de restreindre les actions permises et/ou\nl\u0027adresse du client par l\u0027ajout d\u0027options \u00e0 chaque cl\u00e9 publique list\u00e9e.\n\nCes limitations sont souvent utilis\u00e9es lorsque le client distant est\ninvoqu\u00e9 automatiquement (t\u00e2che programm\u00e9e,...) et que par cons\u00e9quent sa\ncl\u00e9 priv\u00e9e n\u0027est pas prot\u00e9g\u00e9e par un mot de passe. \n\nDans certains cas particuliers, ces restrictions peuvent \u00eatre\ncontourn\u00e9es :\n\n- si le serveur sftp (ftp s\u00e9curis\u00e9 introduit avec la version 2) est\n lanc\u00e9, il peut \u00eatre invoqu\u00e9 malgr\u00e9 la restriction sur les commandes\n autoris\u00e9es, et, selon les droits du client, \u00eatre utilis\u00e9 pour\n modifier le fichier \u02dc/.ssh/authorized_keys2 dans le but d\u0027obtenir un\n shell, par exemple.\n- si 2 cl\u00e9s de nature diff\u00e9rente (i.e. RSA et DSA) se suivent au sein\n de ce fichier, alors les options sur la seconde cl\u00e9 s\u0027appliquent\n \u00e9galement \u00e0 la premi\u00e8re, ce qui peut conduire au non respect de\n restrictions sur l\u0027adresse source du client pour la premi\u00e8re cl\u00e9.\n\n## Contournement provisoire\n\n- D\u00e9sactiver le lancement du sous-syst\u00e8me sftp sur le serveur\n (usuellement dans le fichier sshd_config) dans le premier cas.\n- Commenter l\u0027une des cl\u00e9s ou cr\u00e9er de nouvelles cl\u00e9s de mani\u00e8re \u00e0\n unifier le type, dans le second cas.\n\n## Solution\n\n- T\u00e9l\u00e9charger et compiler la derni\u00e8re version d\u0027OpenSSH depuis le site\n officiel :\n\n http://www.openssh.org\n\n- T\u00e9l\u00e9charger et installer le port/paquetage correspondant \u00e0 la\n distribution lorsqu\u0027il sera disponible.\n - Linux Mandrake :\n\n http://www.linux-mandrake/en/security/2001/MDKSA-2001-081.php3\n\n - Linux Red Hat :\n\n http://www.redhat.com/support/errata/RHSA-2001-114.html\n\n - Linux Trustix :\n\n http://www.trustix.net/errata/misc/2001/TSL-2001-0026-openssh.as.txt\n",
"cves": [],
"links": [
{
"title": "OpenSSH Security Advisory",
"url": "http://www.securityfocus.com/cgi-bin/archive.pl?id=1\u0026mid=216702"
},
{
"title": "OpenSSH: sftp \u0026 bypassing keypair auth restrictions",
"url": "http://www.securityfocus.com/cgi-bin/archive.pl?id=1\u0026mid=214921"
}
],
"reference": "CERTA-2001-AVI-104",
"revisions": [
{
"description": "version initiale.",
"revision_date": "2001-09-28T00:00:00.000000"
},
{
"description": "ajout de liens sur les distributions Linux de Mandrake, Red Hat et Trustix.",
"revision_date": "2001-10-19T00:00:00.000000"
}
],
"risks": [
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
}
],
"summary": "Un utilisateur mal intentionn\u00e9 peut contourner une configuration\nrestreignant les adresses IP de connexion au serveur ou les commandes\nautoris\u00e9es sur ce dernier.\n",
"title": "Vuln\u00e9rabilit\u00e9s multiples dans l\u0027impl\u00e9mentation OpenSSH du protocole SSH v2",
"vendor_advisories": [
{
"published_at": null,
"title": "Listes de diffusion BugTraq et openssh-unix-dev",
"url": null
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
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.