apache sécurité

Thomas <fantome.forums.tDeContes@free.fr> writes:

[Apache, tout ca....]

ok, mais entre temps j'ai trouvé la possibilité de faire un forward :-)

ah, sinon, y en a d'autres, des possibilités ??


au fait,
<87wts9jcx9.fsf@actarus.zen.inc>

Ah, ca, c'est "moi", mais j'ai aussi un nom et un prenom "humains", tu
sais :-)

me dit qu'il n'y a pas de danger

Je n'ai *JAMAIS* dit ca !!!

Cf ma reponse sur le NG approprie (au passage, c'est quand meme un peu
le bordel de suivre en double a peu pres la meme discussion sur 2 NG
differents, et c'est sympa de "tirer dans le dos" d'un intervenant de
l'autre cote......), j'ai suggere l'activation du mode "user" (puisque
c'est apparemment comme ca que ca s'appelle sous Apache), puisque, sur
le principe, Apache n'a besoin des droits de root que pour prendre le
bind sur le port 80 (et n'en a pas besoin par la suite, pour accepter
les sessions).

Maintenant, d'apres un autre post ici (de Cedric, je crois), il
semblerait que le process qui ecoute sur ce port 80 reste root (pour
des raisons qui m'echappent d'un point de vue technique).

il se trompe n'est ce pas ? un pirate peut reussir à passer root si un
processus est tjr sous root ?

D'abord je ne me "trompe" pas, puisque je n'ai rien "affirme".

Ensuite, un pirate prendra le controle d'une session "user", ses
possibilites vis a vis du process "root" (puisqu'apparemment il reste
un process root) dependront de la facon dont les 2 process causent
entre eux (SHM ? signaux ? pipes ?). Si le thread user n'a aucun moyen
d'envoyer des infos au process root (et la comme ca, je vois pas trop
ce qu'il aurait a lui dire a part "j'ai fini mon boulot, je me casse",
mais encore une fois, ma connaissance d'Apache est tres sommaire), bah
ca n'apporte pas de risque supplementaires d'avoir ce process root.


Enfin, meme avec un Apache 100% user des le depart, ca ne garantit
pas qu'un pirate ne pourra jamais passer root: il prendra la main sur
la machine (en user, donc), et a partir de la, il n'aura qu'a chercher
une autre facon de gagner les droits root, par exemple en exploitant
une faille locale qui n'aura pas ete corrigee parceque "ca sert a
rien, c'est un serveur il n'autorise pas les sessions locales".....


[Liste de vulberabilites]

Et attention au check "one time", c'est pas parcequ'il n'y a pas de
vulnerabilites connues un jour qu'il n'y en a pas du tout !!!



A +

VANHU.

Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2005.03.15.12.30.08.272501@cartel-securite.fr> :

Le Tue, 15 Mar 2005 12:28:34 +0000, Kevin Denis a écrit :

A ce propos; que penser d'une redirection de port?
apache ecoute sur le 8080 (donc en user de base). Une regle
iptables (dans le cas linux) qui redirige le 80 sur le 8080. Et
hop, plus de root a peu de frais.

C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture
globale.

Sauf si le serveur est sur le seul poste du réseau, qui fait alors
poste de travail, serveur et firewall, je ne pense pas que cela
complexifie vraiment l'architecture. Si tu n'as qu'une adresse IP
routable, tu seras de toute façon obligé de faire du NAT, il suffira
donc de rajouter la redirection de port au moment de faire les règles.
Et si le réseau dispose de plusieurs adresses IP routables, on a le
choix entre faire la redirection au niveau du routeur en bordure, ou
sur le firewall à l'entrée.
Je me demande même si au final ça n'augmente pas la sécurité relative
du réseau en lui-même. Les serveurs étant à l'écoute sur leurs ports
par défaut, vu de l'extérieur, un attaquant qui aurait réussi à entrer
sur le réseau sans avoir pour autant réussi à compromettre la
passerelle, ou le routeur ou le firewall en bordure, se cassera les
dents sur le port par défaut. Or, c'est le seul cas où ce port pourra
recevoir une connexion, ce qui me semble faire une très bonne alerte.
Même si l'attaquant arrive à spoofer l'adresse d'origine, il ne peut
qu'être à l'intérieur du réseau. Et comme il va devoir trouver le bon
port, ça laisse une petite marge de manoeuvre pour réagir.


--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos

OoO Peu avant le début de l'après-midi du mardi 15 mars 2005, vers
13:30, Cedric Blancher <blancher@cartel-securite.fr> disait:

tu ne pourras plus le faire tourner sur le port 80,
A ce propos; que penser d'une redirection de port?

apache ecoute sur le 8080 (donc en user de base). Une regle iptables (dans
le cas linux) qui redirige le 80 sur le 8080. Et hop, plus de root a
peu de frais.

C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture
globale.

L'intérêt d'avoir séparer les ports < 1024 des autres, c'était aussi
justement de ne pas permettre à n'importe qui d'usurper le serveur
Web. Bref, l'avantage de ne pas avoir à tourner root est contrebalancé
par le fait que l'on peut se faire piquer le port par un programme non
privilégié. Faut voir.
--
BOFH excuse #57:
Groundskeepers stole the root password

[...]

A ce propos; que penser d'une redirection de port?
Pas mal mais ça complique inutilement l'ensemble. Car si tu ne fais pas

confiance aux processus fils d'Apache tournant sous un utilisateur donné
et sur le port 80 tu ne leur feras pas davantage confiance si Apache
tourne sur le port 8080. Les processus fils n'ont pas d'accès au père
sinon depuis longtemps Apache serait à la poubelle.

Seuls intérêts de la règle en question :
le serveur apache n'est pas situé sur le firewall (j'espère du
reste) ;
gestion de la politique de bande passante.

db


--

Courriel : usenet blas net

Le 15-03-2005, Cedric Blancher <blancher@cartel-securite.fr> a écrit :

tu ne pourras plus le faire tourner sur le port 80,
A ce propos; que penser d'une redirection de port?

apache ecoute sur le 8080 (donc en user de base). Une regle iptables (dans
le cas linux) qui redirige le 80 sur le 8080. Et hop, plus de root a
peu de frais.

C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture globale.

J'aimerai clarifier le probleme en fait. Resumons.

1. Apache tourne sur le 80. Il demarre en root, puis passe en www-data.
Tu bosses sur ta machine en relation avec l'user www-data.

2. Apache tourne sur le 8080. Il demarre en user www-data. Tu bosses
sur ta machine en relation avec l'user www-data.

Avantage: on se defait completement du demarrage en root. Apache n'a
jamais l'uid 0.

La question majeure: est-ce que le fait qu'apache demarre en root
pose probleme?

Quelles attaques vers apache as t'on?

- Un script php/cgi/whatever qui est ecrit calamiteusement. Un pirate
en profite pour recuperer un shell. Dans les deux cas, le pirate n'a
que l'uid www-data sur la machine. Ok. (je me desinteresse dans le
cas present de la suite de ses activites)

- Un bon vieux buffer overflow sur apache. Premier cas: paf le pirate
recupere l'uid originelle d'apache, root, et en profites pour faire
ce qu'il souhaite. Deuxieme cas: le pirate ne peut travailler qu'a
partir de l'uid www-data de toute facon. [1]
Avantage leger a la solution 2 (leger car l'attaquant dispose quand
meme de la possibilite d'executer a distance du code)

Autant le premier cas m'a l'air theoriquement possible, autant je me
tate pour le deuxieme. Y'a t'il eu deja des cas de ce genre pour
apache? Plus precisement: apache droppe ses privileges, est-ce suffisant?


[1] En fait, j'ai vu y'a longtemps passer une attaque sur le sunrpc.
En gros, on envoie l'attaque, et la consequence du buffer overflow
correspondait a un script shell qui ajoutait a inetd.conf un shell root
puis qui killall -HUP inetd.
Cet exploit n'etait possible que grace au fait que le process tournait
en root. Imaginer la meme chose (modif d'un demon existant) avec un
user lambda me parait difficile.

--
Kevin

Le 16-03-2005, Dominique Blas <db@internet.invalid> a écrit :

A ce propos; que penser d'une redirection de port?
Pas mal mais ça complique inutilement l'ensemble.

C'est transparent pour le reste du reseau. Tout le reste continue de
communiquer par les voies normales (port 80).

Car si tu ne fais pas
confiance aux processus fils d'Apache tournant sous un utilisateur donné
et sur le port 80 tu ne leur feras pas davantage confiance si Apache
tourne sur le port 8080. Les processus fils n'ont pas d'accès au père
sinon depuis longtemps Apache serait à la poubelle.

Tu n'as pas compris. Dans les deux cas, apache utilise l'user www-data,

et dans les deux cas, tu n'auras qu'une confiance relative a cet user.

Le probleme ne reside pas dans l'user sous lequel tourne apache, mais
dans le fait qu'apache beneficie des droits root, meme temporairement.
La deuxieme question, connexe, est: est-ce reellement un probleme?

Seuls intérêts de la règle en question :
le serveur apache n'est pas situé sur le firewall (j'espère du
reste) ;
gestion de la politique de bande passante.

Aucun rapport. Cette redirection de port ni n'invalide ni ne permet

strictement ces deux phrases.

--
Kevin

Kevin Denis <kevin@nowhere.invalid> writes:
[....]

J'aimerai clarifier le probleme en fait. Resumons.

1. Apache tourne sur le 80. Il demarre en root, puis passe en www-data.
Tu bosses sur ta machine en relation avec l'user www-data.

2. Apache tourne sur le 8080. Il demarre en user www-data. Tu bosses
sur ta machine en relation avec l'user www-data.

Avantage: on se defait completement du demarrage en root. Apache n'a
jamais l'uid 0.

Inconvenient: si quelqu'un gagne l'acces www-data a la machine, il
peut stopper apache et demarrer ce qu'il veut a la place, puisque
c'est un bind sur un port non privilegie.


[...]

- Un bon vieux buffer overflow sur apache. Premier cas: paf le pirate
recupere l'uid originelle d'apache, root, et en profites pour faire
ce qu'il souhaite. Deuxieme cas: le pirate ne peut travailler qu'a
partir de l'uid www-data de toute facon. [1]
[....]

Autant le premier cas m'a l'air theoriquement possible, autant je me
tate pour le deuxieme. Y'a t'il eu deja des cas de ce genre pour
apache? Plus precisement: apache droppe ses privileges, est-ce suffisant?

Ca depend.

Sur les systemes UNIX, il y a 2 facons de lacher ses privileges (en
schematisant un peu, hein): la temporaire et la definitive.


La temporaire permet a un programme qui n'a besoin d'un privilege que
pour certaines occasions bien precises de le lacher le reste du
temps. Si un attaquant prend la main, ca reste possible de recuperer
les privileges en question (le programme y arrive, apres tout), bien
que ca ne soit pas trivial du tout.

Dans le second cas, le privilege est definitivement droppe, donc c'est
impossible a recuperer (enfin, pas avec un set*uid*() ou un "truc
affilie", il reste toujours la possibilite de chercher une autre
faille a exploiter pour augmenter ses privileges, bien sur).

La question qui reste est donc "est-ce que Apache droppe
definitivement les droits root quand il passe en www-data", et ma
reponse est "que je soie pendu si j'en ai la moindre idee !!!"...

Mais la reponse doit bien se trouver, au pire dans le code source
d'Apache....


A +

VANHU.

Le Wed, 16 Mar 2005 09:18:11 +0000, Kevin Denis a écrit :

1. Apache tourne sur le 80. Il demarre en root, puis passe en www-data.
Tu bosses sur ta machine en relation avec l'user www-data.

Non.
Apache démarre en root, et conserve un process sous cet UID. Il crée
ensuite des fils, chargés de traiter les connexions, qui eux sont sous
www-data :

$ ps aux |grep apache
root 5278 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache
www-data 5281 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache
www-data 5282 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache
www-data 5283 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache
www-data 5284 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache
www-data 5285 0.0 0.6 12028 5584 ? S 09:16 0:00 /usr/sbin/apache

2. Apache tourne sur le 8080. Il demarre en user www-data. Tu bosses sur
ta machine en relation avec l'user www-data.

Dans ce cas là, tout le monde, même le process de base, aura l'UID de
www-data.

Avantage: on se defait completement du demarrage en root. Apache n'a
jamais l'uid 0.

Oui, mais cela empêche certaines fonctionnalités que je trouve assez
utiles comme le suexec pour les CGI ou les scripts PHP.

[1. exploitation d'une page -> www-data
2. exploitation d'un bug et récupération de l'UID du père, donc root]

Autant le premier cas m'a l'air theoriquement possible, autant je me
tate pour le deuxieme. Y'a t'il eu deja des cas de ce genre pour apache?

Je ne crois pas, mais c'est à vérifier.


--
BOFH excuse #149:

Dew on the telephone lines.

Dans fr.comp.securite, vous ecriviez:

comment savoir si il y a des trous de sécurité dans ma version
d'apache
svp ? (1.3.29)

Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.

Le 16-03-2005, Cedric Blancher <blancher@cartel-securite.fr> a écrit :

1. Apache tourne sur le 80. Il demarre en root, puis passe en www-data.
Tu bosses sur ta machine en relation avec l'user www-data.

Non.

Cette derniere phrase n'est qu'a prendre en relation avec "complexifier
un peu l'architecture globale". A partir du moment ou l'on a defini une
politique de securite pour l'usager www-data, le fait de lancer apache
en root ou en www-data ne complexifie pas davantage la politique de
securite (sauf cas particulier, cf fin de post).

Apache démarre en root, et conserve un process sous cet UID. Il crée
ensuite des fils, chargés de traiter les connexions, qui eux sont sous
www-data :

Ok

2. Apache tourne sur le 8080. Il demarre en user www-data. Tu bosses sur
ta machine en relation avec l'user www-data.

Dans ce cas là, tout le monde, même le process de base, aura l'UID de
www-data.

Bin oui, c'est meme l'idee de base du truc.

Avantage: on se defait completement du demarrage en root. Apache n'a
jamais l'uid 0.

Oui, mais cela empêche certaines fonctionnalités que je trouve assez
utiles comme le suexec pour les CGI ou les scripts PHP.

Effectivement, la ca peche un peu. Apres, il faut vraiment en ch**r pour

s'en sortir (sudo etc..), et la, ok, ca complexifie le bouzin.


Finalement, pour trancher, cette methode: [pour] [contre] [bof]?
--
Kevin