Translation(s): English - Français

Debian > Debian GNU > Debian GNU/kFreeBSD > kFreeBSD Sécurité


Notes à-propos de la sécurité du système d'exploitation Debian GNU/kFreeBSD

Support de la Sécurité

Wheezy (oldstable)

Les paquets reçoivent les mises-àjours planifiées via security.debian.org, comme les autres architectures.

Même, si nous sommes un 'aperçu de développement' dans Wheezy, nous avons sorti les mises à jours de sécurité planifiées vers kfreebsd-9 (9.0) et nous devrions continuer à le faire jusqu'à Mai 2016 (fin de vie officiel de Wheezy). Le noyau 9.0 ne sera plus supporté en amont, mais la stable/9 l'est toujours, et nous avons été capable de rétroporter tous les correctifs depuis.

Nous manquons de ressources pour participer à Wheezy LTS.

Le paquet kfreebsd-8 ne reçoit pas les mises à jours de sécurité planifiées. La fin de vie en amont de la stable/8 est de toute façon attendue pour le 30 Juin 2015.

kFreeBSD-Jessie (kFreeBSD-Stable)

Les paquets doivent recevoir les mises à jours planifiées via security.debian.org ; l'infrastructure est toujours debout. Les mises à jours de certains paquets peuvent être différées s'ils sont FTBFS dans kFreeBSD, openjdk-7 par exemple.

kFreeBSD-10 (10.1) doit avior un support en amont jusqu'au 31 Décembre 2016. Après cela nous pourrons rétroporter les correctifs depuis stable/10. Nous devrions être capable de le supporter jusqu'à la fin de vie de Jessie, probablement en 2018.

Je suis intéressé par une Jessie LTS, mais il est trop tôt pour faire des promesses à ce sujet. Nous pouvons même considéré un noyau "jessie-and-a-half" mise à jour vers 10.3, si cela doit faciliter la tâche.

Mesures d'atténuations des Exploits

ASLR

FreeBSD n'a implémenté ASLR qu'après la version 10.1. Il sera disponible dans les versions ultérieures.

Cependant, sur GNU/kFreeBSD, cela ne fonctionne pas non plus. Peu importe si un exécutable a été compilé en tant que PIE, les données du programme sont toujours chargées à un décalage prévisible. L'ordre de chargement des bibliothèques partagées, la place d'où elles sont chargées, le décalage dans la pile, et les segments mmap(), semblent être toujours les mêmes.

OpenBSD peut chargé aléatoirement toutes ces choses (lisez http://www.openbsd.org/papers/ven05-deraadt/index.html).

GNU/Linux Wheezy applique ALSR sur de nombreux endroits de la pile et le tas, et le code exécutable s'il est PIE. Mais pour autant que je puisse dire, ce n'est pas le cas des autres choses. La fonction malloc() de la GNU Libc ne semble pas avoir plus d'aléas.

nxstack

Démarrer dans Jessie kFreeBSD-10, les piles non exécutables sont renforcées par défaut. Les suites de tests de GLibc ont déjà montrés qu'elles sont fonctionnelles. SELinux prend en charge quelque chose de similaire, mais ce n'est pas activé par défaut dans Debian GNU/Linux.

Nous pourrions voir des régressions à cause de cela, mais FreeBSD, en amont, pense que cela est bon de l'activer. Cela a déclenché le bogue 765070 dans la suite de test openrc, qui a mis en lumière du code suspicieux (qui ne satisfait pas le principe W^X) et qui a été corrigé ; c'est donc génial. Il était passé inaperçu sous Linux. Nous pouvons trouver plus de problèmes comme celui-ci maintenant que nos buildds exécutent kFreeBSD-10.

DEB_BUILD_HARDENING_STACKPROTECTOR (gcc/g++ -fstack-protector-strong)

Cette fonctionnalité de GCC fonctionne bien sur GNU/kFreeBSD tout comme sur GNU/Linux. Un canari aléatoire est placé dans la pile avant le pointeur de retour, la protégeant d'un dépassement de mémoire tampon.

*** stack smashing detected ***: foo terminated
Aborted

DEB_BUILD_HARDENING_RELRO (ld -z relro)

C'est juste un drapeau de l'éditeur de liens GNU, donc dans les paquets Debian qui l'activent pour GNU/Linux, il devrait être aussi activé pour GNU/kFreeBSD. Confirmant que cela fonctionne :

$ hardening-check foo
foo:
 Read-only relocations: yes

$ objdump -x foo
   RELRO off    0x0000000000000e10 vaddr 0x0000000000600e10 paddr 0x0000000000600e10 align 2**0
         filesz 0x00000000000001f0 memsz 0x00000000000001f0 flags r--

Quand elle est exécutée, la section RELRO (la seconde ligne) est vue pour être mappé en lecture seule :

00400000-00401000 r-xp 00003000 00:00 1195251     foo
00600000-00601000 r--p 00003000 00:00 1195251     foo

DEB_BUILD_HARDENING_BINDNOW (ld -z now)

Il est possible de l'activer sur GNU/kFreeBSD comme sur GNU/Linux. Je ne sais pas comment confirmer si cela protège réellement la section GOT comme cela devrait.

$ hardening-check foo
relro-now:
 Read-only relocations: yes

$ objdump -x foo
  BIND_NOW             0x0000000000000000

DEB_BUILD_HARDENING_FORMAT, _FORTIFY

Ce sont juste de drapeaux de GCC, ainsi ils fonctionnent pareils sur GNU/kFreeBSD et sur GNU/Linux.

in-kernel

Je pense que cette protection de la pile n'est "pas"' encore utilisée.

Cela est activé dans GNU/Linux depuis Jessie, protégeant contre les parcours de /tmp et similaires. Mais n'est pas dans GNU/kFreeBSD. FreeBSD a une fonctionnalité vaguement similaire, mais elle n'est pas activée par défaut.