Un parche es un dato que se pretende utilizar para modificar un recurso de software existente, como un programa o un archivo , a menudo para corregir errores y vulnerabilidades de seguridad . [1] [2] Un parche se puede crear para mejorar la funcionalidad, la facilidad de uso o el rendimiento . Un parche suele ser proporcionado por un proveedor para actualizar el software que ofrece.
Un parche se puede crear manualmente, pero comúnmente se crea mediante una herramienta que compara dos versiones del recurso y genera datos que pueden usarse para transformar una en otra.
Por lo general, un parche debe aplicarse a la versión específica del recurso que se pretende modificar, aunque existen excepciones. Algunas herramientas de aplicación de parches pueden detectar la versión del recurso existente y aplicar el parche adecuado, incluso si admite varias versiones. A medida que se lanzan más parches, su tamaño acumulado puede crecer significativamente, a veces superando el tamaño del recurso en sí. Para gestionar esto, se puede limitar la cantidad de versiones compatibles o se puede proporcionar una copia completa del recurso en su lugar.
La aplicación de parches permite modificar un programa compilado ( en lenguaje de máquina ) cuando el código fuente no está disponible. Esto exige un conocimiento profundo del funcionamiento interno del código compilado, lo que resulta complicado sin acceso al código fuente.
La aplicación de parches permite realizar cambios en un programa sin tener que reconstruirlo desde el código fuente. Para cambios pequeños, puede resultar más económico distribuir un parche que distribuir el recurso completo.
Aunque a menudo se pretende solucionar problemas, un parche mal diseñado puede generar nuevos problemas (consulte Regresiones de software ). En algunos casos, las actualizaciones pueden interrumpir deliberadamente la funcionalidad o deshabilitar un dispositivo, por ejemplo, al eliminar componentes para los que el proveedor de actualizaciones ya no tiene licencia.
La gestión de parches es parte de la gestión del ciclo de vida y es el proceso de utilizar una estrategia y un plan sobre qué parches deben aplicarse a qué sistemas en un momento específico.
Por lo general, un parche se aplica mediante un control programado al almacenamiento de la computadora para que sea permanente. En algunos casos, un programador aplica un parche mediante una herramienta, como un depurador , a la memoria de la computadora , en cuyo caso el cambio se pierde cuando el recurso se vuelve a cargar desde el almacenamiento.
Los parches para software propietario se distribuyen normalmente como archivos ejecutables en lugar de código fuente . Cuando se ejecutan, estos archivos cargan un programa en la memoria que administra la instalación del código del parche en el programa o programas de destino en el disco.
Los parches para otro software se distribuyen normalmente como archivos de datos que contienen el código del parche. Estos son leídos por un programa de utilidad de parches que realiza la instalación. Esta utilidad modifica el archivo ejecutable del programa de destino (el código de máquina del programa ) normalmente sobrescribiendo sus bytes con bytes que representan el nuevo código del parche. Si el nuevo código cabe en el espacio (número de bytes) ocupado por el código antiguo, se puede colocar sobrescribiendo directamente sobre el código antiguo. Esto se denomina parche en línea. Si el nuevo código es más grande que el antiguo, la utilidad de parches añadirá registros de carga que contengan el nuevo código al archivo de objeto del programa de destino que se está parcheando. Cuando se ejecuta el programa parcheado, la ejecución se dirige al nuevo código con instrucciones de bifurcación (saltos o llamadas) parcheadas sobre el lugar del código antiguo donde se necesita el nuevo código. En las primeras microcomputadoras de 8 bits, por ejemplo la Radio Shack TRS-80 , el sistema operativo incluye una utilidad PATCH/CMD que acepta datos de parches de un archivo de texto y aplica las correcciones a los archivos binarios ejecutables del programa de destino.
El código de parche debe tener un lugar o lugares en la memoria para ser ejecutado en tiempo de ejecución. Los parches en línea no son difíciles, pero cuando se necesita espacio de memoria adicional, el programador debe improvisar. Naturalmente, si el programador del parche es el que creó primero el código que se va a parchear, esto es más fácil. Los programadores expertos planifican con anticipación esta necesidad reservando memoria para una expansión posterior, que no se utiliza al producir su iteración final. Otros programadores que no están involucrados con la implementación original, que buscan incorporar cambios en un momento posterior, deben encontrar o hacer espacio para los bytes adicionales necesarios. La circunstancia más afortunada posible para esto es cuando la rutina que se va a parchear es un módulo distinto. En este caso, el programador del parche simplemente necesita ajustar los punteros o indicadores de longitud que señalan a otros componentes del sistema el espacio ocupado por el módulo; entonces es libre de llenar este espacio de memoria con su código de parche expandido. Si la rutina que se va a parchear no existe como un módulo de memoria distinto, el programador debe encontrar formas de reducir la rutina para hacer suficiente espacio para el código de parche expandido. Las tácticas típicas incluyen acortar el código mediante la búsqueda de secuencias de instrucciones más eficientes (o rediseñándolo con algoritmos más eficientes), compactar cadenas de mensajes y otras áreas de datos, externalizar funciones del programa a almacenamiento masivo (como superposiciones de disco) o eliminar características del programa consideradas menos importantes que los cambios que se instalarán con el parche.
Se pueden aplicar manualmente pequeños parches de código de máquina en memoria con la utilidad de depuración del sistema, como DDT de CP/M o los depuradores DEBUG de MS-DOS . Los programadores que trabajaban en BASIC interpretado solían utilizar el comando POKE para alterar la funcionalidad de una rutina de servicio del sistema o del propio intérprete.
Los parches también pueden circular en forma de modificaciones del código fuente. En este caso, los parches suelen consistir en diferencias textuales entre dos archivos de código fuente, llamadas " diffs ". Este tipo de parches suelen surgir de proyectos de software de código abierto . En estos casos, los desarrolladores esperan que los usuarios compilen ellos mismos los archivos nuevos o modificados.
Debido a que la palabra "parche" conlleva la connotación de una pequeña corrección, las correcciones de gran tamaño pueden utilizar una nomenclatura diferente. Los parches voluminosos o los parches que cambian significativamente un programa pueden circular como " paquetes de servicio " o como "actualizaciones de software". Microsoft Windows NT y sus sucesores (incluidos Windows 2000 , Windows XP , Windows Vista y Windows 7 ) utilizan la terminología de "paquete de servicio". [3] Históricamente, IBM utilizaba los términos "FixPaks" y "Disquete de servicio correctivo" para referirse a estas actualizaciones. [4]
Históricamente, los proveedores de software distribuían parches en cinta de papel o en tarjetas perforadas , esperando que el destinatario cortara la parte indicada de la cinta (o pletina) original y parcheara (de ahí el nombre) el segmento de reemplazo. Las distribuciones de parches posteriores utilizaron cinta magnética. Luego, después de la invención de las unidades de disco extraíbles, los parches vinieron del desarrollador de software a través de un disco o, más tarde, CD-ROM por correo . Con el acceso a Internet ampliamente disponible, la descarga de parches desde el sitio web del desarrollador o mediante actualizaciones de software automáticas se volvió a menudo disponible para los usuarios finales. A partir del Mac OS 9 de Apple y Windows ME de Microsoft , los sistemas operativos de PC adquirieron la capacidad de obtener actualizaciones de software automáticas a través de Internet.
Los programas informáticos suelen poder coordinar parches para actualizar un programa de destino. La automatización simplifica la tarea del usuario final: sólo tiene que ejecutar un programa de actualización, que se encarga de que la actualización del programa de destino se realice de forma completa y correcta. Los paquetes de servicios para Microsoft Windows NT y sus sucesores, así como muchos productos de software comerciales, adoptan este tipo de estrategias automatizadas.
Algunos programas pueden actualizarse a través de Internet con muy poca o ninguna intervención por parte de los usuarios. El mantenimiento del software del servidor y de los sistemas operativos se realiza a menudo de esta manera. En situaciones en las que los administradores de sistemas controlan varios equipos, este tipo de automatización ayuda a mantener la coherencia. La aplicación de parches de seguridad se produce habitualmente de esta manera.
Con la llegada de medios de almacenamiento de mayor tamaño y un mayor ancho de banda de Internet, se volvió común reemplazar archivos enteros (o incluso todos los archivos de un programa) en lugar de modificar archivos existentes, especialmente para programas más pequeños.
El tamaño de los parches puede variar desde unos pocos bytes hasta cientos de megabytes ; por lo tanto, los cambios más significativos implican un tamaño mayor, aunque esto también depende de si el parche incluye archivos completos o solo las partes modificadas de los archivos. En particular, los parches pueden llegar a ser bastante grandes cuando los cambios agregan o reemplazan datos que no son del programa, como archivos de gráficos y sonidos. Tales situaciones ocurren comúnmente en la aplicación de parches a los juegos de computadora . En comparación con la instalación inicial del software, los parches generalmente no tardan mucho en aplicarse.
En el caso de los sistemas operativos y el software de servidores informáticos , los parches tienen el papel particularmente importante de reparar los agujeros de seguridad. Algunos parches críticos implican problemas con los controladores. [5] Los parches pueden requerir la aplicación previa de otros parches, o pueden requerir actualizaciones previas o simultáneas de varios componentes de software independientes. Para facilitar las actualizaciones, los sistemas operativos a menudo proporcionan instalaciones de actualización automáticas o semiautomáticas. Las actualizaciones completamente automáticas no han logrado ganar una popularidad generalizada en los entornos informáticos corporativos, en parte debido a los fallos mencionados anteriormente, pero también porque los administradores temen que las empresas de software puedan obtener un control ilimitado sobre sus computadoras. [ cita requerida ] Los sistemas de gestión de paquetes pueden ofrecer varios grados de automatización de parches.
El uso de actualizaciones completamente automáticas se ha vuelto mucho más extendido en el mercado de consumo, debido en gran medida [ cita requerida ] al hecho de que Microsoft Windows agregó soporte para ellas [ ¿cuándo? ] , y el Service Pack 2 de Windows XP (disponible en 2004) las habilitó de manera predeterminada. Los usuarios cautelosos, en particular los administradores de sistemas, tienden a posponer la aplicación de parches hasta que pueden verificar la estabilidad de las correcciones. Microsoft (W)SUS admite esto. En los casos de parches grandes o de cambios significativos, los distribuidores a menudo limitan la disponibilidad de parches a desarrolladores calificados como una prueba beta .
La aplicación de parches al firmware plantea desafíos especiales, ya que a menudo implica el suministro de imágenes de firmware totalmente nuevas, en lugar de aplicar solo las diferencias de la versión anterior. El parche generalmente consta de una imagen de firmware en forma de datos binarios, junto con un programa especial proporcionado por el proveedor que reemplaza la versión anterior con la nueva versión; una actualización del BIOS de la placa base es un ejemplo de un parche de firmware común. Cualquier error o interrupción inesperados durante la actualización, como un corte de energía, puede dejar la placa base inutilizable. Es posible que los fabricantes de placas base implementen salvaguardas para evitar daños graves; por ejemplo, el procedimiento de actualización podría hacer y mantener una copia de seguridad del firmware para usar en caso de que determine que la copia principal está dañada (generalmente mediante el uso de una suma de comprobación , como un CRC ).
Los videojuegos reciben parches para solucionar problemas de compatibilidad después de su lanzamiento inicial al igual que cualquier otro software, pero también se pueden aplicar para cambiar las reglas o algoritmos del juego . Estos parches pueden ser provocados por el descubrimiento de exploits en la experiencia de juego multijugador que se pueden usar para obtener ventajas injustas sobre otros jugadores. A menudo se pueden agregar características adicionales y ajustes de juego. Este tipo de parches son comunes en los juegos de disparos en primera persona con capacidad multijugador , y en los MMORPG , que suelen ser muy complejos con grandes cantidades de contenido, casi siempre dependen en gran medida de los parches posteriores al lanzamiento inicial, donde los parches a veces agregan nuevo contenido y habilidades disponibles para los jugadores. Debido a que el equilibrio y la equidad para todos los jugadores de un MMORPG pueden corromperse gravemente en un corto período de tiempo por un exploit, los servidores de un MMORPG a veces se eliminan con poca antelación para aplicar un parche crítico con una solución.
En ocasiones, las empresas lanzan juegos sabiendo que tienen errores. En 1994, Scorpia , de Computer Gaming World , denunció a "las empresas, demasiado numerosas para mencionarlas todas, que lanzan productos de mala calidad sabiendo que pueden salir adelante con parches y actualizaciones, y que convierten a sus clientes en ' probadores de pago '". [6]
En ocasiones, los parches se vuelven obligatorios para solucionar problemas con bibliotecas o con partes del código fuente de programas que se usan con frecuencia o que se encuentran en mantenimiento. Esto ocurre comúnmente en proyectos de software de gran escala, pero rara vez en desarrollos a pequeña escala.
En los proyectos de código abierto, los autores suelen recibir parches o muchas personas publican parches que solucionan problemas particulares o añaden cierta funcionalidad, como compatibilidad con idiomas locales fuera de la configuración regional del proyecto. En un ejemplo del desarrollo inicial del núcleo Linux (conocido por publicar su código fuente completo), Linus Torvalds , el autor original, recibió cientos de miles de parches de muchos programadores para aplicarlos contra su versión original.
El servidor Apache HTTP se desarrolló originalmente como una serie de parches que Brian Behlendorf recopiló para mejorar NCSA HTTPd , de ahí su nombre que implica que es una colección de parches ( "un servidor con parches" ). Las preguntas frecuentes en el sitio oficial del proyecto indican que el nombre "Apache" se eligió por respeto a la tribu indígena americana de Apache . Sin embargo, la explicación de "un servidor con parches" se dio inicialmente en el sitio web del proyecto. [7]
Una revisión rápida o actualización de ingeniería de corrección rápida (actualización QFE) es un paquete único y acumulativo que incluye información (a menudo en forma de uno o más archivos) que se utiliza para solucionar un problema en un producto de software (es decir, un error de software). Normalmente, las revisiones rápidas se realizan para solucionar una situación específica de un cliente. Microsoft alguna vez utilizó este término, pero dejó de usarlo a favor de una nueva terminología: versión de distribución general (GDR) y versión de distribución limitada (LDR). Blizzard Entertainment , sin embargo, define una revisión rápida como "un cambio realizado en el juego que se considera lo suficientemente crítico como para que no se pueda posponer hasta un parche de contenido regular".
Una versión puntual es una versión menor de un proyecto de software, especialmente una que tiene como objetivo corregir errores o realizar pequeñas mejoras en lugar de agregar funciones importantes . A menudo, hay demasiados errores para corregir en una única versión principal o secundaria, lo que crea la necesidad de una versión puntual.
La terminología estándar de IBM para una corrección temporal de errores o un grupo de correcciones, distribuidas en un formato listo para instalar por los clientes, es la corrección temporal del programa o corrección temporal del producto (PTF, según la fecha). A veces se hacía referencia a un PTF como “ZAP”. [8] Los clientes a veces explican el acrónimo de manera irónica como corrección temporal permanente o, de manera más práctica, probablemente esto corrige , porque tienen la opción de hacer que el PTF sea una parte permanente del sistema operativo si el parche corrige el problema.
Un parche de seguridad es un cambio que se aplica a un activo para corregir la debilidad descrita por una vulnerabilidad. Esta acción correctiva evitará la explotación exitosa y eliminará o mitigará la capacidad de una amenaza para explotar una vulnerabilidad específica en un activo. La gestión de parches es parte de la gestión de vulnerabilidades : la práctica cíclica de identificar, clasificar, remediar y mitigar vulnerabilidades.
Los parches de seguridad son el método principal para corregir vulnerabilidades de seguridad en el software. Actualmente, Microsoft publica sus parches de seguridad una vez al mes (" martes de parches "), y otros sistemas operativos y proyectos de software tienen equipos de seguridad dedicados a publicar los parches de software más confiables lo antes posible después del anuncio de una vulnerabilidad. Los parches de seguridad están estrechamente relacionados con la divulgación responsable .
Estos parches de seguridad son fundamentales para garantizar que los procesos empresariales no se vean afectados. En 2017, las empresas se vieron afectadas por un ransomware llamado WannaCry que encripta archivos en ciertas versiones de Microsoft Windows y exige un rescate a través de Bitcoin. En respuesta a esto, Microsoft lanzó un parche que detiene la ejecución del ransomware.
Un service pack o SP o feature pack (FP) comprende una colección de actualizaciones, correcciones o mejoras para un programa de software entregado en forma de un único paquete instalable. Las empresas suelen lanzar un service pack cuando el número de parches individuales para un programa determinado alcanza un límite determinado (arbitrario), o la versión del software ha demostrado estar estabilizada con un número limitado de problemas restantes según los comentarios de los usuarios y el seguimiento de errores como Bugzilla . En aplicaciones de software de gran tamaño, como suites ofimáticas, sistemas operativos, software de bases de datos o gestión de redes, no es raro que se publique un service pack dentro del primer año o dos desde el lanzamiento de un producto. Instalar un service pack es más fácil y menos propenso a errores que instalar muchos parches individuales, más aún cuando se actualizan varias computadoras a través de una red, donde los service packs son comunes.
Un parche no oficial es un parche para un programa escrito por un tercero en lugar del desarrollador original . De manera similar a un parche común, alivia errores o deficiencias. Algunos ejemplos son las correcciones de seguridad realizadas por especialistas en seguridad cuando un parche oficial realizado por los propios productores del software tarda demasiado. [9] [10] Otros ejemplos son los parches no oficiales creados por la comunidad de juegos de un videojuego que dejó de recibir soporte. [11] [12]
Parchear un programa significa extender o modificar un programa localmente (afectando solo la instancia en ejecución del programa).
La aplicación de parches en caliente , también conocida como aplicación de parches en vivo o actualización dinámica de software , es la aplicación de parches sin apagar y reiniciar el sistema o el programa en cuestión. Esto soluciona problemas relacionados con la falta de disponibilidad del servicio proporcionado por el sistema o el programa. [13] Se puede utilizar este método para actualizar el kernel de Linux sin detener el sistema. [14] [15] Un parche que se puede aplicar de esta manera se denomina parche en caliente o parche en vivo . Esto se está convirtiendo en una práctica común en el espacio de las aplicaciones móviles. [16] Empresas como Rollout.io utilizan el método swizzling para entregar parches en caliente al ecosistema iOS. [17] Otro método para aplicar parches en caliente a las aplicaciones iOS es JSPatch. [18]
Los proveedores de nube suelen utilizar parches en caliente para evitar tiempos de inactividad para los clientes cuando actualizan la infraestructura subyacente. [19]
En informática, la integración es el acto de integrar parches (incluidos los paquetes de servicio ) en los archivos de instalación de su aplicación original, de modo que el resultado permita una instalación directa de la aplicación actualizada. [20] [21]
La naturaleza de la instalación integrada implica que implica una inversión inicial de tiempo y trabajo, pero puede ahorrar mucho tiempo (y, por extensión, dinero) a largo plazo. Esto es especialmente importante para los administradores que tienen la tarea de gestionar una gran cantidad de computadoras, donde la práctica típica para instalar un sistema operativo en cada computadora sería utilizar el medio original y luego actualizar cada computadora una vez que se completa la instalación. Esto llevaría mucho más tiempo que comenzar con una fuente más actualizada (instalada integrada) y necesitar descargar e instalar las pocas actualizaciones que no están incluidas en la fuente instalada integrada.
Sin embargo, no todos los parches se pueden aplicar de esta manera y una desventaja es que si se descubre que un determinado parche es responsable de problemas posteriores, dicho parche no se puede eliminar sin utilizar una fuente de instalación original y no incorporada.
Los sistemas de actualización de software permiten que los usuarios y los desarrolladores de software administren las actualizaciones. En la ciberpandemia de Petya de 2017 , se dice que el sistema de actualización del software financiero "MeDoc" se vio comprometido para propagar malware a través de sus actualizaciones. [22] [23] En el blog de Tor, el experto en ciberseguridad Mike Perry afirma que las compilaciones deterministas y distribuidas son probablemente la única forma de defenderse contra el malware que ataca los procesos de desarrollo y compilación de software para infectar millones de máquinas en una única actualización instantánea firmada oficialmente. [24] Los administradores de actualizaciones también permiten que las actualizaciones de seguridad se apliquen de forma rápida y amplia. Los administradores de actualizaciones de Linux como Synaptic permiten a los usuarios actualizar todo el software instalado en su máquina. Las aplicaciones como Synaptic utilizan sumas de comprobación criptográficas para verificar los archivos de origen/locales antes de que se apliquen para garantizar la fidelidad contra el malware. [25] [26]
Desinstalar el parche del controlador de audio de alta definición KB835221 y KB888111 [...]
{{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )Se ha lanzado otro parche no oficial para contrarrestar una falla crítica en el navegador Internet Explorer de Microsoft.
...] Los fanáticos de la trilogía Myth han llevado esta idea un paso más allá: tienen acceso oficial al código fuente de los juegos Myth. Organizado bajo el nombre de MythDevelopers, este grupo de programadores, artistas y otras personas talentosas, formado exclusivamente por voluntarios, dedica su tiempo a mejorar y apoyar el desarrollo de la serie de juegos Myth.
...] que no habría más parches para el título. Como era de esperar, la comunidad estaba molesta. En lugar de darse por vencida con el juego, los usuarios decidieron que si Activision no iba a arreglar los errores, lo harían ellos. Querían salvar el juego haciendo que Activision abriera el código fuente para que pudiera mantenerse vivo más allá del punto en que Activision perdiera el interés. Con algo de ayuda de los miembros del equipo de desarrollo que eran activos en los foros de fans, finalmente pudieron convencer a Activision de que publicara el código fuente de Call to Power II en octubre de 2003.