Parmi les points notables de cette version 4.0 on peut relever la prise en charge de l'architecture UltraSparc III ou de plusieurs gadgets basés sur le processeur ARM. Le travail d''amélioration des pilotes pour les cartes wifi ou pour les cartes Gigabit ethernet continue ainsi que le combat du projet OpenBSD pour obtenir de la documentation de la part des firmes qui construisent ces matériels.
![[fr]](../images/fr.png)
OpenBSD (1153 hits)![[en]](../images/en.png)
Les nouveautés (427 hits)-
Liste complète des changements (237 hits)
-
Un journal sur la sortie (359 hits)
-
L'interview géante (283 hits)
> Lire la dépêche (56 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #771637.
Run by 
Cette page a été générée par Templeet en 0.0571s (dont 0.0051 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] Prelink
> En effet ce prelinking est incompatible avec le chargement aléatoire des librairies (address space randomization)
Pipo. Prelink de Linux est compatible avec des adresses aléaloires.
M'enfin, une news openBSD sans un troll sur Linux, ce n'est pas une news openBSD.
[^]Re: Prelink
Comme un commentaire de ta part sans un troll ou de la mauvaise foi, c'est pas un commentaire de ta part... :)
[^]Re: Prelink
>> Pipo. Prelink de Linux est compatible avec des adresses aléaloires.
Dans l'interview O'Reilly que j'ai donné en lien on peut lire ceci :
One of the significant security features in OpenBSD is address randomisation (aka ASLR). Prelinking as implemented in Linux removes the randomisation feature so it would not be compatible with OpenBSD's security goals.
Donc soit c'est toi qui a raison soit c'est Dale Rahn (soit j'ai mal compris mais ça me semble une hypothèse inenvisageable ;-).
[^]Re: Prelink
Je dois reconnaitre que je n'y connais pas grand chose dans ces trucs, voire qu'ils m'ennuient.
Plus haut, j'ai parlé de "compatibilité" et non dit que Linux le fournissait. Il y a Red Hat/Fedora qui fournit des fonctionnalités de "random address". Peut-être d'autre, je l'ignore.
Si j'ai bien compris, les adresses aléatoires sont utilisées au chargement pour l'édition de lien et fixer le début de la pile. Une installation typique Fedora fait ça. De même par défaut prelink est installé et activé (prelink des applis toutes les nuits).
L'adresse aléatoire de la pile n'implique pas prelink.
Par contre prelink n'est pas utilisé si le chargement des librairies est mis à une adresse alétoire (c'est le cas par défaut pour pratiquement toute les applis) et/ou si c'est du code indépendant (qui peut-être logé n'importe où et pas seulement pour les librairies ; c'est aussi le cas par défaut depuis FC3 je crois).
Bref, prelink est installé mais dans la majorité des cas non utilisé car "random addresse" est utilisé (ça ne concerne pas la pile).
Quelques info sur ce qui est fait dans RHEL/Fedora : http://people.redhat.com/drepper/nonselsec.pdf
> Donc soit c'est toi qui a raison soit c'est Dale Rahn
J'ai tord.
[^]Re: Prelink
En fait, ça dépend de ce que tu appelles randomization.
Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:
exemple:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
return 0;
}
Sur mon noyau 2.6.17, j'obtiens ça:
Donc, il y a bien "randomizaton" au niveau de la pile (en fait, aussi au niveau des appels à mmap()), mais pas au niveau du tas.
Mais faut pas croire que c'est la panacée: en effet, enfin la dernière fois que j'ai vérifié, la plage de randomization n'est pas énorme (64 kb pour la pile je crois). Quand tu enlèves les adresses quivontpas (alignement), bah en fait il te reste un ensemble assez restreint de valeurs, du coup rien ne t'empêche de faire une boucle au début de ton exploit.
Pour en revenir à la randomization et prelink:
http://lwn.net/Articles/121845/
Quand tu y penses, c'est carrément logique.
Néanmoins, voici ce qu'on peut lire:
Voilà voilà.
Enfin, je crois qu'on se retrouve toujours face au dilemme rapidité/sécurité. Entre les deux, il te faut choisir :-)
[^]Re: Prelink
Je suis pas réveillé, j'ai oublié un appel à free()...
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
free(c);
return 0;
}
P.S: on écrit "j'ai tort", et non pas "j'ai tord".
[^]Re: Prelink mais rien a voir
> P.S: on écrit "j'ai tort", et non pas "j'ai tord".
moyen mnémotechnique, le tort tue (génial)
[^]Re: Prelink
Je sais.
Et ton exemple (très parlant) est pour la pile/tas, non pour les adresses des fonctions.
> Depuis la version 2.6.11 (je crois) du kernel, on a une randomization partielle:
Regardes du côté de Fedora/Red Hat, il y a une randomization complète (avec exec-shield) mais ça ne marche pas pour prelink. Au chargement les adresses données par prelink sont ignorées (prelink est donc ignoré). On peut "réactivé" prelink mais les bibliothèques auront une adresse fixent (celles définis par prelink au moment de l'exécution de prelink).
[^]Re: Prelink
Oui. Mais comme je l'ai dit, ça s'applique aussi à mmap(), donc aux librairies dynamiques.
Pour exec-shield, ça a l'air pas mal. Je ne comprends pas pourquoi Debian ne propose pas un noyau déjà patché (même si c'est désactivé par défaut), ce serait plus pratique que d'avoir à télécharger le patch, l'appliquer etc.
Tiens, ce serait une bonne idée une version de noyau "serveur", avec un noyau durci.
[^]Re: Prelink
Ah, je retire ce que j'ai dit:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n;
int *c = malloc(sizeof(int));
printf("Pile: %p\n", (void *) &n);
printf("Tas: %p\n", (void *) c);
printf("Librairies: %p\n", (void *) fopen);
free(c);
return 0;
}
Me renvoie:
Bon, je sais que ce n'est pas ANSI de convertir un "function pointer" en "object pointer" (comment l'imprimer proprement?), mais n'empêche que ce n'est pas ce que j'attendais. Va falloir que je regarde ça de plus près, ça m'intrigue.