Un fallo en un programa de la empresa AVID está dejando fuera de juego a los Mac Pro por todo Hollywood

El nuevo Mac Pro de Apple saldrá a la venta este otoño, pero su versión anterior sigue siendo un ordenador muy popular por todo Hollywood utilizado por editores de TV y películas. Sus características técnicas unido a la gran cantidad de software específico para edición de video son los factores que han hecho de este ordenador el más utilizado por las productoras. Este pasado lunes por la tarde, muchas de estas estaciones de trabajo no querían arrancar, causando el pánico entre las empresas creadores de contenido por todo Los Ángeles.

Pronto llegaron las primeras especulaciones sobre las posibles causas del problema. Al principio se pensó que su origen era el ataque de un virus pero pronto se distribuyeron mensajes por redes sociales donde se ofrecía más información. Al parecer, el problema afectaba a usuarios de ordenadores Mac Pro con versiones anteriores de MacOS Server (aunque posiblemente uno de los más populares es el OS X server) y que utilizaban el software AVID Media Composer.

Figura 1. AVIT Media Composer. Fuente.

Algunos usuarios, como el productor freelance Marcus Pun, lo avisó a través de un grupo de Facebook indicando que no apagaran los ordenadores e hicieran lo antes posible copia de seguridad. Al parecer algo había provocado un problema en el sistema de ficheros afectando al arranque del ordenador. Marcus no fue el único pronto la red se inundó de mensajes similares que afectaba a los usuarios del Mac Pro o "la papelera" (trashcan), nombre coloquial utilizado para este ordenador.

Figura 2. Mensaje de alerta sobre los errores publicado por Marcus Pun. Fuente.

Al parecer el problema ha sido una combinación de una actualización reciente del sistema operativo con el software de AVID. Por lo tanto, es buena idea hacer copia de seguridad de los datos y reinstalar de nuevo el sistema operativo. Algunas especulaciones por la red indican que el problema puede que no esté relacionado con el editor de AVID directamente sino con el sistema de protección de copia. Seguiremos atentos a esta noticia para determinar finalmente la causa del problema.

Cuando Wozniak borró los discos para la presentación de la unidad de discos del Apple II (la noche antes de presentarla)

Steve Wozniak también comete algunos errores. Y uno de ellos le ocurrió en la presentación del Apple II y su flamante nueva unidad de discos durante la celebración del segundo CES (1978) de la historia. Por aquella época, el Apple II no tenía unidad de disco, un periférico que cada vez estaba más en auge gracias entre otras cosas, al abaratamiento de las unidades. De hecho, estas estaban cambiando de 8" a 5"1/4, lo cual acercaba mucho más estos periféricos al usuario personal.

Apple ya iba al CES a presentar oficialmente al público su flamante Apple II, pero Wozniak sabía que no podían ir allí sin tener una unidad de discos. Un par de semanas antes del evento, levantó la mano durante una reunión y dijo "...si tenemos una a tiempo para CES ¿podemos presentarla?". En ese momento faltaban menos de dos semanas para el evento. Crear desde cero una unidad de disco, la controladora, etc, era un proyecto de prácticamente un año de duración. Wozniak quería hacerlo en dos semanas.

Figura 1. Parte de los esquemas de la controladora de disco creada por Wozniak. Fuente.

Así que durante el poco tiempo que quedaba hasta el evento, se encerró a estudiar los esquemas electrónicos creados por Alan Shugart, uno de los padres de las unidades de disco y los discos duros. Por lo tanto, Wozniak pasó el día de Navidad y el de Fin de Año de 1977 analizando dichos esquemas y buscando la forma de abaratar la construcción de su unidad de disco. Los esquemas de Shugart utilizaban hasta 50 chips. Después de su investigación, la unidad de Wozniak sólo utilizaba 7 y además funcionaba mejor y ofrecía nuevas funcionalidades (la reducción de chips en un proyecto era la gran obsesión de la época, ya que a menor número de chips, mucho más barato sería el producto final).

Finalmente, Steve Wozniak construyó la unidad de disco, la controladora y todo el firmware necesario a tiempo para el CES. La noche anterior a la presentación (que era el día siguiente por la tarde), la pasaron comprobando y realizando pruebas del nuevo periférico. Todo funcionaba a la perfección, estaban preparados para presentarla en el CES junto al Apple II, éxito seguro. Pero debido al cansancio (llevaban días sin apenas dormir), cuando Wozniak comenzó a grabar los ficheros  cometió un error. Los discos no estaban etiquetados y los borró, es decir, sobreescribió la información correcta por ficheros en blanco. En vez de llorar o tirarse de los pelos, Wozniak se fue a la cama y dijo para sí mismo "lo tengo todo en mi cabeza, mañana lo reconstruyo".

Figura 2. Unidad de disco y controladora creada por Wozniak para el CES de 1978. Fuente.

Y así fue. A la mañana siguiente Wozniak se levantó a las 10:00 am, y a las 12:00 ya lo tenía todo otra vez preparado. Así que bajó al stand que tenían en el CES (básicamente el stand era una tabla y dos caballetes) y empezaron a presentar las bondades de su maravilloso Apple II y la nueva unidad de disco. Además, el precio de venta, al reducir tanto los chips y optimizar su funcionamiento, era muy bajo respecto a sus competidores. Esta costaba alrededor de 500$ de la época cuando otras llegaban a más de 2.000 o 10.000$. Genio y figura Wozniak.

El bug de Facetime que permite escuchar y ver a la persona que llamas ... antes de que conteste

La aparición de un fallo en FaceTime se ha expandido rápidamente por las redes desde el día de ayer. En este momento, FaceTime está offline mientras intentan repararlo desde Apple. Como se ha indicado en el título de este artículo, el error permitía escuchar al destinatario de una llamada incluso antes de descolgar, exponiendo gravemente la privacidad de las personas que reciben la llamada. Y  además afecta a todos los usuarios de iPhone con versión iOS 12 o superior.

Vamos a ver la operativa para sacar partido a este bug:

• Se inicia una llamada de video por FaceTime a cualquier contacto del iPhone.
• Mientras escuchamos el sonido de marcado, añadimos a otra persona a la conversación.
• Pero esta vez añadimos nuestro propio número de teléfono (desde el cual se está realizando la llamada).
• Esto iniciará una llamada FaceTime donde podremos escuchar el audio de la otra persona aunque no haya descolgado todavía.

Figura 1. Proceso de llamada FaceTime con la opción de añadir otra persona para llamada en grupo. Fuente.

Por otro lado, sí además la persona que está recibiendo la llamada pulsa el botón de volumen, ya sea para subirlo o bajarlo (reacción bastante habitual), también mostrará el vídeo del receptor de la misma antes de descolgar. Y lo peor es que en ningún momento sabemos que estamos enviando tanto el audio como el vídeo, por lo que todo el tiempo que durase la llamada la persona que la ha realizado estaría viendo y oyendo todo lo que pasa en el teléfono receptor.

Pero además, desde 95toMac han replicado también el bug llamando desde un iPhone a un Mac con la última versión de Mojave. En este caso el Mac retiene más tiempo la llamada por lo que se prolonga la duración de escucha o de vídeo (en iPad es bastante probable que también funcione este mismo bug). En el siguiente vídeo se muestra una demo:

La pregunta ahora es ¿desde cuándo ha estado este fallo de seguridad activo? por lo visto está asociado a las videollamdas en grupo que Apple lanzó en iOS 12, hace ya unos meses (desde esa versión para atrás no existía esta opción de llamadas en grupo). De momento Apple ha deshabilitado FaceTime y es posible que salga en breve un parche para solucionar este problema. De todas formas, es recomendable desactivarlo hasta que esté solucionado del todo oficialmente.

Un fallo en la tienda online de Apple expone el PIN de miles de clientes de T-mobile

El pasado mes de agosto se detectó un importante fallo en la seguridad de la tienda online de Apple, como consecuencia de este fallo han quedado expuestos los 'pines' de más de 72 millones de clientes de T-Mobile (operador de telefonía móvil de origen alemán). La vulnerabilidad fue descubierta por dos investigadores, conocidos como Phobia y Nicholas Cearolo, los cuales también descubrieron un fallo similar en la página web de una compañía aseguradora de teléfonos llamada Asurion durante los anteriores meses.

Tanto Apple como Asurion ya han arreglado sus páginas solucionando el problema de exposición de los pines de sus usuarios, como es habitual Apple no ha querido dar detalles acerca del fallo, sin embargo ha agradecido su trabajo a los investigadores que encontraron la brecha en su seguridad. Los pines o contraseñas son números que se utilizan como una medida de seguridad adicional y suelen ser la última línea de defensa en las cuentas móviles. Hoy en día estos pines son más importantes que nunca, el SIM hacking, que utiliza ingeniería social para transferir el número de teléfono de una víctima a otra tarjeta SIM, ha incrementado exponencialmente durante los últimos años.

Figura 1: Página que solicita el PIN el número de teléfono

Para acceder a los pines de T-Mobile desde la web de Apple los investigadores realizaron un ataque de fuerza bruta en el que un software era capaz de dar con el pin correcto tras probar con numerosas combinaciones posibles. Según BuzzFeed, al iniciar la compra de un iPhone de T-mobile a través de la tienda online y seleccionar la opción de pago mensual con la factura de teléfono, los usuarios son redirigidos a un formulario de autenticación en el que se les solicita un número de teléfono y un pin de 4 dígitos, esta página permite introducir el pin un número ilimitado de veces haciendo que sea posible realizar un ataque de fuerza bruta. Por el momento esta vulnerabilidad parece afectar únicamente a los usuarios de T-mobile, ya que con el resto de compañías el formulario solo te permite introducir el pin incorrecto un determinado número de veces.

Apple contra la justicia Australiana por el brickeo de dispositivos reparados por empresas de terceros

Hace unos días tuvo lugar el juicio entre Apple y la justicia australiana relativo al brickeo de miles de dispositivos iOS debido a un test de seguridad de fábrica en 2016. El juicio federal ha concluido a favor de la comisión de competencia y consumidores de Australia (ACCC) que archivaba un caso en contra de Apple desde el año 2016. Los problemas comenzaron tras el lanzamiento de iOS 9.2.1 para los dispositivos móviles, el nuevo sistema operativo en cuestión contenía un test de fábrica cuya finalidad era verificar que el escáner de huellas (Touch ID) del dispositivo era original.

La implementación de este test provocó que todos aquellos dispositivos de Apple reparados por terceros o empresas de reparación no autorizadas mostrasen en la pantalla el mensaje “Error 53” y brickeasen los dispositivos. En el juicio la ACCC alegó que la empresa californiana se negó a revisar o reparar estos dispositivos ya que habían sido reparados por terceros, aunque la reparación no estuviese relacionada con fallos en el sistema operativo (reparaciones como la sustitución de la pantalla o un sensor que no funciona). Durante el juicio Apple admitió haberse negado a arreglar los dispositivos de al menos 275 clientes, sin embargo la cifra de usuarios afectados asciende al menos hasta los 5000.

Figura 1: Logo de la Australian Competition & Consumer Commission.

“El mero hecho de que un iPhone o iPad haya sido reparado por terceros, no resulta ni debería resultar en el cese de la validez de su garantía. Las compañías globales deben asegurarse de que sus políticas de devoluciones y reparaciones se adecuen a la ley de consumidores australiana o de lo contrario se emprenderán acciones legales para remediarlo” Ha dicho Sarah Court, comisaria de la ACCC.

Tras la resolución del juicio, la empresa de cupertino ha dicho que ha contactado con al menos 5000 clientes afectados para compensarles por las consecuencias del “Error 53” y ofrecerles la reparación gratuita del dispositivo afectado o el reemplazo del mismo así lo desean.

¿Cómo es posible que un único carácter sea capaz de bloquear tu iPad, iPhone, Apple Watch o Mac?

Hace un par de días hablamos de la noticia de cómo un sólo carácter era capaz de bloquear un iPhone, iPad o Mac. La repercusión mediática ha sido bastante amplia y por lo tanto, Apple se ha dado prisa en solucionarlo en la versión 11.2.6. Todos sabemos las consecuencias de este fallo, al cual se le ha asignado el CVE-2018-4124, pero ¿sabes por qué ocurre?. Vamos a intentar explicarlo brevemente.

Este bug bloqueaba (o colgaba como se suele decir en el argot informático) el dispositivo Apple simplemente al mostrar algunos caracteres Telugu. Cualquier aplicación que lo intente, directamente se cuelga y no se puede restaurar hasta que no sea eliminado. El dispositivo se reinicia si el fallo activa un componente en el sistema operativo, como por ejemplo Springboard, la aplicación que controla la pantalla principal de iOS. Incluso puede acabar en un bucle de reinicios que sólo puede ser solucionado con un DFU (Device Firmware Update), con lo que perderíamos la información almacenada. El vídeo a continuación muestra el bug en acción:

Para entender la raíz del problema primero tenemos que hablar de Unicode, un estándar que consiste en asignar un único número a cada carácter, para evitar las limitaciones del código ASCII. Los códigos Unicode se escriben con una "U+" seguido por el código numérico en hexadecimal que corresponde al caracter, por ejemplo la letra "A" sería U+0041. Unicode también incluye caracteres especiales, como por ejemplo U+0020 que corresponde a un espacio. Por defecto, la lectura Unicode se realiza de izquierda a derecha, aunque se puede configurar para idiomas como por ejemplo el árabe para que sean de derecha a izquierda añadiendo algunos marcadores especiales.

El lenguaje Telugu se representa con algunos caracteres agrupados horizontalmente. En concreto, el símbolo que era capaz de bloquear dispositivos Apple estaba compuesto por cinco distintos formado por los códigos siguientes: U+0C1C, U+0C4D, U+0C1E, U+200C y U+0C3E. La representación gráfica de este carácter es:

Figura 1. Carácter Telugu, la cual es la raíz de la palabra "conocimiento" que provoca el error. Fuente.

A nosotros nos interesa el U+200C también llamado ZWNJ o "Zero Width Non-Joiner" el cual es un separador invisible que sirve para unir algunos de los caracteres que forma el símbolo final. Parece ser que la causa de este bug es este separador combinado con ciertos caracteres Telugu. El buffer que corresponde al símbolo en memoria devuelve un puntero nulo a la aplicación, en vez de uno que indique la posición correcta en memoria. Por lo tanto, cuando el programa intenta acceder a dicha ubicación, esta no existe y el sistema operativo revoca los permisos de escritura y lectura para evitar una corrupción de memoria mayor. Este es el error que aparece:

Figura 2. Captura del volcado del error provocado por el carácter Telugu. Fuente.

Como hemos comentado al principio, Apple ya ha solucionado este error en la versión 11.2.6 para iPhone y iPads. Como otros dispositivos como el Apple Watch comparten parte del mismo núcleo, como el motor gráfico, estos son también vulnerables a este incómodo bug. La verdad es que Apple está teniendo un comienzo de año movido en el tema de la seguridad de sus dispositivos.