© 2004-2005 Richard Bejtlich (taosecurity at gmail dot com)
[NdT : The original article may be find at www.taosecurity.com/keeping_freebsd_up-to-date.html]
Traduction : Thomas van Oudenhove (juillet 2005)
Un important travail de l'administrateur système, qui constitue un des principes pour défendre son réseau, est de maintenir les systèmes d'exploitation et les applications à jour. Utiliser des programmes à jour est vital lorsque des versions plus anciennes sont vulnérables. De plus, de nouvelles fonctionnalités peuvent être intégrées aux dernières versions. Par chance, les projets open source offrent différents moyens aux utilisateurs de maintenir un système sécurisé et en état de marche.
Cet article présente plusieurs facettes de la maintenance de FreeBSD. J'ai pris les avis de sécurité d'un FreeBSD 5.2.1 RELEASE pour expliquer les différents types de patch qu'un administrateur peut avoir à appliquer. La maintenance d'applications tierce-partie pour FreeBSD est décrite dans cet article : Keeping FreeBSD Applications Up-to-date
Mon choix s'est porté sur FreeBSD 5.2.1 comme référence, disponible depuis février 2004, pour pouvoir décrire, grâce à son histoire à propos de sécurité, plusieurs façons de mettre à jour. À l'heure où j'écris, FreeBSD 5.3 RELEASE n'a qu'un mois, et seulement deux avis de sécurité ont été publiés. Des lecteurs se demandant pourquoi installer une "vieille" version du système d'exploitation peuvent imaginer qu'il y a peut-être une application supportée seulement par FreeBSD 5.2.1 et non encore officiellement portée sur FreeBSD 5.3, obligeant un administrateur à utiliser une version 5.2.1.
Tout le travail fait dans cet article a été fait à distance via OpenSSH. Un des dangers lors de mises à jour à distance est de perdre la connexion pendant une étape critique. Une astuce logicielle pour amoindrir le risque consiste à utiliser screen. Avec screen(1), si la connexion est perdue lors de la mise à jour, la session continuera sans interruption. Cependant, screen(1) a souffert de failles de sécurité dans le passé, alors pesez le pour et le contre entre ses fonctionnalités et ses risques.
Mes conseils pour l'administration de cette plate-forme de référence sont basés sur le déploiement de FreeBSD sur des serveurs, des stations de travail et des portables depuis 2000. Cet article est un mélange de mes interprétations de la documentation officielle de FreeBSD, de conseils de mentors et de mon expérience personnelle. Ce guide ne doit pas être considéré comme une référence complète sur la mise à jour de FreeBSD et la maintenance d'un système sécurisé.
Si vous lisez une copie en dur de ce document, le côté droit de la page peut être coupé. Celui-ci peut être important lorsque des URL longs ou des lignes de commandes sont montrés. Référez-vous à la version HTML de ce document pour la version complète.
Avant d'expliquer les façons de maintenir le système d'exploitation FreeBSD à jour, je dois brièvement expliquer le terme "à jour" [NdT : up-to-date]. Grâce à la méthode de développement de FreeBSD, chaque version est disponible via CVS (Concurrent Versions System). Ces versions sont représentées par des étiquettes CVS. Les exemples suivants illustrent le fonctionnement des étiquettes pour FreeBSD 5.3 RELEASE :
Les utilisateurs de Linux noteront que ces étiquettes CVS ne correspondent pas seulement au noyau FreeBSD. FreeBSD est développé comme un système intégré, comprenant un noyau et des outils utilisateur [NdT : userland, appellé aussi "le monde"]. Il ne faut pas utiliser un noyau compilé pour FreeBSD 5.3 RELEASE sur une machine en CURRENT. Le noyau et le monde sont faits pour être mis à jour en même temps, et doivent être synchronisés. Si les utilisateurs de Linux sont habituellement obligés de connaître ces bonnes pratiques d'administration système lorsqu'ils effectuent un changement de version majeur du noyau (par exemple, 2.2 à 2.4, ou 2.4 à 2.6), ils gardent souvent les outils utilisateurs lors de changements mineurs de version du noyau. FreeBSD encourage fortement les utilisateurs à toujours garder le monde et le noyau synchronisés en utilisant les méthodes décrites dans le HandBook et dans ce document.
En regardant ce que veut dire d'être "à jour", on peut voir que la "plus vieille" version de FreeBSD dans la branche 5.3 est celle qui a été le plus récemment pressée sur CD : RELENG_5_3_0_RELEASE ou FreeBSD 5.3 RELEASE. La "plus récente" serait HEAD ou CURRENT, qui est constamment modifiée et améliorée quotidiennement. Comment un administrateur peut-il décider quelle version utiliser sur ses machines ?
Je préfère commencer la vie d'une machine en installant les versions RELEASE, par exemple FreeBSD 5.3 RELEASE. Tant que le système se comporte comme je m'y attends, je suis la branche de sécurité RELENG_5_3. Cela me permet d'incorporer les corrections de bugs et les patchs de sécurité pour ne pas nuire à la sécurité du système.
Occasionnellement, il m'arrive d'avoir besoin d'une fonctionnalité (par exemple, le support d'un nouveau matériel) non implémentée dans la branche RELEASE. Si cette fonctionnalité est supportée par la branche STABLE, je vais mettre à jour en utilisant cette dernière. Dans les rares cas où même STABLE ne propose pas cette fonctionnalité, il se peut que j'installe une image de la branche CURRENT. Je ne recommande pas d'utiliser CURRENT dans un environement de production car elle n'est pas aussi bien supportée que les versions RELEASE ou STABLE.
Les avis de sécurité de FreeBSD sont publiés sur la page sécurité et sur la liste de diffusion dédiée. Je recommande à tous les utilisateurs de FreeBSD de s'abonner à cette liste modérée, dont le traffic est très bas. Ces avis de sécurité comprennent le contexte, la description du problème, les éventuels impacts, des conseils pour contourner le problème, une solution pour régler le problème et les détails pour corriger. Nous aborderons plus tard les avis de sécurité, quand nous regarderons comment appliquer des patchs à la main.
Commençons par un scénario classique de déploiement, en utilisant FreeBSD 5.2.1 RELEASE comme référence. Pour cette version, l'étiquette CVS est RELENG_5_2_1_RELEASE pour la version du CD et RELENG_5_2 pour la branche sécurité. (RELENG_5_2 s'applique aussi à FreeBSD 5.2.1.)
L'administrateur installe FreeBSD 5.2.1 RELEASE depuis le CD sur une nouvelle machine. Il installe l'ensemble "développeur" pour avoir le système complet (sources, binaires, documentation) sans les jeux. Lorsque l'installation est terminée, uname montre la version du système avant toute modification :
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
Il n'y a pas de besoin de modifications du noyau, c'est donc le "GENERIC" [NdT : fichier de configuration générique du noyau] qui est utilisé. Aucune nouvelle fonctionnalité de la version STABLE n'est nécessaire ; l'administrateur décide de suivre la branche de sécurité 5.2.
Les administrateurs commençant avec un système RELEASE, qui ne changent pas le noyau générique et qui n'ont fait aucun changement sur le monde, sont encouragés à utiliser les mises à jour binaires. Les mises à jour binaires remplacent les fichiers copiés depuis le CD original par les versions mises à jour patchées pour régler les problèmes de sécurité.
En utilisant l'outil de mise à jour de Colin Percival, l'administrateur peut rapidement mettre son système à jour par rapport à la branche de sécurité 5.2. Rappellez-vous que ce système doit être une installation RELEASE de base sans aucun changement ni au noyau, ni au monde, pour pouvoir tirer parti de "FreeBSD Update" pour les problèmes de sécurité.
L'administrateur installe et lance "FreeBSD Update" en récupérant cet outil comme un package précompilé. (Reconstruire l'outil depuis les sources grâce au système des ports est une autre option, et devrait être préférée d'un point de vue sécurité.)
freebsd521:/root# pkg_add -vr freebsd-update looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 setting passive mode opening data connection initiating transfer Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/freebsd-update.tbz... +CONTENTS ...edited... extract: Package name is freebsd-update-1.4 extract: CWD to /usr/local extract: /usr/local/man/man5/freebsd-update.conf.5.gz extract: /usr/local/man/man8/freebsd-update.8.gz extract: /usr/local/sbin/freebsd-update extract: /usr/local/sbin/freebsd-update-verify extract: /usr/local/etc/freebsd-update.conf.sample extract: /usr/local/share/doc/freebsd-update/LICENSE extract: /usr/local/share/doc/freebsd-update/README extract: /usr/local/share/doc/freebsd-update/VERSION extract: CWD to . Running mtree for freebsd-update-1.4.. mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null Attempting to record package into /var/db/pkg/freebsd-update-1.4.. Trying to record dependency on package 'bsdiff-4.1' with 'misc/bsdiff' origin. Package freebsd-update-1.4 registered in /var/db/pkg/freebsd-update-1.4
Avant de pouvoir l'utiliser, vous devrez créer un fichier de configuration des mises à jour spécifiant le serveur où récupérer ces mises à jour et l'empreinte de la clef publique. Un exemple de fichier de configuration a été installé dans /usr/local/etc/freebsd-update.conf.sample qui récupérera les mises à jour construites par l'auteur. Si vous faites confiance à l'auteur pour construire des binaires suffisament sûrs pour que vous les installiez sur votre serveur, copiez ce fichier dans : /usr/local/etc/freebsd-update.conf ; sinon, créez ce fichier comme bon vous semble.
Si vous trouvez "FreeBSD Update" utile, vous pouvez envisager de soutenir son auteur par un don.
Ensuite, l'administrateur crée le répertoire nécessaire, et fait une copie du fichier de configuration par défaut :
freebsd521:/root# mkdir -p /usr/local/freebsd-update freebsd521:/root# cp /usr/local/etc/freebsd-update.conf.sample /usr/local/etc/freebsd-update.conf
Enfin, il est prêt à récupérer puis appliquer les mises à jour. Rappellez-vous de lancer rehash si vous devez mettre à jour la table de hachage de la variable $PATH utilisée par le "shell" csh :
freebsd521:/root# freebsd-update fetch Fetching public key... Fetching updates signature... Fetching updates... Fetching hash list signature... Fetching hash list... Examining local system... Fetching updates... /boot/kernel/kernel... /boot/kernel/linux.ko... /lib/libcrypto.so.3... /usr/bin/cvs... /usr/bin/fetch... /usr/include/krb5-protos.h... /usr/include/netinet/ip6.h... /usr/include/netinet/tcp_var.h... /usr/include/openssl/opensslv.h... /usr/lib/libcrypto.a... /usr/lib/libcrypto_p.a... /usr/lib/libkrb5.a... /usr/lib/libkrb5.so.7... /usr/lib/libkrb5_p.a... /usr/lib/libssl.a... /usr/lib/libssl.so.3... /usr/lib/libssl_p.a... /usr/libexec/kdc... /usr/share/man/man8/kdc.8.gz... Updates fetched
Pour installer ces mises à jour, utilisez la commande : /usr/local/sbin/freebsd-update install. N'oubliez pas de reconstruire les ports ayant des liens statiques avec les bibliothèques mises à jour.
Nous remarquons que cette application a téléchargé plusieurs fichiers, parmi lesquels un nouveau noyau (kernel), un nouveau module du noyau (linux.ko) et autres binaires, bibliothèques et pages de manuel. Ensuite, l'administrateur applique les patchs :
freebsd521:/root# freebsd-update install Backing up /boot/kernel/kernel... Installing new /boot/kernel/kernel... Backing up /boot/kernel/linux.ko... Installing new /boot/kernel/linux.ko... Backing up /lib/libcrypto.so.3... Installing new /lib/libcrypto.so.3... Backing up /usr/bin/cvs... Installing new /usr/bin/cvs... ...edited... Backing up /usr/share/man/man8/kdc.8.gz... Installing new /usr/share/man/man8/kdc.8.gz...
Une fois ceci terminé, il faut rebooter le système. Un reboot est nécessaire parce que le noyau a été mis à jour. Après le reboot, remarquez le changement sur la sortie de la commande uname.
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-SECURITY FreeBSD 5.2.1-SECURITY #0: Tue Sep 28 17:27:41 GMT 2004 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
Alors que précédemment, uname retournait "5.2.1-RELEASE" comme version, avec une compilation du noyau datée du "Mon Feb 23 20:45:55 GMT 2004", la branche de sécurité retourne "5.2.1-SECURITY" et "Tue Sep 28 17:27:41 GMT 2004". Vous pouvez vérifier qu'il n'ya a pas de nouvelle mise à jour à effectuer en relançant "FreeBSD Update" :
freebsd521:/root# freebsd-update fetch Fetching updates signature... Fetching hash list signature... Examining local system... No updates available
Comme aucune nouvelle mise à jour n'est disponible, le système est correctement patché.
"FreeBSD Update" est un outil rudimentaire mais très pratique pour maintenir une machine sûre sous FreeBSD. Son inconvénient majeur est son incapacité à mettre à jour un noyau modifié par l'administrateur. En effet, il est impossible pour Colin d'imaginer toutes les adaptations différentes que l'on peut faire sur un noyau, il se cantonne donc à la construction de mises à jour binaires pour le noyau GENERIC. Alors que le noyau GENERIC convient pour de nombreux déploiements, le besoin du support IPSec, par example, peut obliger un administrateur à personnaliser le noyau.
"FreeBSD Update" est aussi incapable de gérer des changements au monde s'ils dévient de la branche RELEASE. Si un administrateur bricole avec certains drivers ou outils, "FreeBSD Update" ne pourra pas effectuer leur mise à jour.
Cependant, Colin Percival, l'auteur de "FreeBSD Update", fait remarquer :
"FreeBSD Update" peut être forcé à télécharger des patchs de sécurité pour des fichiers ayant été localement modifiés en utilisant l'option --branch (à partir de la version 1.5). Ici, les branches sont "nocrypto", "crypto", "krb4" et "krb5" ; la plupart des utilisateurs utilisent un système avec cryptographie, mais sans le support de Kerberos, ils utiliseront donc "--branch crypto". Bien évidemment, cela écrasera tous les changements locaux effectués sur les fichiers à mettre à jour, mais ce peut être pratique si le monde a été recompilé sans changer de fichiers.
"FreeBSD Update" peut vous paraître trop simple pour vos besoins. Ainsi, vous souhaitez garder la possibilité de travailler avec vos sources ou d'utiliser un noyau personnalisé. Dès que vous changez le monde ou le noyau par rapport à ce qui est proposé par RELEASE, les mises à jour binaires peuvent poser des problèmes.
Cette section illustre les commandes pour patcher un système FreeBSD 5.2.1 RELEASE. Les administrateurs se tiennent au courant des problèmes de sécurité en lisant les avis de sécurité, il est donc utile de jeter un œil à ces avis.
Commençons ce guide pour patcher manuellement par regarder le premier avis de sécurité affectant FreeBSD 5.2.1 RELEASE :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:04.tcp Security Advisory
The FreeBSD Project
Topic: many out-of-sequence TCP packets denial-of-service
Category: core
Module: kernel
Announced: 2004-03-02
Revised: 2004-03-16
Credits: iDEFENSE, Alexander Cuttergo
Affects: All FreeBSD releases
Corrected: 2004-03-02 17:19:18 UTC (RELENG_4)
2004-03-16 13:47:33 UTC (RELENG_5_2, 5.2.1-RELEASE-p2)
2004-03-15 20:02:06 UTC (RELENG_5_1, 5.1-RELEASE-p15)
2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3)
2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16)
2004-03-17 10:50:45 UTC (RELENG_4_7, 4.7-RELEASE-p26)
CVE Name: CAN-2004-0171
FreeBSD only: NO
0. Revision History
v1.0 2004-03-02 Initial release.
v1.1 2004-03-17 Fix minor performance issue in 5.2.1 patch.
Corrections for RELENG_5_1 and RELENG_4_7 added.
Note Alexander Cuttergo as the discoverer of this issue.
I. Background
The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
provides a connection-oriented, reliable, sequence-preserving data
stream service. When network packets making up a TCP stream (``TCP
segments'') are received out-of-sequence, they are maintained in a
reassembly queue by the destination system until they can be
re-ordered and re-assembled.
II. Problem Description
FreeBSD does not limit the number of TCP segments that may be held in
a reassembly queue.
III. Impact
A remote attacker may conduct a low-bandwidth denial-of-service attack
against a machine providing services based on TCP (there are many such
services, including HTTP, SMTP, and FTP). By sending many
out-of-sequence TCP segments, the attacker can cause the target
machine to consume all available memory buffers (``mbufs''), likely
leading to a system crash.
IV. Workaround
It may be possible to mitigate some denial-of-service attacks by
implementing timeouts at the application level.
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2,
RELENG_4_9, or RELENG_4_8 security branch dated after the correction
date.
OR
2) Patch your present system:
The following patch has been verified to apply to FreeBSD 4.x and 5.x
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 5.2]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc
...edited...
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and
reboot the system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch
Path
-------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING
src/sys/conf/newvers.sh
src/sys/netinet/tcp_input.c
src/sys/netinet/tcp_subr.c
src/sys/netinet/tcp_var.h
...edited...
-------------------------------------------------------------------------
VII. References
<URL:http://www.idefense.com/application/poi/display?id=78&type=vulnerabilities>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAWC4yFdaIBMps37IRAgulAJ93O5yH4Z49oTx4HEdRJK+6sLco2gCfYCEZ
NpPTCWlG1oyLjOL2y6zKBfs=
=Naox
-----END PGP SIGNATURE-----
L'avis FreeBSD-SA-04:04.tcp décrit une condition pouvant amener à un déni de service dans le noyau FreeBSD. C'est le noyau qui gère les paquets TCP, donc ce dernier doit être mis à jour.
Nous voyons que la solution à ce problème exige une mise à jour pour la branche RELENG_5_2 datée d'après la révision des fichiers affectés par cet avis, ou l'application du patch situé à cet endroit pour FreeBSD 5.2 : ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.
Ici, nous montrons comment appliquer un patch au noyau, puis recompiler le noyau. Lorsque wget(1) est utilisé, vous pouvez préférer fetch(1) si wget(1) n'est pas installé sur votre système.
La première étape consiste à installer GNU Privacy Guard (gpg) de façon à pouvoir vérifier l'authenticité du patch. Nous pourrons ensuite importer la clef publique de l'officier de sécurité FreeBSD :
freebsd521:/root# pkg_add -vr gnupg ...edited... Package gnupg-1.2.3_4 registered in /var/db/pkg/gnupg-1.2.3_4 freebsd521:/root# rehash freebsd521:/root# gpg --version gpg (GnuPG) 1.2.3 Copyright (C) 2003 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256 Compression: Uncompressed, ZIP, ZLIB freebsd521:/root# wget ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc ...edited... freebsd521:/root# gpg --import public_key.asc gpg: /root/.gnupg: directory created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key CA6CDFB2: public key "FreeBSD Security Officer <security-officer@FreeBSD.org>" imported gpg: Total number processed: 1 gpg: imported: 1
Éventuellement, vous pouvez aussi rapatrier les clefs de tous les développeurs sur votre disque dur :
freebsd521:/root# gpg --import /usr/share/doc/en_US.ISO8859-1/books/handbook/pgpkeys-developers.html
Ensuite, nous téléchargeons le patch et la signature GPG, puis nous vérifions la signature :
freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch Receiving tcp52.patch (6182 bytes): 100% 6182 bytes transferred in 0.1 seconds (49.28 kBps) freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc Receiving tcp52.patch.asc (186 bytes): 100% 186 bytes transferred in 0.0 seconds (23.98 kBps) freebsd521:/root# gpg --verify tcp52.patch.asc tcp52.patch gpg: Signature made Tue Mar 2 12:10:17 2004 EST using DSA key ID CA6CDFB2 gpg: Good signature from "FreeBSD Security Officer <security-officer@FreeBSD.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C374 0FC5 69A6 FBB1 4AED B131 15D6 8804 CA6C DFB2
GPG émet un avertissement car nous n'avons pris aucune précaution pour vérifier la signature de l'officier de sécurité FreeBSD. Un des moyens de ne plus avoir cet avertissement serait de signer nous-mêmes la clef de l'officier de sécurité FreeBSD. Nous pourrions faire cela après confirmation de vive voix ou au téléphone que l'empreinte de la clef est bien la bonne. (Après cet exemple, je ne montrerai plus la vérification des patchs.)
À partir de maintenant, nous supposons que le patch tcp.52 n'a pas été corrompu, et nous allons l'appliquer selon les instructions de l'avis :
freebsd521:/usr/src# patch < /root/tcp52.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |? tcp_reass-5.2.1-20040301.patch |Index: tcp_input.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v |retrieving revision 1.217.2.1 |diff -u -p -r1.217.2.1 tcp_input.c |--- sys/netinet/tcp_input.c 9 Jan 2004 12:32:36 -0000 1.217.2.1 |+++ sys/netinet/tcp_input.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_input.c using Plan A... Hunk #1 succeeded at 57. Hunk #2 succeeded at 99. Hunk #3 succeeded at 134. Hunk #4 succeeded at 192. Hunk #5 succeeded at 215. Hunk #6 succeeded at 226. Hunk #7 succeeded at 276. Hunk #8 succeeded at 312. Hunk #9 succeeded at 347. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_subr.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v |retrieving revision 1.169.2.3 |diff -u -p -r1.169.2.3 tcp_subr.c |--- sys/netinet/tcp_subr.c 23 Feb 2004 15:32:55 -0000 1.169.2.3 |+++ sys/netinet/tcp_subr.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_subr.c using Plan A... Hunk #1 succeeded at 286. Hunk #2 succeeded at 709. Hunk #3 succeeded at 771. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_var.h |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v |retrieving revision 1.93.2.1 |diff -u -p -r1.93.2.1 tcp_var.h |--- sys/netinet/tcp_var.h 9 Jan 2004 12:32:36 -0000 1.93.2.1 |+++ sys/netinet/tcp_var.h 1 Mar 2004 15:18:55 -0000 -------------------------- Patching file sys/netinet/tcp_var.h using Plan A... Hunk #1 succeeded at 54. Hunk #2 succeeded at 513. done
Maintenant que le patch est appliqué, nous devons recompiler le noyau. Comme nous allons recompiler le noyau, nous pouvons effectuer des changements dans sa configuration. Nous copions donc le noyau GENERIC vers un fichier nommé pour notre système (freebsd521). Les lecteurs familiers des conventions de nommage de FreeBSD pourront remarquer que les fichiers de configuration du noyau sont généralement en capitales, par exemple FREEBSD521. Cette différence n'influence pas le résultat, mais les lecteurs sont tout de même encouragés à utiliser la convention de nommage en capitales.
freebsd521:/usr/src# cd /usr/src/sys/i386/conf freebsd521:/usr/src/sys/i386/conf# cp GENERIC freebsd521
Ensuite, nous opérons quelques changements pour ôter le support des processeurs Intel 486 et 586 et changer l'identifiant du noyau par le nom de notre machine :
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394.2.3 2004/01/26 19:42:11 nectar Exp $
machine i386
#cpu I486_CPU
#cpu I586_CPU
cpu I686_CPU
#ident GENERIC
ident freebsd521
Nous pourrions faire des dizaines d'autres changements, comme ôter le support de matériel non présent, ou faire des optimisations. Je recommande de revoir le HandBook ou l'un des excellents livres traitant de FreeBSD pour plus d'informations sur les modifications du noyau.
Enfin, nous pouvons compiler et installer le nouveau noyau :
freebsd521:/usr/src# make buildkernel KERNCONF=freebsd521 -------------------------------------------------------------- >>> Kernel build for freebsd521 started on Sat Nov 27 19:45:44 EST 2004 -------------------------------------------------------------- ===> freebsd521 mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games: /usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr /src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/freebsd521 /usr/src/sys/i386/conf/freebsd521 Kernel build directory is /usr/obj/usr/src/sys/freebsd521 ...edited... -------------------------------------------------------------- >>> Kernel build for freebsd521 completed on Sat Nov 27 21:25:30 EST 2004 -------------------------------------------------------------- freebsd521:/usr/src# make installkernel KERNCONF=freebsd521 cd /usr/obj/usr/src/sys/freebsd521; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr /src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy /usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy /usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy /usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr /bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install ...edited... ===> vesa install -o root -g wheel -m 555 vesa.ko /boot/kernel kldxref /boot/kernel freebsd521:/usr/src# shutdown -r now
Après le reboot, la sortie de uname est légèrement différente :
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Sat Nov 27 20:36:48 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386
À l'origine, le noyau était GENERIC alors que uname affiche maintenant un noyau appellé freebsd521.
Cet exemple montre comment patcher et recompiler le noyau FreeBSD. Le principal inconvénient de cette méthode est le temps requis pour recompiler et installer le noyau, qui peut être assez long sur de vieilles machines. Il est possible de recompiler le noyau et le monde sur une vieille machine, puis de les installer sur une machine plus ancienne. J'ai écrit dans mon Blog comment faire cela ; l'entrée se nomme "Building Kernel and World on One System, Installing on Another".
Dans la section précédente, nous avons patché, recompilé puis réinstallé le noyau FreeBSD. Les vulnérabilités du noyau sont moins fréquentes que celles du monde. Dans cette section, nous allons voir comment patcher, recompiler et réinstaller des applications du monde. Cette approche sera illustrée par le deuxième avis de sécurité affectant FreeBSD 5.2.1 :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:05.openssl Security Advisory
The FreeBSD Project
Topic: Denial-of-service vulnerability in OpenSSL
Category: crypto
Module: openssl
Announced: 2004-03-17
Credits: OpenSSL Project <URL:http://www.openssl.org>
Codenomicon Ltd <URL:http://www.codenomicon.com>
Affects: All FreeBSD 4.x and 5.x releases
Corrected: 2004-03-17 12:23:51 UTC (RELENG_4, 4.9-STABLE)
2004-03-17 12:14:12 UTC (RELENG_5_2, 5.2.1-RELEASE-p3)
2004-03-17 12:14:56 UTC (RELENG_5_1, 5.1-RELEASE-p16)
2004-03-17 12:17:13 UTC (RELENG_4_9, 4.9-RELEASE-p4)
2004-03-17 12:18:23 UTC (RELENG_4_8, 4.8-RELEASE-p17)
CVE Name: CAN-2004-0079
FreeBSD only: NO
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/ >.
I. Background
FreeBSD includes software from the OpenSSL Project. The OpenSSL
Project is a collaborative effort to develop a robust, commercial-
grade, full-featured, and Open Source toolkit implementing the Secure
Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1)
protocols as well as a full-strength general purpose cryptography
library.
II. Problem Description
When processing an SSL/TLS ChangeCipherSpec message, OpenSSL may fail to
check that a new cipher has been previously negotiated. This may result
in a null pointer dereference.
III. Impact
A remote attacker could perform a specially crafted SSL/TLS handshake
with an application that utilizes OpenSSL, triggering the null pointer
dereference and causing the application to crash. Depending upon the
specifics of the application, this may result in an effective
denial-of-service.
IV. Workaround
No workaround is known.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_2,
RELENG_4_9, or RELENG_4_8 security branch dated after the correction
date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.8,
4.9, 5.1, and 5.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system as described in
<URL: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >.
Note that any statically linked applications that are not part of the
base system (i.e. from the Ports Collection or other 3rd-party sources)
must be recompiled.
All affected applications must be restarted for them to use the
corrected library. Though not required, rebooting may be the easiest
way to accomplish this.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING 1.282.2.11
src/crypto/openssl/crypto/opensslv.h 1.1.1.14.2.1
src/crypto/openssl/ssl/s3_pkt.c 1.1.1.8.4.1
src/sys/conf/newvers.sh 1.56.2.10
...edited...
- -------------------------------------------------------------------------
VII. References
<URL: http://www.openssl.org/news/secadv_20040317.txt >
<URL: http://cvs.openssl.org/chngview?cn=12033 >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAWH8nFdaIBMps37IRAgsZAKCPXaoTb16c8JGJL+Uz7eOX8/864ACbB059
AIfN8fbeiGJ3fdG0pKAMwMw=
=2f24
-----END PGP SIGNATURE-----
Pour cet exemple, nous allons télécharger le patch, l'appliquer, puis recompiler et réinstaller le monde. Pour procéder ainsi, vous devez avoir toutes les sources du système. Sans ces sources, FreeBSD ne peut pas recompiler les outils utilisateur. Comme notre administrateur a installé l'ensemble "développeur", nous avons toutes les sources, binaires et la documentation à notre disposition.
Si vous n'avez pas l'ensemble requis, vous pouvez l'installer grâce à /stand/sysinstall (nouvellement /usr/sbin/sysinstall) ou les rapatrier via CVS. Je vous recommande de les rapatrier par CVS, comme expliqué dans la section "Mise à jour par CVSup de la branche sécurité 5_2" plus bas.
freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch ...edited... freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:05/openssl.patch.asc freebsd521:/root# cd /usr/src freebsd521:/usr/src# patch < /root/openssl.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: crypto/openssl/ssl/s3_pkt.c |=================================================================== |RCS file: /home/ncvs/src/crypto/openssl/ssl/s3_pkt.c,v |retrieving revision 1.1.1.8 |diff -c -r1.1.1.8 s3_pkt.c |*** crypto/openssl/ssl/s3_pkt.c 19 Feb 2003 23:17:05 -0000 1.1.1.8 |--- crypto/openssl/ssl/s3_pkt.c 16 Mar 2004 13:18:28 -0000 -------------------------- Patching file crypto/openssl/ssl/s3_pkt.c using Plan A... Hunk #1 succeeded at 1085. done freebsd521:/usr/src# make buildworld -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/i386 mkdir -p /usr/obj/usr/src/i386/legacy/usr/bin mkdir -p /usr/obj/usr/src/i386/legacy/usr/games mkdir -p /usr/obj/usr/src/i386/legacy/usr/include/sys ...edited... ===> etc ===> etc/sendmail rm -f freebsd.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf chmod 444 freebsd.cf rm -f freebsd.submit.cf m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/ /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf chmod 444 freebsd.submit.cf
Avant de passer à l'étape suivante, nous remarquons que l'avis FreeBSD-SA-04:06.ipv6 nous avertit par rapport à un malfaisant local qui pourrait accéder à la mémoire du noyau ou aboutir à des paniques du noyau. Nous décidons donc d'implémenter le contournement du problème :
1) Disable IPv6 entirely by following these steps:
- Remove or comment out any lines mentioning `INET6' from your
kernel configuration file, and recompile your kernel as described
in <URL:http://www.freebsd.org/handbook/kernelconfig.html
>.
- Reboot your system.
Nous désactivons l'IPv6 en commentant la ligne suivante dans notre fichier de configuration du noyau freebsd521 :
#options INET6 #IPv6 communications protocols
Nous continuons donc notre travail, en recompilant et réinstallant le noyau comme nous l'avons déjà fait.
freebsd521:/usr/src# make buildkernel KERNCONF=freebsd521 ...edited... freebsd521:/usr/src# make installkernel KERNCONF=freebsd521 ...edited...
Ici, la documentation officielle de FreeBSD recommande de rebooter en mode "single user". Les lecteurs sont encouragés à faire de même s'ils ont un accès local au système en question. Je n'ai pas eu de problèmes en effectuant ces mises à jour via SSH. Pour des précisions sur la façon de répondre aux questions posées par mergemaster, reportez-vous au HandBook. Brièvement, les changements sont acceptés avec la commande 'i' et refusés grâce à 'd' et les fichiers sont mixés [NdT : "mergés"] avec 'm'. Par exemple, je refuse les fichiers proposant de remplacer mon fichier /etc/hosts mais j'accepte le nouveau fichier /etc/motd.
freebsd521:/usr/src# mergemaster -p ...edited... freebsd521:/usr/src# make installworld ...edited... ===> etc ===> etc/sendmail -------------------------------------------------------------- >>> Rebuilding man page indices -------------------------------------------------------------- cd /usr/src/share/man; make makedb makewhatis /usr/share/man makewhatis /usr/share/openssl/man rm -rf /tmp/install.byiy1xGn freebsd521:/usr/src# mergemaster ...edited... freebsd521:/usr/src# shutdown -r now
Lorsque le système a rebooté, la sortie de uname devient :
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #1: Sun Nov 28 14:46:01 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386
Avant, la sortie de uname précisait "FreeBSD 5.2.1-RELEASE #0" comme numéro de version. Maintenant, le "0" a été incrémenté à "1" pour montrer que le noyau a encore été recompilé.
Parfois, l'équipe sécurité de FreeBSD ne juge pas nécessaire de recompiler et réinstaller le monde entier (cependant, le procédé habituel décrit ci-dessus reste valide). C'était le cas pour l'avis de sécurité FreeBSD-SA-04:07.cvs, qui affectait le binaire CVS. Voici les détails pour la seule correction :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-04:07.cvs Security Advisory
The FreeBSD Project
...edited...
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.8,
4.9, 5.1, and 5.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/gnu/usr.bin/cvs
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
...edited...
RELENG_5_2
src/UPDATING 1.282.2.13
src/sys/conf/newvers.sh 1.56.2.12
src/contrib/cvs/src/client.c 1.10.4.1
src/contrib/cvs/src/modules.c 1.1.1.8.6.2
...edited...
- -------------------------------------------------------------------------
...truncated...
Nous téléchargeons puis appliquons le patch réglant le problème :
freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:07/cvs.patch Receiving cvs.patch (1913 bytes): 100% 1913 bytes transferred in 0.0 seconds (386.53 kBps) freebsd521:/root# cd /usr/src freebsd521:/usr/src# patch < /usr/src/root/cvs.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: contrib/cvs/src/client.c |=================================================================== |RCS file: /home/ncvs/src/contrib/cvs/src/client.c,v |retrieving revision 1.10 |diff -c -r1.10 client.c |*** contrib/cvs/src/client.c 21 Jan 2003 22:01:38 -0000 1.10 |--- contrib/cvs/src/client.c 14 Apr 2004 15:51:51 -0000 -------------------------- Patching file contrib/cvs/src/client.c using Plan A... Hunk #1 succeeded at 1054. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Index: contrib/cvs/src/modules.c |=================================================================== |RCS file: /home/ncvs/src/contrib/cvs/src/modules.c,v |retrieving revision 1.1.1.9 |diff -c -r1.1.1.9 modules.c |*** contrib/cvs/src/modules.c 21 Jan 2004 16:27:56 -0000 1.1.1.9 |--- contrib/cvs/src/modules.c 14 Apr 2004 15:54:51 -0000 -------------------------- Patching file contrib/cvs/src/modules.c using Plan A... Hunk #1 succeeded at 170. done
Maintenant, nous pouvons recompiler et réinstaller les composants affectés :
freebsd521:/usr/src# cd /usr/src/gnu/usr.bin/cvs freebsd521:/usr/src/gnu/usr.bin/cvs# make obj ===> lib ===> libdiff ===> cvs ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make depend ===> lib ===> libdiff ===> cvs rm -f .depend mkdep -f .depend -a -I/usr/src/gnu/usr.bin/cvs/cvs -I../lib -DHAVE_CONFIG_H ...edited... ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make ===> lib ===> libdiff ===> cvs cc -O -pipe -mcpu=pentiumpro -I/usr/src/gnu/usr.bin/cvs/cvs -I../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -I. -DHAVE_GSSAPI -DHAVE_GSSAPI_H -DENCRYPTION -c /usr/src/contrib/cvs/src/client.c ...edited... ===> contrib ===> cvsbug ===> doc freebsd521:/usr/src/gnu/usr.bin/cvs# make install ===> lib ===> libdiff ===> cvs install -s -o root -g wheel -m 555 cvs /usr/bin install -o root -g wheel -m 444 cvs.1.gz /usr/share/man/man1 ...edited... install-info --quiet --defsection="Programming & development tools." --defentry="* CVS-CLIENT: (cvsclient). CVS client/server Reference Manual." cvsclient.info /usr/share/info/dir install -o root -g wheel -m 444 cvs.info.gz cvsclient.info.gz /usr/share/info
Nous avons réussi à patcher l'outil CVS ; dans ce cas-là, il n'y a rien d'autre à faire.
Arrivés là, nous avons déjà patché, recompilé et réinstallé le noyau, le monde, ainsi qu'un certain ensemble d'outils faisant partie du monde sur FreeBSD 5.2.1. À partir d'ici, nous décidons que tous ces processus sont fastidieux et qu'il serait donc préférable de suivre la branche sécurité de FreeBSD 5.2.1.
Pour pouvoir suivre cette branche de sécurité, il nous faut installer CVSup. CVSup(1) nous permettra de rapatrier une version précise de FreeBSD depuis CVS, après quoi nous aurons à recompiler puis réinstaller le monde et le noyau. Commençons par installer la version précompilée du package "cvsup-without-gui" [NdT : CVSup sans interface graphique] :
freebsd521:/root# pkg_add -vr cvsup-without-gui
Il faut alors créer un fichier CVSup pour suivre les mises à jour de sécurité dans /usr/local/etc/ contenant les entrées suivantes. Ce fichier communique à CVSup les versions de fichiers à rapatrier. Nous choisissons comme serveur cvsup3.freebsd.org ; cependant, vous êtes encouragés à utiliser un serveur plus proche de chez vous. Remarquez que nous utilisons RELENG_5_2 comme étiquette CVS. Il s'agit de la branche sécurité pour FreeBSD 5.2.1.
*default host=cvsup3.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_2
*default delete use-rel-suffix
*default compress
src-all
Avec ce fichier de configuration, nous pouvons commencer CVSup. L'option -g désactive l'interface graphique et -L 2 rend CVSup plus verbeux.
freebsd521:/root# cvsup -g -L 2 /usr/local/etc/security-supfile Parsing supfile "/usr/local/etc/security-supfile" Connecting to cvsup3.FreeBSD.org Connected to cvsup3.FreeBSD.org Server software version: SNAP_16_1e Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Checkout src/UPDATING Checkout src/contrib/cvs/lib/xsize.h Checkout src/contrib/cvs/src/client.c Edit src/contrib/cvs/src/commit.c Add delta 1.13.4.1 2004.09.19.22.37.10 nectar Edit src/contrib/cvs/src/cvs.h Add delta 1.17.4.1 2004.09.19.22.37.10 nectar Edit src/contrib/cvs/src/filesubr.c Add delta 1.10.6.1 2004.09.19.22.37.10 nectar ...edited... Edit src/usr.bin/fetch/fetch.c Add delta 1.62.4.1 2004.11.18.12.04.29 cperciva SetAttrs src/usr.bin/lex/mkskel.sh,v SetAttrs src/usr.sbin/pkg_install/tkpkg,v Shutting down connection to server Finished successfully
Si vous êtes derrière un pare-feu qui interdit l'accès par le port 5999 sur le serveur CVSup, vous pouvez essayer de créer un tunnel SSH. Par exemple, si vous avez un accès SSH au serveur 'bouncehost', vous pouvez créer ce tunnel ainsi :
freebsd521:/root# ssh -v -L 5999:cvsup3.freebsd.org:5999 user@bouncehost
Puis utilisez CVSup ainsi :
freebsd521:/root# cvsup -g -L 2 -h localhost /usr/local/etc/security-supfile
Maintenant que CVSup a rapatrié tous les changements, nous procédons à la recompilation puis réinstallation du monde et du noyau. C'est exactement le même procédé que pour la vulnérabilité d'OpenSSL. Voici un récapitulatif des commandes :
cd /usr/src
make buildworld
make buildkernel KERNCONF=freebsd521
make installkernel KERNCONF=freebsd521
mergemaster -p
make installworld
mergemaster
shutdown -r now
Après le reboot, regardons le résultat de uname :
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE-p12 FreeBSD 5.2.1-RELEASE-p12 #2: Mon Nov 29 02:39:09 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386
La version de FreeBSD est maintenant "FreeBSD 5.2.1-RELEASE-p12" ; p12 indique le niveau de patch. Donc 11 avis de sécurité ont affecté FreeBSD 5.2.1 depuis sa sortie. Le premier (FreeBSD-SA-04:04.tcp) a été corrigé par 5.2.1-RELEASE-p2, le onzième (FreeBSD-SA-04:16.fetch) par 5.2.1-RELEASE-p12. C'est la version de la branche de sécurité que nous utilisons actuellement.
Le numéro "#2" indique que le noyau a encore été recompilé et réinstallé ; ce numéro était précédemment à "#1".
Supposons que vou souhaitez mettre à jour depuis la branche de sécurité de FreeBSD 5.2 vers FreeBSD 5.3 RELEASE. Créez un nouveau fichier "supfile" (appelons-le 5.3_REL-supfile) contenant ces lignes :
*default host=cvsup3.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_3_0_RELEASE
*default delete use-rel-suffix
*default compress
src-all
Remarquez que la seule différence entre ce fichier et le précédent est l'étiquette CVS. Suivez encore une fois les instructions de la section précédente, en commençant par rapatrier les sources de la nouvelle version via CVSup :
freebsd521:/root# cvsup -g -L 2 /usr/local/etc/5.3_REL-supfile
Continuez avec les commandes rappellées plus haut. Lorsque vous aurez fini, votre système sera FreeBSD 5.3 RELEASE.
Si vous désirez suivre la branche de sécurité de FreeBSD 5.3, changez l'étiquette CVS ("RELENG_5_3_0_RELEASE") en "RELENG_5_3". De n'importe quelle version de FreeBSD 5.2 que vous veniez, il vaut mieux utiliser la branche sécurité de FreeBSD 5.3. Pourquoi mettre à jour un système pour utiliser une version non sûre que vous pourriez trouver sur le CD FreeBSD 5.3 RELEASE ?
Dans l'arbre 5.x de FreeBSD, la version la plus aboutie est 5-STABLE. L'arbre STABLE incorpore non seulement des corrections de bugs et des patchs de sécurité, mais certaines améliorations sont importées de CURRENT. STABLE est constamment en mouvement, marquée seulement de la date et heure à laquelle un administrateur utilise CVSup pour resynchroniser ces sources avec l'arbre STABLE. Pour cette raison, les avis de sécurité vont incorporer la date et l'heure à laquelle la branche STABLE va intégrer les corrections, par exemple sur FreeBSD-SA-04:16.fetch :
Corrected: 2004-11-18 12:02:13 UTC (RELENG_5, 5.3-STABLE)
Votre système STABLE sera vulnérable si la mise à jour est plus vieille que la date indiquée. Comparez cette méthode de juger de la vulnérabilité d'un système avec celle des niveaux de patchs ; d'après le même avis de sécurité :
2004-11-18 12:03:05 UTC (RELENG_5_3, 5.3-RELEASE-p1)
2004-11-18 12:04:29 UTC (RELENG_5_2, 5.2.1-RELEASE-p12)
Ici, nous avons aussi la date, mais il est plus facile de constater que 5.3-RELEASE-p1 et 5.2.1-RELEASE-p12 sont patchées par rapport à la vulnérabilité de 'fetch'.
Pour les besoins de la démonstration, nous allons utiliser le "supfile" suivant pour passer de 5.2 à 5.3 :
*default host=cvsup3.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5
*default delete use-rel-suffix
*default compress
src-all
Nous rapatrions les sources via CVSup, puis recompilons et réinstallons le monde et le noyau (cf. plus haut). Enfin, notre système est devenu un FreeBSD 5-STABLE, comme nous le montre la commande uname :
freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.3-STABLE FreeBSD 5.3-STABLE #3: Tue Nov 30 20:16:13 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386
Notez bien que la version est maintenant "FreeBSD 5.3-STABLE", avec le "#3" pour indiquer que le noyau a été recompilé encore une fois. Pour les futurs avis de sécurité, nous devrons vérifier si la date de la ligne "Corrected:" est avant le "Tue Nov 30 20:16:13 EST 2004" de notre uname
Juste après avoir fini la mise à jour vers STABLE marquée du "Tue Nov 30 20:16:13 EST 2004", l'équipe sécurité de FreeBSD publiait un nouvel avis (FreeBSD-SA-04:17.procfs). Cet avis liste les versions concernées par ce problème :
Corrected: 2004-12-01 21:33:35 UTC (RELENG_5, 5.3-STABLE)
2004-12-01 21:34:23 UTC (RELENG_5_3, 5.3-RELEASE-p2)
2004-12-01 21:34:43 UTC (RELENG_5_2, 5.2.1-RELEASE-p13)
...truncated...
Étant donné que la date de ce correctif est "2004-12-01 21:33:35 UTC" (après ma mise à jour), je dois corriger ce problème, comme décrit dans l'avis.
Je peux aussi vérifier dans l'avis les fichiers qui doivent être modifiés. La liste apparaît comme suit pour la branche STABLE :
RELENG_5
src/sys/compat/linprocfs/linprocfs.c 1.84.2.1
src/sys/fs/procfs/procfs_status.c 1.52.2.1
En parcourant l'interface CVSWeb.freebsd.org du CVS, je peux trouver les changements apportés à chacun des fichiers :
La possibilité de regarder exactement ce qu'un patch corrige, en regardant le code source, est extrèmement formatrice. En relisant le code, vous pouvez précisément voir ce que les développeurs ont fait pour régler le problème et éventuellement juger si leur correctif est efficace.
J'espère que cet article vous a aidé à comprendre comment maintenir un système FreeBSD à jour vis-à-vis des avis de sécurité. Il peut ne pas être très clair, mais en le suivant, vous pourrez apprécier les différentes façons de garder votre système synchronisé avec les derniers correctifs pour FreeBSD.
Je voudrais remercier Michael Lucas, Colin Percival, Dru Lavigne, Maarten Midden, Terry Erickson, Marius Nunnerich, et Julien Gabel pour leurs retours sur cet article.
NdT : merci à Richard Bejtlich pour son autorisation pour traduire cet article et pour sa gentillesse.
Copyright © 2004-2005 Richard Bejtlich. Tous droits réservés.
Retour à l'accueil