Re: propositions pour l'agenda de l'AG
Erik Rossen wrote: [...] * Ne pourront être traitées, lors de l'Assemblée Générale, que les questions soumises à l'ordre du jour. DONC, si vous voulez quelque choses dans l'ordre du jour, il faut le transmettre AVANT qu'on publie la convocation, c'est à dire, AVANT 20 MARS Bonjour à tous, Pour respecter les statuts et le CO, il faudrait mettre à l'o.d.j. la question du nouveau nom du GULL, choisi lors de la précédente AG, pour entériner le changement de nom par l'assemblée. A bientôt. -- Mathias Schmocker SMAT Engineering LLC Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland
Re: propositions pour l'agenda de l'AG
Erik Rossen wrote: [...] DONC, si vous voulez quelque choses dans l'ordre du jour, il faut le transmettre AVANT qu'on publie la convocation, c'est à dire, AVANT 20 MARS Vous pouvez envoyer votre proposition dans la mailing-liste [EMAIL PROTECTED] Bonjour à tous, Je vous propose de mettre le point suivant à l'ordre du jour: Evoting à Genève: Etat du projet suite au test de janvier 2003 à Anières. Propositions d'actions avant le deuxième test prévu en novembre 2003, probablement lors d'une votation cantonale à Genève. Si possible pas dans les tréfonds de l'ordre du jour, pour avoir une discussion constructive et des propositions intéressantes de la part des personnes présentes. Merci et à bientôt. -- Mathias Schmocker SMAT Engineering LLC Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland
[Fwd: Revised OpenSSH Security Advisory (adv.iss)]
Pour votre information:
Original Message
From: Markus Friedl [EMAIL PROTECTED]
Subject: Revised OpenSSH Security Advisory (adv.iss)
To: [EMAIL PROTECTED]
Newsgroups: fa.openbsd.announce
This is the 2nd revision of the Advisory.
1. Versions affected:
Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
contain an input validation error that can result in an
integer overflow and privilege escalation.
All versions between 2.3.1 and 3.3 contain a bug in the
PAMAuthenticationViaKbdInt code.
All versions between 2.9.9 and 3.3 contain a bug in the
ChallengeResponseAuthentication code.
OpenSSH 3.4 and later are not affected.
OpenSSH 3.2 and later prevent privilege escalation if
UsePrivilegeSeparation is enabled in sshd_config. OpenSSH
3.3 enables UsePrivilegeSeparation by default.
Although some earlier versions are not affected upgrading
to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
checks for a class of potential bugs.
2. Impact:
This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config.
Affected are at least systems supporting s/key over
SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
as well as other systems supporting s/key with SSH).
Exploitablitly of systems using
PAMAuthenticationViaKbdInt
has not been verified.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
and
Disable PAMAuthenticationViaKbdInt in sshd_config.
Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.
4. Solution:
Upgrade to OpenSSH 3.4 or apply the following patches.
5. Credits:
ISS.
Appendix:
A:
Index: auth2-chall.c
===
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c 19 Jun 2002 00:27:55 - 1.18
+++ auth2-chall.c 26 Jun 2002 09:37:03 -
@@ -256,6 +256,8 @@
authctxt-postponed = 0;/* reset */
nresp = packet_get_int();
+ if (nresp 100)
+ fatal(input_userauth_info_response: nresp too big %u, nresp);
if (nresp 0) {
response = xmalloc(nresp * sizeof(char*));
for (i = 0; i nresp; i++)
B:
Index: auth2-pam.c
===
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c 22 Jan 2002 12:43:13 - 1.12
+++ auth2-pam.c 26 Jun 2002 10:12:31 -
@@ -140,6 +140,15 @@
nresp = packet_get_int(); /* Number of responses. */
debug(got %d responses, nresp);
+
+ if (nresp != context_pam2.num_expected)
+ fatal(%s: Received incorrect number of responses
+ (expected %u, received %u), __func__, nresp,
+ context_pam2.num_expected);
+
+ if (nresp 100)
+ fatal(%s: too many replies, __func__);
+
for (i = 0; i nresp; i++) {
int j = context_pam2.prompts[i];
[Fwd: OpenSSH 3.4 released]
Une autre info: Original Message From: Markus Friedl [EMAIL PROTECTED] Subject: OpenSSH 3.4 released To: [EMAIL PROTECTED] Newsgroups: fa.openbsd.announce OpenSSH 3.4 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Changes since OpenSSH 3.3: Security Changes: = All versions of OpenSSH's sshd between 2.9.9 and 3.3 contain an input validation error that can result in an integer overflow and privilege escalation. OpenSSH 3.4 fixes this bug. In addition, OpenSSH 3.4 adds many checks to detect invalid input and mitigate resource exhaustion attacks. OpenSSH 3.2 and later prevent privilege escalation if UsePrivilegeSeparation is enabled in sshd_config. OpenSSH 3.3 enables UsePrivilegeSeparation by default. Reporting Bugs: === - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom.
[Fwd: CVS: cvs.openbsd.org: www]
Qui dit mieux ? Original Message From: Jan-Uwe Finck [EMAIL PROTECTED] Subject: CVS: cvs.openbsd.org: www To: [EMAIL PROTECTED] Newsgroups: fa.openbsd.source-changes CVSROOT:/cvs Module name:www Changes by: [EMAIL PROTECTED]2002/06/26 10:43:45 Modified files: de : index.html Log message: one remote hole in six years
[Re: Upcoming SSH vulnerability
Marc SCHAEFER wrote: ``Eclaircissement'' de Theo de Raadt (co-auteur de OpenSSH). Résumé: - il ne veut toujours pas nous décrire le problème. - il critique ceux qui veulent connaître les détails. - il force tout le monde à mettre à jour à une nouvelle version pas terminée, peu testée, et contenant au moins deux bugs. - une nouvelle version qui ne corrige pas la vulnérabilité, mais l'atténue (comment? dans quelle mesure? pourquoi?), ou du moins on doit lui faire confiance pour ça. - il ne donne même pas des informations plus complètes aux distributions. en bref, il applique la maxime `security through obscurity'. Donc ma recommandation reste: - arrêtez SSH sur vos serveurs (et clients): /etc/init.d/ssh stop - sur les serveurs sur lesquels vous devez pouvoir faire de la maintenance à distance, utilisez les règles de firewalling pour n'autoriser qu'une machine à adresse fixe à y accéder - si vous avez du temps à perdre, installez la version corrigée-mais-pas-complètement-et-qui-casse-des-trucs sur une machine de test et testez-la complètement avant de la mettre en oeuvre et de casser votre seule méthode d'accès à votre serveur distant. Une alternative est de firewaller à l'entrée de votre réseau le port 22, en attendant mieux. Mes 2 centimes additionnels... Je lis les listes openbsd, etc. Vendredi: apache httpd vulnerability (64 bits only ?) Lundi: apache httpd vulnerability avec cracker program, concerne aussi les 32 bits et Openbsd. Test, pas de trou, le child httpd segfaulte, pas trop grave. en 2 H, avant de filer à un rdv à Berne, update de TOUS les serveurs apache sous mon contrôle, et retest, OK. Mardi: de diverses sources, (et merci Marc pour ton résumé security) problème sshd. Update selon les erratas openbsd, privilege separation de TOUS les serveurs en production, chez moi et mes clients. Contrôle, etc... Je préfère ma méthode, j'ai vu des sysadmins se tirer dans le pied en modifiant les règles de firewall à distance :) Je fais tjrs confiance au team OpenBSD, avez-vous vu une liste détaillée à la CVS des changements journaliers du code kernel, etc. dans des systèmes autres que *BSD (comme Linux p.ex. ...). Un remote root exploit chaque 5 ans c'est un peu mieux que Linux je crois, et en plus on est averti à l'avance. Je me rappelle qu'il n'y a pas si longtemps, un = au lieu de donnait un local root exploit, alors un patch de 5 lignes... (le récent de apache fait ~10 lignes je crois) Bonne journée à tous, patchez et laissez le FUD retomber un peu. -- Mathias Schmocker SMAT Engineering Sarl Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland Please visit http://www.OpenBSD.org/ the FREE Multiplatform Ultra-Secure Operating System P.S. envoyé a linux-leman-admin, linux-leman m'a bouncé
Au sujet du e-voting genevois
Bonjour, Voici un lien sur un papier ayant pour titre: e-voting: cyberattaque sur la e-democratie ? URL: http://www.smat.ch/evoting/evote2_fr.html Vos commentaires sont les bienvenus. -- Mathias Schmocker SMAT Engineering Sàrl Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland Please visit http://www.OpenBSD.org/ the FREE Multiplatform Ultra-Secure Operating System
Re: changement de nom du GULL
Pierre TESTORI wrote: Bonjour, Un changement de nom implique un changement d'image, avec des conséquences assez aléatoires (à la New Coke p.ex.) et notamment une dilution du focus. On ne manque pas d'orgueil là-haut. Rappel de quelques ordres de grandeurs : COCA-COLA est une multinationale multimilliardaire en dollar$$$ gull, même à Lausanne sur SainF, personne connaît. Minuscule question : Comment détruit-on une Tour ( d'ivoire ) ? Cordiales salutations, Pierre TESTORI [EMAIL PROTECTED] Je ne comprends pas votre question. Le contexte m'échappe. -- Mathias Schmocker SMAT Engineering Sarl Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland Please visit http://www.OpenBSD.org/ the FREE Multiplatform Ultra-Secure Operating System
Re: Table ronde E-Voting
informations par des organismes privés, en opposition à la Poste (ISP, et si on était en Italie ou le contrôle de l'information et de sa transmission sont étroitement liés au pouvoir); Qui vérifie les certificats du serveur atteint? ( je rajoute maintenant, j'ai pas eu le temps de l'exposer). En matière d'Internet on change simplement l'échelle des fraudes possibles (cela ils n'ont pas l'air de s'en rendre compte!). Le rapport sécurité sera-t-il public? Réponse de M. Ascheri: Je ne suis pas des Informaticiens et donc il faut attendre le rapport de la commission de sécurité et le rapport sera public mais j'ai signé un NDA (Non Disclosure Agreement) alors je ne peux pas en parler! - Sur ceux, José a bondi et mentionné que cela était un vrai problème ce d'ouverture: comment discuter de sécurité et de processus démocratique avec des personnes qui signent un NDA? Il a aussi fait remarquer que le e-voting n'est pas une simple et nouvelle façon de voter mais que cela était un changement Majeur et qu'il fallait du temps pour l'introduire dans notresociété. (Ce avec lequel je suis entièrement d'accord quand on voit le peu d'éducation Internet que les gens possédent - Qui connait les certificats? Qui fait attention régulièrement à la maison - une fois par semaine - aux nouveaux virus? Qui sait ce qu'est un protocole, la cryptographie (la Chancelerie mentionne partout 128bits!)? etc... Appréciation Générale = Dans l'ensemble c'était un bon débat et les acteurs semblent avoir dilué leur vin avec beaucoup d'eau. L'optimisme du début du projet est un peu tombé. M. Auer et M. Ascheri ont mentionné que cela ne serait pas accepté par la Confédération et le Grand Conseil si les rapports n'étaient pas positifs. Que ce n'était qu'une phase de test et qu'il faut essayer de déceler, corriger les problèmes et quand le débat sera ouvert, il est possible donc que cela ne soit pas accepté dans un proche avenir. A-propos, avez vous testé le vote par Internet au service des passeports. C'est très intéressant et avec Arnaud Bresson, on a quelques conclusions surprenantes à divulguer, bientôt. -- Mathias Schmocker SMAT Engineering Sarl Tel. +41 22 800 3400 Bvd Georges-Favon 20 Fax. +41 22 800 3401 P.O. Box mailto:[EMAIL PROTECTED]CH-1211 Geneva 11 http://www.smat.ch/Switzerland Please visit http://www.OpenBSD.org/ the FREE Multiplatform Ultra-Secure Operating System
