¿Es el código fuente cerrado más seguro que el código abierto?

"El diseño seguro, la auditoría del código fuente, los desarrolladores de calidad, el proceso de diseño y otros factores, todos juegan en la seguridad de un proyecto, y ninguno de estos está directamente relacionado con que un proyecto sea de código abierto o cerrado ".

Fuente : código abierto versus seguridad de código cerrado

El hecho de que el software sea de código abierto no significa que cualquiera pueda cambiarlo (a menudo, cualquiera puede bifurcarlo , pero ese será un nuevo software derivado): solo las personas dedicadas tienen acceso al repositorio. Por ejemplo, si quiero enviar un cambio a Tortoise SVN , tengo que enviar mi cambio por correo a una lista de correo dedicada y luego los desarrolladores lo verán, lo revisarán y lo confirmarán en la base de código. ^{1 , 2}

Aún así, cualquiera puede leer las fuentes. Eso tampoco es gran cosa. Mire la criptografía contemporánea. Los algoritmos son públicos e investigados y probados por numerosas personas. ¿Cómo se pueden utilizar para proteger los datos? Utilizan pequeñas porciones de datos secretos (claves de cifrado) para parametrizar el algoritmo. Todos conocen el algoritmo , pero solo las personas que necesitan conocer las claves secretas y los algoritmos se utilizan con éxito para la protección de datos.

Dicho esto, el software de código abierto y el software seguro (o confiable) son completamente independientes: compararlos es como comparar manzanas con naranjas. Sí, el software de código abierto puede tener errores. Lo mismo ocurre con el software de código cerrado. Es cómo se organiza el proceso de desarrollo, no si divulgas las fuentes.

Referencias:

¹

Envíe parches (¡envíe los suficientes y podrá convertirse en un commiter!)

² (ligeramente modificado)

Técnicamente, un committer es alguien que tiene acceso de escritura al repositorio SVN. Un committer puede enviar sus propios parches o parches de otros.

No voy a responder a esta pregunta yo mismo. El Departamento de Defensa de los Estados Unidos lo ha hecho mucho mejor que yo.

P: ¿Ocultar el código fuente no hace que el software sea automáticamente más seguro?

No. De hecho, las bases de datos de vulnerabilidades como CVE dejan claro que simplemente ocultar el código fuente no contrarresta los ataques:

• Los ataques dinámicos (p. ej., generar patrones de entrada para detectar vulnerabilidades y luego enviar esos datos al programa para ejecutarlos) no necesitan código fuente ni binario. Observar la salida de las entradas suele ser suficiente para el ataque.

• Los ataques estáticos (p. ej., analizar el código en lugar de su ejecución) pueden utilizar coincidencias de patrones con binarios; tampoco se necesita el código fuente para ellos.

• Incluso si el código fuente es necesario (por ejemplo, para los analizadores de código fuente), los desensambladores y descompiladores a menudo pueden regenerar el código fuente adecuado para buscar vulnerabilidades. Dicho código fuente puede no ser adecuado para mantener el software de manera rentable, pero los atacantes no necesitan mantener el software.

• Incluso cuando la fuente original es necesaria para un análisis en profundidad, poner el código fuente a disposición del público ayuda significativamente a los defensores y no solo a los atacantes. La revisión por pares continua y amplia, habilitada por el código fuente disponible públicamente, mejora la confiabilidad y la seguridad del software a través de la identificación y eliminación de defectos que, de otro modo, podrían pasar desapercibidos por el equipo central de desarrollo. Por el contrario, cuando el código fuente está oculto al público, los atacantes pueden atacar el software de todos modos como se describe anteriormente. Además, un atacante a menudo puede adquirir el código fuente original de los proveedores de todos modos (ya sea porque el proveedor lo proporciona voluntariamente o mediante ataques contra el proveedor); en tales casos, si solo el atacante tiene el código fuente, el atacante obtiene otra ventaja.

Ocultar el código fuente inhibe la capacidad de terceros para responder a las vulnerabilidades (porque cambiar el software es más difícil sin el código fuente), pero obviamente esto no es una ventaja de seguridad. En general, la “Seguridad por Oscuridad” es ampliamente denigrada.

Esto no significa que el DoD rechazará el uso de productos COTS patentados. Existen razones comerciales válidas, no relacionadas con la seguridad, que pueden llevar a una empresa comercial que vende software propietario a optar por ocultar el código fuente (por ejemplo, para reducir el riesgo de infracción de derechos de autor o la revelación de secretos comerciales). Lo que sí significa, sin embargo, es que el DoD no rechazará la consideración de un producto COTS simplemente porque es OSS. Algunos OSS son muy seguros, mientras que otros no lo son; algunos programas propietarios son muy seguros, mientras que otros no lo son. Cada producto debe ser examinado por sus propios méritos.

Editar para agregar: también hay una respuesta a la pregunta de inserción de código malicioso:

P: ¿Existe el riesgo de que se incruste un código malicioso en el OSS?

El uso de cualquier software disponible comercialmente, ya sea propietario o OSS, crea el riesgo de ejecutar un código malicioso incrustado en el software. Incluso si un programa comercial no tenía vulnerabilidades originalmente, los archivos binarios de los programas propietarios y OSS pueden modificarse (por ejemplo, con un "editor hexadecimal" o virus) para que incluya código malicioso. Puede que sea ilegal modificar el software propietario, pero eso normalmente no ralentizará a un atacante. Afortunadamente, existen formas de reducir el riesgo de ejecutar código malicioso cuando se utiliza software comercial (tanto propietario como OSS). Es imposible eliminar por completo todos los riesgos; en su lugar, concéntrese en reducir los riesgos a niveles aceptables.

El uso de software con una licencia propietaria no garantiza en absoluto que el software esté libre de código malicioso. De hecho, muchas personas han lanzado código propietario que es malicioso. Además, las prácticas de lanzamiento de software propietario hacen que sea más difícil estar seguro de que el software no incluye código malicioso. Dicho software normalmente no se somete a una revisión pública generalizada; de hecho, el código fuente generalmente no se proporciona al público y, a menudo, hay cláusulas de licencia que intentan inhibir una revisión adicional (por ejemplo, prohibir la ingeniería inversa y/o prohibir la divulgación pública de los resultados del análisis). ). Por lo tanto, para reducir el riesgo de ejecutar código malicioso, los usuarios potenciales deben considerar la reputación del proveedor y la experiencia de otros usuarios, preferir software con una gran cantidad de usuarios, y asegúrese de que obtengan el software "real" y no un imitador. Cuando sea importante, también puede ser conveniente examinar la postura de seguridad del proveedor (por ejemplo, sus procesos que reducen el riesgo) y escanear/probar/evaluar el software.

Del mismo modo, el OSS (así como el software propietario) puede tener incrustado un código malicioso. Sin embargo, dicho código malicioso no puede ser insertado directamente por "cualquiera" en un proyecto OSS bien establecido. Como se indicó anteriormente, los proyectos OSS tienen un "repositorio de confianza" que solo ciertos desarrolladores (los "desarrolladores de confianza") pueden modificar directamente. Además, dado que el código fuente se publica públicamente, cualquiera puede revisarlo, incluso por la posibilidad de código malicioso. El lanzamiento público también facilita tener copias de las versiones en muchos lugares y comparar esas versiones, lo que facilita que muchas personas revisen los cambios. Muchos perciben esta apertura como una ventaja para OSS, ya que OSS cumple mejor con el "principio de diseño abierto" de Saltzer & Schroeder ("

Al igual que con el software propietario, para reducir el riesgo de ejecutar código malicioso, los usuarios potenciales deben tener en cuenta la reputación del proveedor (el proyecto OSS) y la experiencia de otros usuarios, preferir el software con una gran cantidad de usuarios y asegurarse de que obtienen la software "real" y no un imitador (por ejemplo, del sitio principal del proyecto o de un distribuidor de confianza). Cuando sea importante, también puede ser conveniente examinar la postura de seguridad del proveedor (el proyecto OSS) y escanear/probar/evaluar el software. El ejemplo de InterBase/Firebird de Borland es instructivo. Durante al menos 7 años, Interbase de Borland (un programa de base de datos patentado) había incorporado una "puerta trasera"; el nombre de usuario "políticamente", la contraseña "correcta", daría inmediatamente al solicitante el control total sobre la base de datos, un hecho desconocido para sus usuarios. Ya sea que esto fuera intencional o no, ciertamente tenía la misma forma que una puerta trasera maliciosa. Cuando el programa se lanzó como OSS, en 5 meses se encontró y solucionó esta vulnerabilidad. Esto demuestra que el software propietario puede incluir funcionalidades que podrían describirse como maliciosas y, sin embargo, permanecer sin reparar, y que al menos en algunos casos el OSS se revisa y repara.

Tenga en cuenta que el mero hecho de estar desarrollado para el gobierno no garantiza que no haya código incrustado malicioso. Dichos desarrolladores no necesitan ser autorizados, por ejemplo. Requerir que todos los desarrolladores sean aprobados primero puede reducir ciertos riesgos (a costos sustanciales), cuando sea necesario, pero incluso así no hay garantía.

Tenga en cuenta que la mayoría del software comercial no está diseñado para usarse donde el impacto de cualquier error de cualquier tipo sea extremadamente alto (por ejemplo, es probable que se pierda inmediatamente una gran cantidad de vidas si ocurre el más mínimo error de software). El software que cumple con requisitos muy altos de confiabilidad/seguridad, también conocido como software de "alta garantía", debe diseñarse especialmente para cumplir con dichos requisitos. La mayoría del software comercial (incluido el OSS) no está diseñado para tales fines.

En 2002, Payne realizó un estudio comparando tres sistemas operativos similares a Unix, uno de los cuales era de código cerrado (Solaris) y dos de los cuales eran de código abierto (Debian y OpenBSD) a través de una serie de métricas de seguridad. Él concluye:

Los resultados muestran que, de los tres sistemas, OpenBSD tenía la mayor cantidad de funciones de seguridad (18), con Debian en segundo lugar (15) y Solaris en tercero (11). De estas funciones, las funciones de OpenBSD obtuvieron la puntuación más alta con 7,03 sobre 10, mientras que las de Debian obtuvieron un 6,42 y las de Solaris un 5,92. Se observó un patrón similar para las vulnerabilidades, con OpenBSD teniendo la menor cantidad (5).
...
Con base en estos resultados, parecería que los sistemas de código abierto tienden a ser más seguros, sin embargo, ... con una puntuación de 10.2, OpenBSD fue el único sistema del árbol que recibió una puntuación positiva y, en comparación con las magnitudes de los otros dos puntuaciones sugiere que esta también es una puntuación relativamente alta. Por lo tanto, las diferencias significativas entre la puntuación de Debian y OpenBSD respaldan el argumento de que hacer un programa de 'código abierto' no mejora automáticamente, por sí mismo, la seguridad del programa (Levy, 2000), (Viega, 2000). ¿Qué explica, por lo tanto, la seguridad espectacularmente mejor exhibida por el sistema OpenBSD sobre los otros dos? El autor cree que la respuesta a esta pregunta radica en el hecho de que, si bien el código fuente del sistema Debian está disponible para cualquiera que quiera examinarlo, el código fuente de OpenBSD se examina de manera regular y deliberada con la intención explícita de encontrar y corregir agujeros de seguridad (Payne, 1999), (Payne, 2000). Por lo tanto, es este trabajo de auditoría, más que simplemente la disponibilidad general del código fuente, el responsable del bajo número de problemas de seguridad de OpenBSD.

Editar: para resumir, Payne explica sus resultados afirmando que es la cultura de la seguridad en sí misma la que promueve la seguridad real. Si bien es probable que eso sea cierto, creo que también es importante tener en cuenta que, en igualdad de condiciones, el público en general no puede auditar de forma independiente lo que no está abierto.

Sin embargo, ese estudio está un poco anticuado y tiene una amplitud limitada.

Traté de buscar un estudio más completo, pero realmente no pude encontrar nada sustantivo (hay muchos "artículos de opinión" que dan argumentos sobre por qué el código abierto es mejor, pero no muchos datos). Por lo tanto, eché un vistazo rápido a la base de datos nacional de vulnerabilidades , que recopila, clasifica y publica vulnerabilidades de software. Tiene una base de datos que data de la década de 1980. Rápidamente compuse este script de perl para analizar la base de datos:

#!/usr/bin/perl -w
use Cwd 'abs_path';
use File::Basename;
use XML::Parser;
my @csseverity;my @osseverity;my @bothseverity;
my $numNeither = 0;
sub mean {
  my $result; return 0 if(@_ <= 0); foreach (@_) { $result += $_ } return $result / @_;
}
sub stddev {
  my $mean = mean(@_); my @elem_squared; foreach (@_) { push (@elem_squared, ($_ **2));     }
  return sqrt( mean(@elem_squared) - ($mean ** 2));
}
sub handle_start {
    if($_[1] eq "entry") {
        $item = {};
        undef($next) if(defined($next));
        for(my $i=2; $i<@_; $i++) {
            if(!defined($key)) {
                $key = $_[$i];
            } else {
                $item->{$key} = $_[$i];
                undef($key);
            }
        }
    } elsif(defined($item)) {
        $next = $_[1];
    }
}
sub handle_end {
    if($_[1] eq "entry") {
        if(!exists($item->{'reject'}) || $item->{'reject'} != 1) {
            my $score = $item->{'CVSS_score'};
            my $d = $item->{"descript"};
            my $isOS = 0;
            my $isCS = 0;
            $isOS = 1 if($d =~ m/(^|\W)(linux|nfs|openssl|(net|open|free)?bsd|netscape|red hat|lynx|apache|mozilla|perl|x windowing|xlock|php|w(u|f)-?ftpd|sendmail|ghostscript|gnu|slackware|postfix|vim|bind|kde|mysql|squirrelmail|ssh-agent|formmail|sshd|suse|hsftp|xfree86|Mutt|mpg321|cups|tightvnc|pam|bugzilla|mediawiki|tor|piwiki|ruby|chromium|open source)(\W|$)/i);
            $isCS = 1 if($d =~ m/(^|\W)(windows|tooltalk|solaris|sun|microsoft|apple|macintosh|sybergen|mac\s*os|mcafee|irix|iis|sgi|internet explorer|ntmail|sco|cisco(secure)?|aix|samba|sunos|novell|dell|netware|outlook|hp(-?ux)?|iplanet|flash|aol instant|aim|digital|compaq|tru64|wingate|activex|ichat|remote access service|qnx|mantis|veritas|chrome|3com|vax|vms|alcatel|xeneo|msql|unixware|symantec|oracle|realone|real\s*networks|realserver|realmedia|ibm|websphere|coldfusion|dg\/ux|synaesthesia|helix|check point|proofpoint|martinicreations|webfort|vmware)(\W|$)/i);
            if($isOS && $isCS) {
                push(@bothseverity, $score);
            } elsif($isOS) {
                push(@osseverity, $score);
            } elsif($isCS) {
                push(@csseverity, $score);
            } else {
                $numNeither++;
                #print $d . "\n";
            }
        }
        undef($item);
    }
}
sub handle_char {
    $item->{$next} = $_[1] if(defined($item) && defined($next));
    undef($next) if(defined($next));
}
my($scriptfile, $scriptdir) = fileparse(abs_path($0));
sub process_year {
    my $filename = 'nvdcve-' . $_[0] . '.xml';
    system("cd $scriptdir ; wget http://nvd.nist.gov/download/" . $filename) unless(-e $scriptdir . $filename);
    $p = new XML::Parser(Handlers => {Start => \&handle_start,
                                      End   => \&handle_end,
                                      Char  => \&handle_char});
    $p->parsefile($filename);
}
my($sec,$min,$hour,$mday,$mon,$currentyear,$wday,$yday,$isdst) = localtime(time);
$currentyear += 1900;
for(my $year=2002; $year<=$currentyear; $year++) {
    &process_year($year);
}
print "Total vulnerabilities: " . (@osseverity + @csseverity + @bothseverity + $numNeither) . "\n";
print "\t  # Open Source (OS): " . @osseverity . "\n";
print "\t# Closed Source (OS): " . @csseverity . "\n";
print "\t              # Both: " . @bothseverity . "\n";
print "\t      # Unclassified: " . $numNeither . "\n";
print "OS Severity: " . &mean(@osseverity) . "\t" . &stddev(@osseverity) . "\n";
print "CS Severity: " . &mean(@csseverity) . "\t" . &stddev(@csseverity) . "\n";
print "Both Severity: " . &mean(@bothseverity) . "\t" . &stddev(@bothseverity) . "\n";

Siéntase libre de modificar el código, si lo desea. Aquí están los resultados:

La base de datos completa tiene 46102 vulnerabilidades. Mi secuencia de comandos pudo clasificar 15748 de ellos como específicamente relacionados con el software de código abierto, 11430 estaban relacionados con el software de código cerrado, 782 eran aplicables tanto al software de código abierto como al de código cerrado, y 18142 no estaban clasificados (no tuve tiempo para optimizar mucho mi clasificador; siéntete libre de mejorarlo). Entre las vulnerabilidades que se clasificaron, las de código abierto tuvieron una severidad promedio de 6.24 con una desviación estándar de 1.74 (a mayor severidad es peor). Las vulnerabilidades de fuente cerrada tenían una gravedad promedio de 6,65 (stddev = 2,21). Las vulnerabilidades que se clasificaron como ambas tenían una gravedad media de 6,47 (stddev = 2,13). Sin embargo, puede que esta no sea una comparación completamente justa, ya que el software de código abierto se ha vuelto mucho más popular en los últimos años.

• Vulnerabilidades totales: 39445
• # Código abierto (SO): 14595
• # Fuente cerrada (CS): 9293
• # Ambos: 675
• # Sin clasificar: 14882
• Promedio Gravedad del SO: 6.25 (stddev 1.70)
• Promedio CS Gravedad: 6.79 (stddev 2.24)
• Ambos Gravedad: 6,52 (stddev 2,15)

No he tenido tiempo de hacer ningún análisis estadístico de estos resultados; sin embargo, parece que, en promedio, las vulnerabilidades que afectan al software de código abierto tienen una clasificación de gravedad ligeramente menor que las vulnerabilidades que afectan al software de código cerrado.

Cuando tenga más tiempo, intentaré generar un gráfico del promedio móvil de gravedad a lo largo del tiempo.

Mi profesor de informática nos dijo que el software de código cerrado es más seguro que el software de código abierto, porque con el código abierto "cualquiera puede modificarlo y ponerle cosas".

Tu profesor está completamente equivocado. La afirmación correcta es:

cualquiera puede bifurcarlo y poner cosas en su tenedor .

Código abierto significa que cualquiera puede leer el código fuente correspondiente al binario distribuido. Por lo general, también significa que cualquiera puede leer desde el repositorio principal donde ocurre el desarrollo, para probar nuevos cambios inéditos. FreePascal sigue este patrón general: "Como alternativa a los archivos zip diarios de las fuentes SVN, el repositorio SVN se ha hecho accesible para todos, con acceso de solo lectura".

No requiere que el público en general pueda escribir en el repositorio principal; de hecho, la norma general es que el acceso de escritura se limite a los miembros del proyecto de confianza. En algunos casos, el repositorio acepta parches de cualquier persona, pero se ponen en cuarentena en ramas separadas hasta que un miembro de confianza combine el cambio en la base de código maestra (troncal). Parece que FreePascal sigue este último modelo, solo necesita una cuenta gratuita para cargar parches, pero no se integrarán en la línea principal sin revisión.

Pídele a tu maestro que respalde sus palabras con acciones: tienes FreePascal instalado en tu computadora, si cree que es "inseguro", pídele que "modifique y coloque" un mensaje insultante que aparecerá la próxima vez que lo ejecutes. No sucederá, existe un gran abismo entre la copia modificada en su directorio de inicio y la versión que descargas y compilas en tu computadora.

Su oración final, que solicita estudios que realicen una comparación estadística de código abierto frente a código cerrado, muestra que ha adoptado una de las malas prácticas de su maestro: la falacia de aplicar la ley de los promedios a un individuo.

Considero que la utilidad para usted de dibujar software de una categoría que es más segura en promedio es esencialmente nula. Debería estar interesado en cambio en los programas que son individual y específicamente altamente seguros, sin importar las características que compartan con el software inseguro.

Creo que John proporciona la mejor respuesta cuando dice que muchos otros factores pueden influir en la seguridad. Sin embargo, vale la pena ver cómo la apertura puede afectar la seguridad.

El primer trabajo en esta dirección fue en 1883 por Auguste Kerckhoffs y se llama Principio de Kerckhoffs . Argumentó que para que cualquier sistema sea seguro:

Un criptosistema debe ser seguro incluso si todo lo relacionado con el sistema, excepto la clave, es de conocimiento público.

Una interpretación importante del Arte de la Seguridad de la Información ,

El Principio de Kerckhoff no requiere que publiquemos o divulguemos cómo funcionan las cosas. Requiere que la seguridad del sistema no se vea afectada negativamente por tal divulgación.

La mayoría de los sistemas de código cerrado en realidad no violan el principio de Kerckhoff, por lo que no se puede decir que el código abierto sea inferior o superior al código cerrado según esta medida.

A menudo se utilizan dos modelos con respecto al software Seguridad a través de la oscuridad frente a Seguridad a través de la divulgación/apertura. Los argumentos a favor y en contra de ellos se repiten en wikipedia .

Estadísticamente, Linux sufre una tasa de infección mucho más baja que Windows. Esto generalmente se atribuye al modelo de código abierto, pero también se proponen como explicación otras razones alternativas (como una menor participación de mercado). Firefox también afirma tener un número menor de vulnerabilidades de seguridad abiertas que Internet Explorer.

Sin embargo, debe tenerse en cuenta que más ojos, menos errores solo funciona para el software popular de código abierto y puede no ser viable para el software menos popular o personalizado.

Un examen superficial de las controversias en las secciones semanales del kernel en Linux Weekly News[1] muestra cuán difícil suele ser para los desarrolladores extremadamente experimentados con una gran reputación convertir su código en proyectos de buena reputación. Si está descargando desde un proyecto o distribución que tiene estándares y los aplica en las listas de correo públicas, puede tomar una decisión más informada sobre la confiabilidad y confiabilidad del código que si está comprando software propietario de compañías con procesos desconocidos cuyos prácticas de desarrollo que no se pueden examinar. Si está descargando desde Will's World of Warez, está en problemas, independientemente del modelo de desarrollo.

[1]: http://lwn.net/ Noticias semanales de Linux. Las ediciones semanales que no sean la última son gratuitas para los no suscriptores.

Como he señalado en los comentarios, se presenta un análisis completo y razonado en Sistemas de código abierto frente a sistemas de código cerrado .

Sin embargo, por el bien del argumento, presentaré un solo ejemplo como evidencia: el primer rootkit real, y aparentemente el más extendido, estaba en un paquete de código abierto muy popular.

De la historia de Rootkit (Wikipedia) :

Ken Thompson de Bell Labs, uno de los creadores de Unix, subvirtió el compilador C en una distribución de Unix y discutió el exploit en la conferencia que dio al recibir el premio Turing en 1983. El compilador modificado detectaría los intentos de compilar el Unix "iniciar sesión " y generar un código alterado que aceptaría no solo la contraseña correcta del usuario, sino también una contraseña adicional conocida por el atacante. Además, el compilador detectaría los intentos de compilar una nueva versión del compilador e insertaría las mismas vulnerabilidades en el nuevo compilador. Una revisión del código fuente para el comando "iniciar sesión" o el compilador actualizado no revelaría ningún código malicioso.

Referencia: http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

En resumen, las propias palabras de Ken de ese documento:

La moraleja es obvia. No puedes confiar en un código que no creaste totalmente tú mismo. Ninguna cantidad de verificación o escrutinio a nivel de fuente lo protegerá del uso de código no confiable.

El código abierto no te ayudaría aquí.
De hecho, insistir en la seguridad inherente al código abierto es irrelevante.

Otro punto que aún no se ha cubierto, pero que va en la misma dirección que la mayoría de las respuestas:

Incluso sin la fuente, en muchos entornos, puede colocar una serie de saltos al comienzo de un binario ejecutable para ir a un lugar donde ha compilado su propio software y luego reanudar el funcionamiento normal del código.

De Wikipedia :

Luego, el binario se modifica utilizando el depurador o un editor hexadecimal de una manera que reemplaza un código de operación de bifurcación anterior con su complemento o un código de operación NOP, por lo que la bifurcación clave siempre ejecutará una subrutina específica o la omitirá. Casi todos los cracks de software comunes son una variación de este tipo.

Por supuesto, dado que esto es lo que hacen muchos virus y versiones descifradas de software comercial, las utilidades antivirus pueden detectarlo como sospechoso o bloquearlo debido a las verificaciones de suma de comprobación realizadas por el propio código, el cargador/enlazador, el sistema operativo, etc.