Noticias sobre Heartbleed, un agujero de seguridad
Por (reenvio) Colectivo Riseup - Saturday, Apr. 26, 2014 at 4:16 PM

Abril de 2014 / Usuarios de Riseup, en este momento ustedes han escuchado sobre la gran falla de seguridad hecha publica la semana pasada, denominada Heartbleed.

Aquí, Nosotros hicimos las arreglos necesarios el mismo día en que la falla se hizo publica. Existe el riesgo de que tu clave haya sido extraída, y de que tu comunicación por medio de Riseup haya sido monitoreada o interferida. Es necesario que cambies tu clave. Si quieres saber más al respecto, hay un resumen muy bueno en https://mayfirst.org/heartbleed

Hay quien afirma (y quien lo niega) que la NSA estuvo al tanto de este problema desde hace dos años. De ser así, calculamos que, en el peor de los escenarios, ellos pudieron intervenir nuestra comunicación durante 11 meses, aproximadamente. Aja, Uff ☹

Puedes encontrar detalles sobre el nuevo certificado de seguridad (y los nombres de los servicios ocultos de Tor) enlistados en la pagina web principal de riseup, dentro de la sección de “actualizaciones del sistema”

Debes entrar a user.riseup.net y cambiar tu clave. Hazlo inmediatamente.

En solidaridad, Riseup https://riseup.net

Nota: Recuerda que Riseup nunca, pero nunca, va a pedirte que nos envíes tu clave, o que des clic en un enlace para que nos proporciones tu clave.

¿Qué es Heartbleed?

Heartbleed es un agujero de seguridad (bug) de software en la biblioteca de código abierto OpenSSL, que permite a un atacante leer la memoria de un servidor o un cliente, permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor. Investigaciones de auditorías muestran que, al parecer, algunos atacantes han explotado este error desde hace al menos cinco meses antes de que fuera descubierto y publicado.

leer más http://es.wikipedia.org/wiki/Heartbleed

agrega un comentario

Algunas recomendaciones críticas sobre el fallo de OpenSSL (Heartbleed)
Por (reenvio) Fernando Acero Martín - Saturday, Apr. 26, 2014 at 4:19 PM

Parece que la comunidad de software libre en particular, y los usuarios de Internet en general, no ganan para sustos y preocupaciones en los últimos días. A fecha de hoy han aparecido problemas en la práctica totalidad de las tecnologías que se usan para hacer que las conexiones sean seguras en Internet y en especial, GnuTLS y OpenSSL. Pero también debemos recordar que hace unos años también hubo serios problemas de seguridad con SSH.

Como ya se ha escrito y hablado mucho sobre el fallo de OpenSSL y llego un poco tarde con mi artículo, solamente resumiré e intentaré aclarar algunas cosas y en la medida de lo posible, aprovecharé para actualizar algo la situación y recomendar algunas acciones prácticas.

Un poco de lo que sabemos

En relación al fallo de OpenSSL sabemos, entre otras cosas, lo siguiente:

a) Es un fallo que lleva algo más de dos años en el código de OpenSSL y convierte inseguras desde la versión 1.0.1 a la 1.0.1f, siendo la versión 1.0.1g, la que resuelve el problema en este momento. Por ser un programa ampliamente utilizado para asegurar las conexiones en Internet, ha afectado a una gran cantidad de servidores y conexiones seguras de todo tipo. Entre los servidores que han podido estar afectados, se han incluido en algunas listas los de Google, Yahoo, Facebook o Twitter, etc. Pero dada la marcada polémica suscitada con la publicación de las listas de servidores afectados y pensando en lo que nos puede pasar en el peor de los casos, lo más razonable es pensar que cualquier servidor ha sido afectado, incluido el de nuestro banco y tomar a la mayor brevedad las medidas que recomendaré más adelante.

b) Este fallo permite obtener todo el contenido de la memoria de un servidor en bloques de 64 kB y ello incluye, entre otras cosas jugosas, las claves privadas usadas para identificar el servidor y asegurar las conexiones SSL. Una vez obtenidas, es posible suplantar dicho servidor y actuar como MitM. Pero como he adelantado en la primera frase de este párrafo, también se puede extraer cualquier otra información que esté siendo procesada en el servidor en ese momento. Eso incluye los datos personales de los usuarios, o sus claves de acceso al servidor. Asimismo, es importante saber, que si un servidor afectado ha sido atacado explotando este fallo en SSL, puede que no quede ningún rastro en el mismo que demuestre que ello ha sido así.

Si tenemos en cuenta lo que hemos dicho en el punto anterior y lo que hemos dicho en este, es posible que algunos responsables de servidores que fueron afectados por el fallo, no lo reconozcan abiertamente por problemas de reputación, o simplemente, aunque estuvieron afectados y es un hecho evidente para ellos por la versión de OpenSSL que utilizaban, desconocen si han sido atacados, o las consecuencias del ataque, por lo que no alertan a sus usuarios. Por lo tanto, mi recomendación en este caso, es ponerse siempre en el peor caso posible y actuar en consecuencia.

c) Aunque el fallo afecta principalmente a servidores y conexiones VPN (Redes Privadas Virtuales), lo que incluye infinidad de servicios en la nube, también puede afectar a otros dispositivos de nuestro entorno que pueden usar OpenSSL para asegurar ciertas conexiones. Por ejemplo: smartphones, puntos de acceso WIFI, tablets, routers ADSL, switches configurables, Smart TV's, receptores de satélite, reproductores multimedia o dispositivos de almacenamiento masivo (NAS) con conexión a Internet, etc.

Recordemos que Android se basa en el kernel de Linux y que tanto Android como Linux, están disponibles en varios miles de millones de dispositivos en este momento. Sin embargo, en muchas ocasiones, como meros usuarios de la tecnología, no somos conscientes del software que usa realmente nuestro flamante dispositivo.

Aprovecho para traer a estas líneas, algo que ya se está comentando con cierta preocupación en algunos foros. La llegada del Internet de las cosas provocará que este problema se multiplique de forma exponencial y más, si los fabricantes de hardware no se conciencian de que la seguridad de sus dispositivos debe estar en el ciclo de vida de los mismos como una de sus prioridades fundamentales. El problema para los fabricantes que opten por fabricar equipos que exploten las enormes posibilidades del Internet de las cosas, es que el ciclo de vida para muchos de estos dispositivos de uso común puede ser extremadamente largo en relación a los ciclos de vida del software.

d) Aunque Robin Seggelmann, el desarrollador que introdujo el error en 2012, ha declarado y en varias ocasiones, que no lo hizo de forma deliberada y que la NSA no estaba detrás del fallo, posteriormente, la agencia de noticias Bloomberg ha anunciado que la NSA conocía el fallo desde sus orígenes y que lo estaba explotando activamente. Como no podía ser de otro modo, la NSA ha negado posteriormente que esa noticia fuera cierta, por lo que cada uno puede pensar lo que quiera al respecto.

e) Aunque todos los expertos en seguridad coinciden al decir que el error es muy grave y que Bruce Schneier incluso ha llegado a decir textualmente lo siguiente:"Catastrophic is the right word. On the scale of 1 to 10, this is an 11", lo cierto es que el NIST ha clasificado esta vulnerabilidad como de riesgo medio CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/AU:N/C:P/I:N/A:N), lo que puede llevar a cierta polémica.

f) Después de descubrirse el fallo, aparecieron una serie de noticias relacionadas con la explotación del mismo, como la relacionada con el joven canadiense arrestado por usar dicha vulnerabilidad de forma efectiva con los servidores de Canada Revenue Agency (CRA) o la relacionada con la explotación con éxito de la vulnerabilidad contra los servidores de Yahoo mail. Pero ¿cómo se han podido detectar este tipo de ataques, cuando decimos que no deja rastro en un servidor?. Evidentemente al mismo tiempo que han aparecido los programas que explotan el problema, también han aparecido las contramedidas especializadas para detectarlo y minimizarlo. Por lo que si alguien usa algún exploit relacionado con HeartBleed contra un servidor, debe saber que puede ser cazado en el intento y que igualmente, puede tener que responder por ello.

También se ha comentado, en base a un ataque realizado con éxito poco después de desvelarse la vulnerabilidad, que para explotarla con éxito era necesario que los servidores hubieran sido arrancados inmediatamente antes del ataque, lo que es improbable que ocurra en un sistema en producción. Pero desde mi punto de vista, lo único que se logra si ataca un servidor cuando acaba de ser arrancado, es facilitar la localización en la memoria de la información relevante para el atacante, por ejemplo, la posición en memoria de los certificados digitales del servidor. Si algo está en la memoria del servidor, dadas las características del fallo y con independencia del momento en el que se realice el ataque, siempre estará disponible para un eventual atacante que tenga paciencia para localizarla.

Más recientemente se ha usado dicha vulnerabilidad para saltarse la seguridad de Redes Privadas Virtuales, lo que abre una nueva y preocupante dimensión al problema de Heartbleed.

También se ha comentado algo que es muy preocupante para muchos usuarios de la Red Tor, la existencia de nodos de dicha Red, teóricamente segura, que eran vulnerables a Heartbleed. Dicho descubrimiento ha provocado que los responsables de la Red Tor, comiencen a rechazarlos mediante la creación de una "black list" de los mismos. Sin embargo, ¿cómo se puede tener la seguridad en una red abierta, como es el caso de Tor, de que los nodos que estamos usando en determinado momento no están afectados?. ¿Quién garantiza que en un momento determinado no se introduzca de forma maliciosa un nodo vulnerable en la Red Tor con el objeto de monitorizar el tráfico e la Red Tor?. Ante esta situación, hay algunos que aconsejan alejarse de la Red Tor, o incluso de Internet, durante un tiempo, si es que se necesita de privacidad.

g) El que no se haya actualizado al día de la fecha está en grave riesgo y va con tiempo negativo. En este momento no paran de salir a la luz pruebas de concepto (PoC) y exploits relacionados con esta grave vulnerabilidad del OpenSSL. Esto hace que el riesgo crezca de forma exponencial con el tiempo para los más retrasados. Como están las cosas, un eventual atacante, incluso con pocos conocimientos sobre el tema, dispone de todo lo necesario para tener éxito en un ataque:

· Sabe que existe una vulnerabilidad.
· Dispone de herramientas para saber si una determinada página es vulnerable.
· Dispone de software para atacar de forma efectiva un servidor vulnerable.

Qué podemos hacer

Las acciones a tomar para protegernos dependerán de si tenemos un servidor, somos clientes de un servidor seguro (https), o si tenemos hardware afectado, por lo que revisaremos cada caso de forma individual.

a) Si tenemos un servidor seguro, las acciones son cuatro y han de ser inmediatas:

· Revocar nuestros certificados digitales del servidor.
· Instalar la nueva versión de OpenSSL, la 1.0.1g o superior.
· Solicitar e instalar nuevos certificados digitales.
· Solicitar a todos los usuarios del servidor que cambien sus contraseñas lo antes posible.

b) Si somos usuarios o clientes de servidores seguros, lo que me atrevo a decir que somos todos los que usamos Internet, la acción es única y también ha de ser inmediata. No es otra que cambiar todas las contraseñas que usamos normalmente para conectarnos a servidores seguros a través de Internet. Por ejemplo: redes sociales, correo electrónico, servicios bancarios, administración electrónica, etc.

Los usuarios también deben tener en cuenta dos cosas en relación a la actualización de sus contraseñas:

· Si quieren saber si un determinado servicio está afectado en la actualidad, pueden usar esta página de McAfee para comprobarlo. Evidentemente si el servidor todavía está afectado, no tiene mucho sentido cambiar nuestra contraseña, por lo que en este caso lo que debemos hacer es enviar un correo a su administrador indicándole que su página es vulnerable y no conectarnos a dicha página, ni cambiar nuestra contraseña, hasta que no lo solucionen adecuadamente. Si usamos nuestras contraseñas, o intentamos actualizar nuestras contraseñas en este momento sobre un servidor que todavía no ha sido actualizado, lo más probable es que sean robadas sin remedio.

· Si recibimos un correo electrónico indicando que debemos cambiar nuestras contraseña en determinado servicio (red social, banco, etc) y dicho correo viene con un enlace, debemos desconfiar y no usar dicho enlace para cambiar nuestras contraseñas. Lo más probable es que sea un ataque de phishing que usa una URL falsa y su intención es robarnos limpiamente la contraseña que introduzcamos. Si queremos conectarnos a una página segura o cambiar nuestras contraseñas de acceso a las mismas, lo que debemos hacer siempre es acceder directamente a la página escribiendo la URL (https) en el navegador. No debemos usar nunca un enlace recibido mediante un correo electrónico, aunque nos parezca legítimo y la página a la que accedemos a través de él nos parezca la correcta primera vista.

· También es muy sano, tras conectarnos a una web segura (https), que antes de introducir nuestras credenciales, es decir, nuestro nombre de usuario y contraseña, que comprobemos el certificado digital de dicha página, para ver que se corresponde con la página que esperamos y que es válido.

c) Si tenemos hardware que pueda estar afectado, el problema se complica y mucho por dos motivos principalmente. El primero, es que es difícil saber, sin la ayuda del fabricante del mismo, si nuestro hardware es vulnerable ante un determinado problema de seguridad, como es el caso del OpenSSL. El segundo, es que siempre dependemos para su actualización de nuestro smartphone, tablet, router, etc, y en la mayoría de los casos de forma secuencial en el tiempo, del fabricante del software origen del problema, en este caso OpenSSL, del fabricante del software que lo integra, por ejemplo Google, del fabricante del hardware que lo usa, por ejemplo Samsung, o incluso, del proveedor de servicios de Internet que lo comercializa (por ejemplo, una compañía telefónica, que en ocasiones personalizan el software). Esta absurda cadena alarga los tiempos de actualización de los dispositivos más de lo necesario y hace que una vulnerabilidad, por pequeña que sea, se pueda convertir en una pesadilla para los usuarios, en especial si afecta, como es el caso, a su información sensible, o le provoca molestas denegaciones de servicio.

En estos casos debemos hacer lo siguiente:

· Consultar al fabricante del dispositivo, o al proveedor de servicios de Internet que lo comercializa, sobre el problema y preguntarle si hay disponible una actualización de seguridad para el mismo en ese momento.
· Si la hay y está disponible para nosotros, instalarla lo antes posible y siguiendo las indicaciones del fabricante del dispositivo.
· Si no está disponible, consultar al fabricante o al proveedor de servicios de Internet que lo comercializa, sobre la forma de protegernos hasta que esté disponible la actualización que corrija el problema.

Tanto Microsoft como Apple han manifestado que tanto los dispositivos basados en Windows Mobile, como en iOS y OSx, así como sus servicios web, no están afectados por el problema del OpenSSL.

En el caso de Android, los móviles más vulnerables al fallo de OpenSSL son los que tienen versiones 4.1 de este sistema operativo, aunque también es cierto, que algunas versiones de Android 2.4 Jelly Bean, que han sido personalizadas por fabricantes u operadores, también pueden ser vulnerables.

Incluso móviles que se han actualizado recientemente a Android KitKat 4.4 pueden estar afectadas por este fallo, por usar versiones de OpenSSL tan antiguas como la 1.0.1e. Sin embargo, aunque tengan instalado un OpenSSL afectado en un dispositivo Android, la posibilidad de explotación del fallo también depende de la configuración del móvil, por lo que lo mejor es usar la aplicación indicada anteriormente para comprobarlo.

De todos modos, si nuestro smartphone está afectado por el fallo, lo más recomendable es no usarlo para realizar conexiones seguras, o manejar información sensible, hasta que dispongamos de una actualización adecuada, lo que puede tardar bastante, si además de Google, dependemos del fabricante y/o del operador para hacerlo.

Existen algunas opciones para saber si nuestro smartphone está afectado por problemas con el SSL o con el TLS:

a) Apple (fallo en el TLS por goto fail).
b) Aplicación Android para comprobar el fallo de OpenSSL.

Pero esta seguridad en relación a los sistemas operativos de los smartphones es relativa. Aunque nuestro smartphone no se vea afectado por el problema de OpenSSL y esto es aplicable de forma indistinta a dispositivos Android, iOS, o Windows Mobile, eso no nos garantiza que no se haya utilizado para acceder a un servidor vulnerable. Por lo que debemos estar atentos a todas las actualizaciones de aplicaciones que se produzcan estos días en relación a este fallo de seguridad y si sabemos que una aplicación móvil ha sido afectada, ya sea por usar la librería afectada internamente, o por conectar con un servidor afectado, no debemos utilizarla hasta que se actualice la aplicación y/o el servidor del servicio y cuando todo esté en orden, deberemos cambiar la contraseña de acceso a dicho servicio lo antes posible.

"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

fuente http://www.kriptopolis.com/recomendaciones-heartbleed

agrega un comentario

Las ondas sísmicas del 'terremoto Heartbleed' aún sacuden la Red
Por (reenvio) Mercè Molist - Saturday, Apr. 26, 2014 at 5:25 PM

Usuarios confundidos porque nadie les avisa de si deben cambiar las contraseñas. Administradores divididos sobre si seguir usando OpenSSL. Programadores replanteándose cómo debe auditarse el "software" libre. Discusiones bizantinas por si los servicios secretos norteamericanos sabían antes que nadie que existía el fallo. Más discusiones bizantinas, en la comunidad de seguridad, sobre si la gravedad de "Heartbleed" es media o alta. La red Tor, tambaleándose. Dos semanas después de que el mundo conociese la existencia de un grave error en la principal herramienta que cifra comunicaciones y contenidos de Internet, sólo hay algo claro: que las grandes compañías de la red entonan el "mea culpa" y ponen dinero para mejorar OpenSSL.

El mayor damnificado por el agujero de seguridad 'Hearbleed', descubierto en diciembre y hecho público recientemente, ha sido el propio OpenSSL. El 'gurú' Robert Graham lo ha llamado "spaguetti code" , aunque ha defendido a quienes lo han creado. Otro peso pesado, Theo de Raadt, fundador del sistema operativo libre OpenBSD en 1995, lo ha calificado de "caos" con "miles de líneas de código superfluas" y no ha querido usarlo ni un minuto más: el equipo de OpenBSD ha creado un "fork" (un nuevo proyecto basado en otro) de OpenSSL llamado LibreSSL que está despertando gran interés.

Steve Marquess, líder del Proyecto OpenSSL, no ha querido hacer comentarios sobre LibreSSL. Ha preferido dirigir sus iras contra las empresas, como escribía en su blog : "Os miro a vosotras, compañías del Fortune 1000, las que tenéis OpenSSL en vuestros productos de seguridad, financieros, en la nube o cortafuegos, que vendéis o usáis para asegurar vuestras infraestructuras y comunicaciones. Las mismas que no tenéis que pagar a un equipo de programadores para pelearse con el código criptográfico y que nos agobiáis pidiendo consultorías gratuitas cuando no sabéis cómo usarlo. Las mismas que nunca habéis movido un dedo para contribuir a la comunidad libre que os ha hecho este regalo. El misterio es que esto no haya pasado antes".

'Heartbleed' ha puesto sobre la mesa una realidad hacia la que muchos no querían mirar: la precariedad en la que sobreviven la mayoría de proyectos de "software" libre, basados en las donaciones y el voluntariado, prácticamente sin presupuesto y con poco tiempo para las tareas alejadas del día a día de añadir código, como la delicada tarea de auditar los programas resultantes. Esos programas que usan las empresas a coste 0 y sin obligación de invertir en el proyecto, presuponiendo además que el producto resultante es perfecto. Como explica Miguel López en Genbeta: "OpenSSL lo ha estado manteniendo un solo programador trabajando a jornada completa y con un apoyo en donaciones de 2.000 dólares al año".

Como respuesta, la Fundación Linux ha puesto en marcha la Iniciativa Infraestructura Central (Core Infrastructure Initiative) que ha conseguido cuatro millones de dólares en donaciones de Google, Facebook, Microsoft, Amazon, Rackspace, Cisco, Dell, Fujitsu, IBM, Intel, NetApp y VMware. Con este dinero se financiarán, los próximos tres años, los proyectos libres que quieran auditar su código y la mayor parte del dinero se destinará a OpenSSL. Según el líder de OpenSSL, el proyecto debería tener seis personas trabajando a tiempo completo.

En cuanto a las repercusiones en el mundo de la seguridad, desde que "Heartbleed" se hizo público hace dos semanas se han conocido unos pocos ataques que lo explotaban. Destacan uno contra la Canada Revenu Agency, destinado a robar datos de empresarios y empresas, relacionados con el pago de impuestos. Y otro que quería violar la red privada virtual de una corporación cuyo nombre no ha trascendido.

Un problema añadido para las empresas es que, si debido a "Heartbleed" sufren un robo de datos de sus clientes, las autoridades de protección de datos pueden multarlas. Según el abogado David Maeztu, es un riesgo a tener en cuenta: "El administrador debe comprobar si su sitio tiene este defecto o no y en su caso aplicar el parche o remedio correspondiente. En caso de no hacerlo y sufrir una denuncia por un robo de datos, la Agencia podría iniciar un procedimiento de inspección". Según la Ley de Protección de Datos, sería una infracción grave y podría costar a la empresa entre 60.000 y 300.000 euros de multa.

La red Tor ha sido otro damnificado de "Heartbleed". Tor permite usar los servicios de Internet de forma anónima y todos sus servicios usan cifrado, OpenSSL mayoritariamente. Era cuestión de probabilidades que "Heartbleed" atacase con más fuerza a Tor que a Internet, y así ha sido: nodos, programas y servicios de esta red, entre ellos el cliente Orbot para acceder a Tor con Android, estaban afectados. Según Ars Technica, aunque se ha trabajado rápido y la infraestructura central de Tor ya está libre de peligro, el 10% de la red (586 nodos) aún es vulnerable: "Muchos servidores que están en países que censuran fuertemente Internet no han sido "parcheados", estos sistemas son operados por voluntarios y funcionan sin supervisión".

Inquietud entre los usuarios

Otro frente abierto es el desconcierto o, peor aún, desconocimiento de los usuarios de Internet sobre "Heartbleed" y por qué las empresas afectadas no les han comunicado personalmente que debían cambiar sus contraseñas. El sitio Mashable creó una lista de servicios con millones de usuarios que habrían sido afectados: Facebook, Instagram, Tumblr, Twitter, Google y Gmail, Yahoo y Yahoo! Mail, GoDaddy, Flickr, Youtube, Dropbox, Wikipedia, Wordpress... Pero, hasta la fecha, nadie ha dicho nada. Sólo Pinterest ha mandado correos electrónicos a sus usuarios recomendando cambiar contraseñas.

Según han contado algunas empresas afectadas a los medios, no han avisado directamente a sus usuarios porque "no había evidencias de que hubiesen robado sus datos". Uno de los problemas de "Heartbleed" es, precisamente, que si alguien roba datos, por las características de este fallo no dejará ningún rastro ni evidencia. Otros servicios, como Dropbox y Google, sí han advertido a sus usuarios pero sólo a través de su blog corporativo y cuenta oficial en Twitter. A preguntas de los periodistas, Google aseguraba que sus usuarios "no necesitan cambiar contraseñas" mientras en su blog oficial los mismos usuarios preguntaban, sin respuesta: ¿Seguro?.

Google es responsable también del sistema operativo Android, cuya versión 4.1 está afectada, así como diveresas aplicaciones de la Google Play Store que suman 150 millones de descargas, según un estudio de los investigadores Yulong Zhang, Hui Xue y Tao Wei (http://seguridad.ticbeat.com/150-millones-descargas-apps-android-afectadas-heartbleed). El experto en criptografía Fernando Acero señala, en un comentado artículo de Kriptópolis: "Recordemos que tanto Android como Linux están disponibles en varios miles de millones de dispositivos en este momento. Como meros usarios de la tecnología no somos conscientes del "software" que usa realmente nuestro flamante dispositivo".

Esta es otra cuestión que ha destapado "Heartbleed": la llamada Internet de las Cosas viene pisando muy fuerte, con todo tipo de aparatos, desde los "routers" domésticos hasta neveras, conectados a Internet y equipados con "software" que puede tener fallos como el de OpenSSL, nunca solucionados porque el fabricante no quiera gastar dinero en ello, alerta la "MIT Technology Review". Dice Acero: "La llegada del Internet de las cosas provocará que este problema se multiplique de forma exponencial y más, si los fabricantes no se conciencian de que la seguridad de sus dispositivos debe estar en el ciclo de vida de los mismos como una de sus prioridades fundamentales. El problema es que el ciclo de vida para muchos de estos dispositivos de uso común puede ser extremadamente largo en relación a los ciclos de vida del software".

fuente http://www.elmundo.es/tecnologia/2014/04/26/535a606d268e3e51688b4585.html

agrega un comentario