Esta semana se conoció que los diferentes desarrolladores de sistemas operativos publicaron un parche para KRACK, un exploit creado por investigadores de seguridad que permite vulnerar el protocolo de seguridad inalámbrica WPA2, y también que los desarrolladores de OpenBSD, habían publicado el parche antes de la fecha prevista para el anuncio público de la vulnerabilidad, lo que motivó que algunos los acusaran de poner en peligro a los sistemas operativos que aún no habían creado el parche. Un desarrollador de OpenBSD explicó los motivos.




Aunque desde el proyecto no se respondió oficialmente a las críticas, un desarrollador dio una explicación que parece perfectamente válida sobre lo que sucedió con los descubridores del problema. Ante la pregunta del sitio web PlanetaDiego, otros desarrolladores la confirmaron.

Lo que pasó es que me lo dijeron ( el 15 de julio, y me impusieron un embargo de 6 semanas hasta finales de agosto. Ya nos quejábamos entonces de que esto era demasiado largo y dejábamos a la gente expuesta.

Luego consiguieron la participación del CERT(*) (y, por lo tanto, de las agencias gubernamentales estadounidenses) y tuvieron que extender aún más el embargo hasta el día de hoy. En ese momento ya teníamos el balón en marcha y decidimos atenernos al acuerdo original con él.

En esta situación, una petición para mantener el problema y arreglar el secreto es una petición para dejar a nuestros usuarios en riesgo y expuestos a los iniciados que potencialmente usarán el fallo para explotar a nuestros usuarios. Y no tenemos ni idea de quiénes son los otros iniciados. Tenemos que asumir que este tipo de información se filtrará y se disipa rápidamente en la “comunidad” de seguridad.”

Elegimos servir las necesidades de nuestros usuarios que son las personas vulnerables en este drama. Estoy de acuerdo con esa elección.

 Parche:

• http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_pae_input.c.diff?r1=1.30&r2=1.31

===================================================================
RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- src/sys/net80211/ieee80211_pae_input.c 2017/08/17 06:01:05 1.30
+++ src/sys/net80211/ieee80211_pae_input.c 2017/10/16 10:39:41 1.31
@@ -1,4 +1,4 @@
-/* $OpenBSD: ieee80211_pae_input.c,v 1.30 2017/08/17 06:01:05 stsp Exp $ */
+/* $OpenBSD: ieee80211_pae_input.c,v 1.31 2017/10/16 10:39:41 stsp Exp $ */
 
 /*-
  * Copyright (c) 2007,2008 Damien Bergamini 
@@ -340,6 +340,12 @@
 }
 #endif /* IEEE80211_STA_ONLY */
 
+/* 
+ * Check if a group key must be updated with a new GTK from an EAPOL frame.
+ * Manipulated group key handshake messages could trick clients into
+ * reinstalling an already used group key and hence lower or reset the
+ * associated replay counter. This check prevents such attacks.
+ */
 int
 ieee80211_must_update_group_key(struct ieee80211_key *k, const uint8_t *gtk,
     int len)
@@ -528,6 +534,17 @@
  if (ieee80211_send_4way_msg4(ic, ni) != 0)
   return; /* ..authenticator will retry */
 
+ /* 
+  * Only install a new pairwise key if we are still expecting a new key,
+  * as indicated by the NODE_RSN_NEW_PTK flag. An adversary could be
+  * sending manipulated retransmissions of message 3 of the 4-way
+  * handshake in an attempt to trick us into reinstalling an already
+  * used pairwise key. If this attack succeeded, the incremental nonce
+  * and replay counter associated with the key would be reset.
+  * Against CCMP, the adversary could abuse this to replay and decrypt
+  * packets. Against TKIP, it would become possible to replay, decrypt,
+  * and forge packets.
+  */
  if (ni->ni_rsncipher != IEEE80211_CIPHER_USEGROUP &&
      (ni->ni_flags & IEEE80211_NODE_RSN_NEW_PTK)) {
   u_int64_t prsc;

Fuente:
https://planetadiego.com/2017/10/18/explicacion-de-la-decision-de-openbsd-de-liberar-el-parche-para-krack-antes-que-se-hiciera-publica-la-vulnerabilidad/