Bonjour,
Frédéric a écrit :
> On Samedi 12 Mars 2005 19:11, Olivier Allard-Jacquin wrote:
>
> Merci pour ces précisions.
Je t'en prie.
>> Aussi, il est important de sécuriser les machines cliente et serveur
>>avec un bon FW (netfilter sous Linux), afin surtout de "boucher" le port
>>VNC sur l'interface réseau Internet. En effet, que ce soit aussi bien du
>>cote client ou serveur, le soft VNC (client ou serveur) et le SSH
>>dialoguent sur l'interface réseau loopback (localhost / 127.0.0.1).
>
>
> Donc, si je comprend bien, pour que ça fonctionne, il suffit d'ouvrir
> uniquement le port ssh,
Sur l'interface réseau externe, oui.
> et dans ce cas, c'est le seul qui sera sujet au
> buffer overflow, c'est bien ça ? Ou bien, même fermé, le port VNC
> sera-t-il sujet à ce genre d'attaque, via le port ssh ?
Les deux en fait :
- Un intrus qui attaquera directement le serveur SSH pourra tenter de
faire un buffer overflow dessus. Si il y arrive, il fera tomber le
serveur SSH, et aura des chances d'exécuter un programme sur ta machine.
- Si par contre l'intrus (*) (ou un utilisateur "légal") obtient une
session SSH sur ta machine, alors dans ce cas, il peut tenter un buffer
overflow sur le serveur VNC lui-même. L'attaque arrivera sous forme
cryptée sur le serveur SSH. Elle sera décrypté par le serveur SSH, et
transmise au serveur VNC, qui l'exécutera.
Ainsi, ton FW ne te protégera que d'une attaque directe contre le
serveur VNC. Mais une fois le tunnel SSH établi, plus rien ne protégera
le serveur VNC.
Dans les 2 cas de buffer overflow, ta machine exécutera donc un code
malicieux. Celui-ci pourra éventuellement augmenter ses privilèges
d'exécution (si il y a une faille de sécurité dans le kernel par
exemple), afin de devenir root sur ta machine. Avec toutes les
conséquences désagréables que cela suppose... :=(
Les seules parades aux attaques par buffer overflow :
- garder des versions à jour de ses logiciels serveurs (spécialement
pour SSH), et appliquer les patchs de sécurité.
- faire tourner un maximum les logiciels serveurs avec des droits
limités, voir dans des chroot si c'est posssible. Le chroot N'est PAS
une sécurité absolu, mais cela peut limiter la casse, et ralentir les
intrus.
(*) : Un intrus peut obtenir une session SSH "légalement", si par
exemple il a volé le login / mot de passe de l'utilisateur "légal" (dans
le cas d'un mot de passe trop simple par exemple). Dans ce cas là, comme
il a déjà une session SSH sur ta machine, il préférera sans doute faire
une élévation de privilège en faisant un exploit local, plutôt que
d'attaquer le serveur VNC de la machine. Dans tout les cas, si l'intrus
a déjà réussi à obtenir une session SSH "légale", c'est que la sécurité
de ta machine ne tient plus qu'à un fil, serveur VNC ou pas.
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
