La recommandation publiée, qui a motivé beaucoup d'échanges sur ce forum, consistait à éviter les mises à jour. Paul W. Frields vient de poster un message sur la liste de diffusion des annonces Fedora dont le contenu suit (traduction libre Herrib; l'original est joint).
On retiendra les points suivants:
i- les serveurs Fedora ont été victimes d'un intrusion [on remerciera la transparence de Fedora et de Red Hat, les deux cas étant disjoints comme indiqué dans le communiqué];
ii- les paquetages proposés par les serveurs ne sont très vrais vraisemblablement pas touchés car la phrase appuyant la signature n'a pas été utilisée;
iii- des dispositions sont cependant prises pour assurer que les paquetages ne seront pas altérés à l'avenir, par des changements de clés qui pourront avoir des impact sur les utilisateur;
iv- les cas Fedora et Red Hat sont disjoints; Red Hat a par ailleurs communiqué vers ses clients, certains de ses ordinateurs ayant été aussi touchés;
v- pour Red Hat (et non Fedora, on le répétera), des paquetages ont été touchés (OpenSSH); ce point est décrit à la fin de ce message.
Les serveurs Fedora sont à nouveau connectés et les mises à jour peuvent reprendre. Le cas OpenSSH Red Hat est traité à la fin.
Sans céder à la paranoïa, on ne que trop renouveler les consignes élémentaires de sécurité dont ce fil saura certainement se faire l'écho (voir notamment ce post). Remercions en tout cas toute l'équipe Fedora pour sa transparence et sa réactivité.
La traduction du post:
"La semaine dernière, nous avons découvert des accès illégaux à quelques serveurs Fedora. L'intrusion a été rapidement découverte et les serveurs ont été déconnectés.
Les spécialistes sécurité et administrateurs ont travaillé depuis à l'analyse de l'intrusion et l'étendue de ses effets de même qu'ils ont réinstallé les systèmes Fedora. Nous profitons des arrêts de fonctionnement rendus nécessaires comme une opportunité de faire d'autres mises à niveau des fonctionnalités et de la sécurité. Le travail est en cours, soyez patient. Quiconque dispose d'informations pertinentes en rapport à cet événement voudra bien contacter fedora-legal@redhat.com.
L'un des serveurs compris état le système utilisé pour signer les paquetages Fedora. Quoi qu'il en soit, eu égard à nos efforts, nous sommes très confiants, l'intrus n'a pas été capable d'acquérir la phrase utilisée pour sécuriser la clé de signature des paquetages. Notre revue, à ce jour, a indiqué que la phraese n'a pas été utilisée durant l'intrusion et cette phrase n'est pas enregistrée sur aucun des serveurs Fedora.
Il n'y a aucune preuve définitive/certaine que la clé Fedora a été compromise, cependant, parce que les paquetages Fedora sont distribués par de nombreux mirroirs tiers et dépôts, nous avons décidé de passer à de nouvelles clés de signature. Cela pourra requérir quelques démarches volontaires de tous les administrateurs système. Nous ferons largement et clairement les étapes à parcourir et apporterons l'aide utile aux utilisateurs quand le tout sera disponible.
Dans le cadre de nos autres analyses, nous avons réalisé de nombreux contrôles des paquetages Fedora et un ensemble significatif de contrôles à la source; nous n'avons découvert aucune anomalie/défaut qui indiquerait des pertes d'intégrité de paquetages. Ces efforts n'ont pas débouché sur la découverte d'autres vulnérabilités au sein des paquetages fournis par Fedora.
Nos avertissements précédents concernant la mise à jour des paquetages reposaient sur excès de précautions par respect pour nos utilisateurs. C'est aussi pourquoi nous procédons à la modification des modalités de signature des paquetages Fedora. Nous avons déjà commencé à planifié et réaliser d'autres garanties pour l'avenir. A cet instant, nous sommes confiants et il y a peu de risques pour les utilisateurs Fedora qui souhaitent installer ou mettre à jour des paquetages Fedora.
En lien avec ces événements , Red Hat, Inc. a détecté une intrusion dans quelques uns de ses systèmes et a engagé une communication vers les utilisateurs Red Hat Enterprise Linux qui être consultée à l'adresse suivante: http://rhn.redhat.com/errata/RHSA-2008-0855.html.
Cette communication indique en particulier "La semaine passée, Red Hat a détecté une intrusion dans certains des systèmes de ses ordinateurs et a réagi immédiatemetn. Alors que l'analyse de l'intrusion est en cours, notre préoccupation principale a consisté à évaluer et tester notre canal de distribution vers les clients, Red Hat Network (RHN) et ses dispositifs de sécurité associés. Les résultats de cette approche nous rendent très confiants, nos systèmes et processus ont évité que l'intrusion ne compromette le réseau RHN ou le contenu distribué depuis RHN; de même, nous pensons que les utilisateurs qui maintiennent leurs systèmes à jour en utilisant Red Hat Network, n'encourent aucun risque. Nous publions cette alerte au point de départ pour ceux qui pourraient acquérir les paquetages binaires Red Hat binary depuis des canaux autres que ceux destinés aux clients de Red Hat".
Il est important de noter que les effets de l'intrusion sur Fedora et Red Hat ne sont pas identiques. La clé de signature des paquetages Fedora n'est pas connectée / est différente de la clé utilisée pour signer les paquetages Red Hat Enterprise Linux. De plus, la clé de signature des paquetages Fedora n'est pas liée / est différentes de celle qui est utilisée pour signer les paquetages Extra Enterprise Linux (EPEL) .
Nous continuerons à informer la communauté Fedora community de tout développement. Merci pour votre patience.
Le texte original (la traduction n'est pas littérale!)
"Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the
servers were taken offline.
Security specialists and administrators have been working since then to analyze the intrusion and the extent of the compromise as well as reinstall Fedora systems. We are using the requisite outages as an opportunity to do other upgrades for the sake of functionality as well as security. Work is ongoing, so please be patient. Anyone with pertinent information relating to this event is asked to contact fedora-legal@redhat.com.
One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key. Based on our review to date, the passphrase was not used during the time of the intrusion on the system and the passphrase is not stored on any of the Fedora servers.
While there is no definitive evidence that the Fedora key has been compromised, because Fedora packages are distributed via multiple third-party mirrors and repositories, we have decided to convert to new Fedora signing keys. This may require affirmative steps from every Fedora system owner or administrator. We will widely and clearly communicate any such steps to help users when available.
Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity. These efforts have also not resulted in the discovery of additional security vulnerabilities in packages provided by Fedora.
Our previous warnings against further package updates were based on an abundance of caution, out of respect for our users. This is also why we are proceeding with plans to change the Fedora package signing key. We have already started planning and implementing other additional safeguards for the future. At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages.
In connection with these events, Red Hat, Inc. detected an intrusion of certain of its computer systems and has issued a communication to Red Hat Enterprise Linux users which can be found at http://rhn.redhat.com/errata/RHSA-2008-0855.html. This communication states in part, "Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we
remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and
accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for
those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers."
It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key
is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key
is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages.
We will continue to keep the Fedora community notified of any updates. Thank you again for your patience.
=================================
Point particulier pour les administrateurs Red Hat
===================================
Le post mentionne un communiqué de Red Hat (la référence complète est donnée). Une partie seulement est citée dans le texte-même. La suite signale un problème avec les paquetages OpenSSH (voir: http://www.redhat.com/security/data/openssh-blacklist.html)
Les éléments ne concernent pas Fedora (les cas sont disjoints), comme indiqué dans le post de Paul W. Frields. Des paquetages, dans le cas Red Hat, ont été altérés. La traduction suit:
En lien à cet incident, l'intrus a été capable de signer un petit nombre de paquetages OpenSSH concernant uniquement Red Hat Enterprise Linux 4 (architectures i386 et x86_64 suelement) et Red Hat Enterprise Linux 5 (architecture x86_64 seulement). Par mesure de précaution, nous diffusons une version mise à jour de ces paquetages et nous avons publié une liste des paquetages altérés et les moyens de les détecter. Une nouvelle fois, nos processus et efforts à ce jour indiquent que les paquetages obtenus par les clients Red Hat Enterprise Linuxvia Red Hat Network ne présentent pas de risque.
Nous avons fourni un shell script qui liste les paquetages affectés et peut vérifier qu'aucun d'entre eux sont installés sur un système:
* openssh-blacklist-1.0.sh
Le script possède une signature GPG signature distincte, de Red Hat Security Response Team (clé) , et vous pouvez ainsi en vérifier l'intégrité:
* openssh-blacklist-1.0.sh.asc
Le script peut être exécuté comme non-root user ou comme root. Pour l'executer après téléchargement et suavegarde sur votre système, lancez la commande:
bash ./openssh-blacklist-1.0.sh
Si le résultat du script comprend des lignes acommençant par "ALERT" alors un paquetage altéré a été installé sur le système.Sinon, si aucun paquetage altéré a été trouvé sur le système, le script devrait éditer une seule ligne commençant par le mot "PASS", comme indiqué ci-dessous:
bash ./openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system
Le script peut aussi vérifier un ensemble de paquetages en lui transmettant une liste de noms de RPM binaires. Dans ce mode, une ligne "PASS" ou "ALERT" sera éditée pour chaque nom de RPM traité; par exemple:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm
PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklist
Les clients Red Hat qui découvre un paquetage altéré, qui ontbesoin d'aide pour exécuter ce script, ou qui ont des questions, devront se connecter au support Red Hat et enregistrer un ticket, appeler leur support local ou contacter leur gestionnaire technique de compte.
texte original:
OpenSSH blacklist script
22nd August 2008
Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.
In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only). As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.
To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.
We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:
* openssh-blacklist-1.0.sh
The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:
* openssh-blacklist-1.0.sh.asc
This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:
bash ./openssh-blacklist-1.0.sh
If the script output includes any lines beginning with "ALERT" then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word "PASS", as shown below:
bash ./openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system
The script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a "PASS" or "ALERT" line will be printed for each filename passed; for example:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm
PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklist
Red Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.
On retiendra les points suivants:
i- les serveurs Fedora ont été victimes d'un intrusion [on remerciera la transparence de Fedora et de Red Hat, les deux cas étant disjoints comme indiqué dans le communiqué];
ii- les paquetages proposés par les serveurs ne sont très vrais vraisemblablement pas touchés car la phrase appuyant la signature n'a pas été utilisée;
iii- des dispositions sont cependant prises pour assurer que les paquetages ne seront pas altérés à l'avenir, par des changements de clés qui pourront avoir des impact sur les utilisateur;
iv- les cas Fedora et Red Hat sont disjoints; Red Hat a par ailleurs communiqué vers ses clients, certains de ses ordinateurs ayant été aussi touchés;
v- pour Red Hat (et non Fedora, on le répétera), des paquetages ont été touchés (OpenSSH); ce point est décrit à la fin de ce message.
Les serveurs Fedora sont à nouveau connectés et les mises à jour peuvent reprendre. Le cas OpenSSH Red Hat est traité à la fin.
Sans céder à la paranoïa, on ne que trop renouveler les consignes élémentaires de sécurité dont ce fil saura certainement se faire l'écho (voir notamment ce post). Remercions en tout cas toute l'équipe Fedora pour sa transparence et sa réactivité.
La traduction du post:
"La semaine dernière, nous avons découvert des accès illégaux à quelques serveurs Fedora. L'intrusion a été rapidement découverte et les serveurs ont été déconnectés.
Les spécialistes sécurité et administrateurs ont travaillé depuis à l'analyse de l'intrusion et l'étendue de ses effets de même qu'ils ont réinstallé les systèmes Fedora. Nous profitons des arrêts de fonctionnement rendus nécessaires comme une opportunité de faire d'autres mises à niveau des fonctionnalités et de la sécurité. Le travail est en cours, soyez patient. Quiconque dispose d'informations pertinentes en rapport à cet événement voudra bien contacter fedora-legal@redhat.com.
L'un des serveurs compris état le système utilisé pour signer les paquetages Fedora. Quoi qu'il en soit, eu égard à nos efforts, nous sommes très confiants, l'intrus n'a pas été capable d'acquérir la phrase utilisée pour sécuriser la clé de signature des paquetages. Notre revue, à ce jour, a indiqué que la phraese n'a pas été utilisée durant l'intrusion et cette phrase n'est pas enregistrée sur aucun des serveurs Fedora.
Il n'y a aucune preuve définitive/certaine que la clé Fedora a été compromise, cependant, parce que les paquetages Fedora sont distribués par de nombreux mirroirs tiers et dépôts, nous avons décidé de passer à de nouvelles clés de signature. Cela pourra requérir quelques démarches volontaires de tous les administrateurs système. Nous ferons largement et clairement les étapes à parcourir et apporterons l'aide utile aux utilisateurs quand le tout sera disponible.
Dans le cadre de nos autres analyses, nous avons réalisé de nombreux contrôles des paquetages Fedora et un ensemble significatif de contrôles à la source; nous n'avons découvert aucune anomalie/défaut qui indiquerait des pertes d'intégrité de paquetages. Ces efforts n'ont pas débouché sur la découverte d'autres vulnérabilités au sein des paquetages fournis par Fedora.
Nos avertissements précédents concernant la mise à jour des paquetages reposaient sur excès de précautions par respect pour nos utilisateurs. C'est aussi pourquoi nous procédons à la modification des modalités de signature des paquetages Fedora. Nous avons déjà commencé à planifié et réaliser d'autres garanties pour l'avenir. A cet instant, nous sommes confiants et il y a peu de risques pour les utilisateurs Fedora qui souhaitent installer ou mettre à jour des paquetages Fedora.
En lien avec ces événements , Red Hat, Inc. a détecté une intrusion dans quelques uns de ses systèmes et a engagé une communication vers les utilisateurs Red Hat Enterprise Linux qui être consultée à l'adresse suivante: http://rhn.redhat.com/errata/RHSA-2008-0855.html.
Cette communication indique en particulier "La semaine passée, Red Hat a détecté une intrusion dans certains des systèmes de ses ordinateurs et a réagi immédiatemetn. Alors que l'analyse de l'intrusion est en cours, notre préoccupation principale a consisté à évaluer et tester notre canal de distribution vers les clients, Red Hat Network (RHN) et ses dispositifs de sécurité associés. Les résultats de cette approche nous rendent très confiants, nos systèmes et processus ont évité que l'intrusion ne compromette le réseau RHN ou le contenu distribué depuis RHN; de même, nous pensons que les utilisateurs qui maintiennent leurs systèmes à jour en utilisant Red Hat Network, n'encourent aucun risque. Nous publions cette alerte au point de départ pour ceux qui pourraient acquérir les paquetages binaires Red Hat binary depuis des canaux autres que ceux destinés aux clients de Red Hat".
Il est important de noter que les effets de l'intrusion sur Fedora et Red Hat ne sont pas identiques. La clé de signature des paquetages Fedora n'est pas connectée / est différente de la clé utilisée pour signer les paquetages Red Hat Enterprise Linux. De plus, la clé de signature des paquetages Fedora n'est pas liée / est différentes de celle qui est utilisée pour signer les paquetages Extra Enterprise Linux (EPEL) .
Nous continuerons à informer la communauté Fedora community de tout développement. Merci pour votre patience.
Le texte original (la traduction n'est pas littérale!)
"Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the
servers were taken offline.
Security specialists and administrators have been working since then to analyze the intrusion and the extent of the compromise as well as reinstall Fedora systems. We are using the requisite outages as an opportunity to do other upgrades for the sake of functionality as well as security. Work is ongoing, so please be patient. Anyone with pertinent information relating to this event is asked to contact fedora-legal@redhat.com.
One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key. Based on our review to date, the passphrase was not used during the time of the intrusion on the system and the passphrase is not stored on any of the Fedora servers.
While there is no definitive evidence that the Fedora key has been compromised, because Fedora packages are distributed via multiple third-party mirrors and repositories, we have decided to convert to new Fedora signing keys. This may require affirmative steps from every Fedora system owner or administrator. We will widely and clearly communicate any such steps to help users when available.
Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity. These efforts have also not resulted in the discovery of additional security vulnerabilities in packages provided by Fedora.
Our previous warnings against further package updates were based on an abundance of caution, out of respect for our users. This is also why we are proceeding with plans to change the Fedora package signing key. We have already started planning and implementing other additional safeguards for the future. At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages.
In connection with these events, Red Hat, Inc. detected an intrusion of certain of its computer systems and has issued a communication to Red Hat Enterprise Linux users which can be found at http://rhn.redhat.com/errata/RHSA-2008-0855.html. This communication states in part, "Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we
remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and
accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for
those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers."
It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key
is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key
is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages.
We will continue to keep the Fedora community notified of any updates. Thank you again for your patience.
=================================
Point particulier pour les administrateurs Red Hat
===================================
Le post mentionne un communiqué de Red Hat (la référence complète est donnée). Une partie seulement est citée dans le texte-même. La suite signale un problème avec les paquetages OpenSSH (voir: http://www.redhat.com/security/data/openssh-blacklist.html)
Les éléments ne concernent pas Fedora (les cas sont disjoints), comme indiqué dans le post de Paul W. Frields. Des paquetages, dans le cas Red Hat, ont été altérés. La traduction suit:
En lien à cet incident, l'intrus a été capable de signer un petit nombre de paquetages OpenSSH concernant uniquement Red Hat Enterprise Linux 4 (architectures i386 et x86_64 suelement) et Red Hat Enterprise Linux 5 (architecture x86_64 seulement). Par mesure de précaution, nous diffusons une version mise à jour de ces paquetages et nous avons publié une liste des paquetages altérés et les moyens de les détecter. Une nouvelle fois, nos processus et efforts à ce jour indiquent que les paquetages obtenus par les clients Red Hat Enterprise Linuxvia Red Hat Network ne présentent pas de risque.
Nous avons fourni un shell script qui liste les paquetages affectés et peut vérifier qu'aucun d'entre eux sont installés sur un système:
* openssh-blacklist-1.0.sh
Le script possède une signature GPG signature distincte, de Red Hat Security Response Team (clé) , et vous pouvez ainsi en vérifier l'intégrité:
* openssh-blacklist-1.0.sh.asc
Le script peut être exécuté comme non-root user ou comme root. Pour l'executer après téléchargement et suavegarde sur votre système, lancez la commande:
bash ./openssh-blacklist-1.0.sh
Si le résultat du script comprend des lignes acommençant par "ALERT" alors un paquetage altéré a été installé sur le système.Sinon, si aucun paquetage altéré a été trouvé sur le système, le script devrait éditer une seule ligne commençant par le mot "PASS", comme indiqué ci-dessous:
bash ./openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system
Le script peut aussi vérifier un ensemble de paquetages en lui transmettant une liste de noms de RPM binaires. Dans ce mode, une ligne "PASS" ou "ALERT" sera éditée pour chaque nom de RPM traité; par exemple:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm
PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklist
Les clients Red Hat qui découvre un paquetage altéré, qui ontbesoin d'aide pour exécuter ce script, ou qui ont des questions, devront se connecter au support Red Hat et enregistrer un ticket, appeler leur support local ou contacter leur gestionnaire technique de compte.
texte original:
OpenSSH blacklist script
22nd August 2008
Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.
In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only). As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.
To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.
We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:
* openssh-blacklist-1.0.sh
The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:
* openssh-blacklist-1.0.sh.asc
This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:
bash ./openssh-blacklist-1.0.sh
If the script output includes any lines beginning with "ALERT" then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word "PASS", as shown below:
bash ./openssh-blacklist-1.0.sh
PASS: no suspect packages were found on this system
The script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a "PASS" or "ALERT" line will be printed for each filename passed; for example:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm
PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklist
Red Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.
