Por que o governo dos EUA proíbe idiomas dinâmicos para projetos seguros?

120

Conheço algumas pessoas que estão atualmente trabalhando em um projeto para as forças armadas dos EUA (baixo nível de segurança, dados do tipo recursos humanos que não são de combate).

Um estado inicial do código do projeto foi submetido aos militares para revisão e eles executaram o programa através de algum tipo de ferramenta de análise de segurança. Ele retornou um relatório de problemas de segurança conhecidos no código e exigiu alterações que precisavam ser implementadas antes da entrega do produto final.

Um dos itens que precisavam ser resolvidos foi a remoção de parte do projeto que foi escrito em Ruby por ser uma linguagem dinâmica.

Qual é o motivo / motivo para não permitir que um idioma dinâmico seja usado em um ambiente seguro? O governo está demorando para adotar novas tecnologias? Ou as linguagens dinâmicas representam um risco adicional à segurança em comparação às linguagens estáticas (ala C ++ ou Java )?

Patrick
fonte
56
A única maneira de saber com certeza é se seus conhecidos perguntam aos empregadores o motivo. Mas posso arriscar um palpite: a verificação de tipo estático é outra camada que ajuda na correção de software de missão crítica. É claro que não vai se livrar de bugs, mas é um passo na direção certa: o computador está fazendo parte do trabalho para você. (Sim, eu sei que este é um território de guerras sagradas).
Andres F.
4
Possivelmente relevante: williamedwardscoder.tumblr.com/post/42912076785/…
Robert Harvey
75
Você não deseja software de controle de mísseis gravado em PHP + JavaScript.
Tulains Córdova
16
Os dados de RH não são "baixo nível de segurança". Eu esperava que uma empresa mantivesse meu emprego e dados pessoais o mais seguro possível.
gbjbaanb
5
@gbjbaanb Acho que o OP significou que a perda de vidas não é o pior cenário aqui.
Andres F.

Respostas:

126

Há várias coisas "legais" que podem ser feitas em linguagens dinâmicas que podem ser escondidas em partes do código que não são imediatamente óbvias para outro programador ou auditor quanto à funcionalidade de um determinado pedaço de código.

Considere esta sequência no irb (ruby shell interativo):

irb(main):001:0> "bar".foo
NoMethodError: undefined method `foo' for "bar":String
        from (irb):1
        from /usr/bin/irb:12:in `<main>'
irb(main):002:0> class String
irb(main):003:1> def foo
irb(main):004:2> "foobar!"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> "bar".foo
=> "foobar!"

O que aconteceu lá é que tentei chamar o método fooem uma constante String. Isso falhou. Abri a classe String e defini o método fooo return "foobar!"e, em seguida, o chamei. Isso funcionou.

Isso é conhecido como classe aberta e me dá pesadelos toda vez que penso em escrever código em ruby ​​que tenha qualquer tipo de segurança ou integridade. Claro que isso permite que você faça algumas coisas legais bem rápido ... mas eu poderia fazer isso toda vez que alguém armazenasse uma string, a armazenasse em um arquivo ou a enviasse pela rede. E esse pequeno pedaço de redefinição da String pode ser colocado em qualquer lugar do código.

Muitas outras linguagens dinâmicas têm coisas semelhantes que podem ser feitas. O Perl tem o Tie :: Scalar que pode nos bastidores mudar o funcionamento de um determinado escalar (isso é um pouco mais óbvio e requer um comando específico que você pode ver, mas um escalar que é passado de outro lugar pode ser um problema). Se você tiver acesso ao Perl Cookbook, procure a Receita 13.15 - Criando variáveis ​​mágicas com gravata.

Devido a essas coisas (e outras geralmente fazem parte de linguagens dinâmicas), muitas abordagens para a análise estática da segurança no código não funcionam. Perl e Indecidibilidade mostram que esse é o caso e apontam até esses problemas triviais com destaque da sintaxe ( whatever / 25 ; # / ; die "this dies!";apresenta desafios porque whateverpodem ser definidos para receber argumentos ou não em tempo de execução, derrotando completamente um marca-texto ou analisador estático da sintaxe).


Isso pode se tornar ainda mais interessante no Ruby com a capacidade de acessar o ambiente em que um fechamento foi definido (consulte YouTube: Mantendo o Ruby Reasonable from RubyConf 2011 por Joshua Ballanco). Fui informado deste vídeo de um comentário da Ars Technica por MouseTheLuckyDog .

Considere o seguinte código:

def mal(&block)
    puts ">:)"
    block.call
    t = block.binding.eval('(self.methods - Object.methods).sample')
    block.binding.eval <<-END
        def #{t.to_s}
          raise 'MWHWAHAW!'
        end
    END
end

class Foo
    def bar
        puts "bar"
    end

    def qux
        mal do
            puts "qux"
        end
    end
end

f = Foo.new
f.bar
f.qux

f.bar
f.qux

Este código é totalmente visível, mas o malmétodo pode estar em outro lugar ... e com classes abertas, é claro, pode ser redefinido em outro lugar.

Executando este código:

~ / $ ruby ​​foo.rb 
Barra
> :)
qux
Barra
b.rb: 20: em `qux ': MWHWAHAW! (RuntimeError)
    de b.rb: 30: em ''
~ / $ ruby ​​foo.rb 
Barra
> :)
qux
b.rb: 20: no `bar ': MWHWAHAW! (RuntimeError)
    de b.rb: 29: em ''

Nesse código, o fechamento pôde acessar todos os métodos e outras ligações definidas na classe nesse escopo. Ele escolheu um método aleatório e o redefiniu para gerar uma exceção. (veja a classe Binding no Ruby para ter uma ideia do que esse objeto tem acesso)

As variáveis, métodos, valor de si próprio e, possivelmente, um bloco iterador que pode ser acessado nesse contexto são mantidos.

Uma versão mais curta que mostra a redefinição de uma variável:

def mal(&block)
    block.call
    block.binding.eval('a = 43')
end

a = 42
puts a
mal do 
  puts 1
end
puts a

Que, quando executado, produz:

42.
1
43

Isso é mais do que a classe aberta que mencionei acima, que torna impossível a análise estática. O que foi demonstrado acima é que um fechamento que é passado em outro lugar leva consigo o ambiente completo em que foi definido. Isso é conhecido como ambiente de primeira classe (assim como quando você pode passar funções, elas são funções de primeira classe, este é o ambiente e todas as ligações disponíveis naquele momento). Pode-se redefinir qualquer variável definida no escopo do fechamento.

Bom ou mau, queixando-se de rubi ou não (há usos onde se poderia desejar para ser capaz de chegar ao ambiente de um método (ver Seguro em Perl)), a questão do "por que rubi ser restringida em um projeto do governo "realmente é respondido no vídeo vinculado acima.

Dado que:

  1. Ruby permite extrair o ambiente de qualquer fechamento
  2. O Ruby captura todas as ligações no escopo do fechamento
  3. O Ruby mantém todas as ligações como ativas e mutáveis
  4. O Ruby tem novas ligações que ocultam as antigas (em vez de clonar o ambiente ou proibir a religação)

Com as implicações dessas quatro opções de design, é impossível saber o que qualquer parte do código faz.

Mais sobre isso pode ser lido no blog Abstract Heresies . O post em particular é sobre o Scheme em que esse debate foi realizado. (relacionado com SO: por que o Scheme não suporta ambientes de primeira classe? )

Com o tempo, porém, percebi que havia mais dificuldade e menos energia nos ambientes de primeira classe do que eu pensava originalmente. Neste ponto, acredito que os ambientes de primeira classe são inúteis, na melhor das hipóteses, e perigosos, na pior das hipóteses.

Espero que esta seção mostre o aspecto de perigo dos ambientes de primeira classe e por que seria solicitado a remover o Ruby da solução fornecida. Não é apenas porque Ruby é uma linguagem dinâmica (como mencionado em outras respostas, outras linguagens dinâmicas foram permitidas em outros projetos), mas também por questões específicas que tornam ainda mais difícil pensar em algumas linguagens dinâmicas.

Comunidade
fonte
3
Eu não entendo o objetivo disso. Você menciona uma classe Perl que permite alterar o comportamento dos escalares. No entanto, o Perl é amplamente usado, inclusive em ambientes seguros. Simplesmente ter esses recursos no idioma não significa que o idioma não possa ser usado. No caso específico de Ruby, é provável que o ambiente de destino não suporte Ruby. Pessoalmente, nunca vi o Ruby disponível para uso em nenhum sistema e nem tenho certeza se ele está em alguma lista de softwares aprovados.
Thomas Owens
17
@ThomasOwens - Meu entendimento desta resposta é que a chave é "many approaches to static analysis of security in code doesn't work", então ela é rejeitada porque não pode ser analisada (por este grupo, pelo menos). Se estou interpretando direito ou se é mesmo um motivo válido para rejeitá-lo, não sei.
22413 Bobson
21
Na falta de informações nas listas de softwares aprovados, só posso adivinhar as dificuldades com linguagens dinâmicas. No entanto, vi problemas semelhantes no software financeiro e nas verificações do setor de cartões de pagamento, porque o idioma não podia ter uma análise estática pré-formada para problemas de segurança. Demonstrei dois exemplos em linguagens dinâmicas em que a natureza da linguagem permite subverter a análise estática. Também indiquei por que isso, mesmo teoricamente, nunca pode ser preciso. Pode ser que o perl seja permitido em alguns lugares e não em outros, só posso adivinhar os motivos.
2
Você também pode redefinir as funções padrão da biblioteca em muitos outros idiomas (por exemplo, Obj-C, C, C ++).
Martin Wickman
12
Bem, os métodos de extensão .NET NÃO são os mesmos do Ruby acima. Eles apenas criam uma maneira mais fácil de digitar uma classe estática. Na verdade, eles não adicionam um método a uma classe.
Graham
50

Supondo que a avaliação era apenas de segurança, e não apenas uma verificação de aceitação (ou seja, eles não aceitam Ruby porque não desejam dar suporte a Ruby), então:

As ferramentas de análise de segurança normalmente passam mal com comportamentos dinâmicos.

Por exemplo:

Execute qualquer projeto .NET escrito com recursos modernos como ASP.NET MVC e Entity Framework através de algo como Veracode e veja que tipo de lista de lavanderia de falsos positivos você recebe em seu relatório.

A Veracode até lista muitas técnicas básicas nas bibliotecas principais do .NET 4 como "estruturas não suportadas" como não suportadas ou beta apenas, embora a maioria delas tenha vários anos de idade neste momento.

Se você estiver lidando com uma entidade que depende fortemente de tal ferramenta, elas são quase forçadas a considerá-las inseguras se não tiverem o conhecimento técnico e os recursos para avaliar manualmente um projeto e verificar se ele está escrito e seguro.

Nas operações civis em que os sistemas de computador geralmente não controlam nada perigoso ou terrivelmente caro, a atenuação é que você discute os falsos positivos e eles geralmente são aceitos como tal em massa.

Nas operações bancárias, você ainda tem uma chance de uma mitigação de falsos positivos, mas gastará muito mais tempo discutindo as minúcias de cada item. Isso rapidamente se torna proibitivo em termos de custos e você começa a usar métodos mais tradicionais.

Nas forças armadas, na aviação, na indústria pesada e similares, os sistemas podem controlar coisas que têm terríveis falhas nos modos desses sistemas, para que possam ter regras muito estritas sobre idiomas, compiladores, etc.

As organizações também geralmente escrevem sua política de segurança para o pior caso que conhecem, portanto, mesmo se você estiver escrevendo algo trivial, se estiver escrevendo para uma organização que possui sistemas não triviais, o padrão geralmente será mantê-la um padrão mais alto, a menos que alguém solicite uma exceção específica.

Conta
fonte
4
E esses são apenas os falsos positivos. O que realmente preocupa é o potencial de falsos negativos.
Stephen C
3
Honestamente, minha experiência com essas ferramentas geralmente tem sido péssima. Provavelmente algo ao longo de uma taxa de 1/200 a 1/1000 de encontrar algo que realmente valha a pena discutir. Além disso, quando recebo um falso positivo que sei que é algo usado em milhares de pontos na base de código ou no framework e ele o identificou apenas algumas vezes, não estou exatamente cheio de confiança. O problema é que você está implementando efetivamente uma prova negativa ao criar uma dessas ferramentas, a menos que comece com uma linguagem formal como spec #.
Bill
33

Linguagens dinâmicas podem ser usadas em aplicações militares e de defesa. Eu pessoalmente usei e entreguei Perl e Python em aplicativos do DoD. Também vi PHP e JavaScript usados ​​e implantados. Nas minhas experiências, a maioria do código não compilado que eu vi foram scripts de shell e Perl porque os ambientes necessários são aprovados e instalados em uma variedade de possíveis sistemas de destino.

O fato de essas linguagens serem dinâmicas provavelmente não é o problema. Os intérpretes para esses idiomas devem ser aprovados para uso nos sistemas de destino. Se o intérprete não for aprovado para uso (ou, talvez seja, mas não estiver implantado nos sistemas de destino), o idioma não poderá ser usado. O uso de um determinado intérprete (ou qualquer aplicativo) em um sistema seguro requer vários obstáculos de segurança: análise da fonte, capacidade de compilar a partir da fonte para ambientes de destino, análise adicional dos binários, garantindo que não haja conflitos com a infraestrutura existente, etc.

Thomas Owens
fonte
32

Passei algum tempo entrevistando o DOD (Departamento de Defesa), para obter um código de posição para a MMU do F-16 . Sem violar nenhuma não divulgação: a MMU é a unidade de computador que controla quase todas as funções do F-16. É (obviamente) fundamental que nenhum erro, como erros de tempo de execução, ocorra durante o voo. É igualmente crítico que o sistema realize operações de computação em tempo real.

Por esse e outros motivos históricos, todo o código desse sistema é gravado ou compilado no ADA, uma linguagem de programação estática orientada a objetos .

Devido aos recursos críticos de segurança da Ada, agora ele é usado não apenas para aplicações militares, mas também em projetos comerciais em que um bug de software pode ter consequências graves, por exemplo, aviônica e controle de tráfego aéreo, foguetes comerciais (por exemplo, Ariane 4 e 5), satélites e outros sistemas espaciais, transporte ferroviário e bancário. Por exemplo, o software do sistema fly-by-wire no Boeing 777 foi escrito em Ada.

Detesto citar muito, mas isso explica muito bem por que exatamente as linguagens estáticas (como o ADA) são usadas para projetos como este:

Um grande número de verificações em tempo de compilação é suportado para ajudar a evitar erros que não seriam detectáveis ​​até o tempo de execução em outros idiomas ou exigiriam que verificações explícitas fossem adicionadas ao código-fonte. Por exemplo, a sintaxe exige o fechamento explicitamente denominado de blocos para evitar erros devido a tokens finais incompatíveis. A adesão à digitação forte permite a detecção de muitos erros comuns de software (parâmetros incorretos, violações de intervalo, referências inválidas, tipos incompatíveis etc.) durante o tempo de compilação ou durante o tempo de execução. Como a simultaneidade faz parte da especificação da linguagem, o compilador pode, em alguns casos, detectar possíveis conflitos. Os compiladores também geralmente checam identificadores com erros ortográficos, visibilidade de pacotes, declarações redundantes etc., e podem fornecer avisos e sugestões úteis sobre como corrigir o erro.

O Ada também suporta verificações em tempo de execução para proteger contra acesso à memória não alocada, erros de estouro de buffer, violações de intervalo, erros de um por um, erros de acesso à matriz e outros erros detectáveis. Essas verificações podem ser desativadas no interesse da eficiência do tempo de execução, mas geralmente podem ser compiladas com eficiência. Também inclui recursos para ajudar a verificar o programa. Por esses motivos, o Ada é amplamente utilizado em sistemas críticos, onde qualquer anomalia pode levar a consequências muito graves, por exemplo, morte acidental, ferimentos ou perdas financeiras graves. Exemplos de sistemas em que o Ada é usado incluem aviônicos, ferrovias, bancos, militares e tecnologia espacial.

O gerenciamento dinâmico de memória da Ada é de alto nível e seguro para tipos. Ada não possui "ponteiros" genéricos (e vagos); nem declara implicitamente qualquer tipo de ponteiro. Em vez disso, toda alocação e desalocação dinâmica de memória devem ocorrer por meio de tipos de acesso declarados explicitamente. Cada tipo de acesso possui um pool de armazenamento associado que lida com os detalhes de baixo nível do gerenciamento de memória; o programador pode usar o pool de armazenamento padrão ou definir novos (isso é particularmente relevante para o acesso não uniforme à memória). É até possível declarar vários tipos de acesso diferentes que designam o mesmo tipo, mas usam conjuntos de armazenamento diferentes. Além disso, o idioma fornece verificações de acessibilidade, tanto em tempo de compilação quanto em tempo de execução, que garantem que um valor de acesso não possa sobreviver ao tipo de objeto para o qual aponta.

Michael Jasper
fonte
3
“Devido aos recursos de suporte crítico à segurança da Ada, ele agora é [usado em] foguetes comerciais (por exemplo, Ariane 4 e 5)” , é claro que o primeiro Ariane 5 explodiu devido a um bug do software , portanto não há uma bala de prata.
Andrew Marshall
5
@AndrewMarshall: "Embora o relatório tenha identificado um bug de software como causa direta, outros investigadores veem as causas como falhas de design do sistema e problemas de gerenciamento" - duvido seriamente que o código escrito em uma linguagem diferente (por exemplo, Java ou C ++) tenha recebido o foguete para orbitar.
Martin Schröder
@ MartinSchröder Oh, eu não estou duvidando que Ada ainda seja superior aos outros para esta aplicação, apenas observando que não é à prova de idiotas. Outro idioma pode ter deixado incontáveis ​​bugs que simplesmente não seriam possíveis no Ada.
Andrew Marshall
13

Tanto o Departamento de Defesa quanto a NASA têm uma longa história de falhas de programação que custam bilhões de dólares. Ambas as instituições aceitaram processos que deveriam protegê-las de repetir os mesmos erros.

Is this the government being slow to adopting new technologies?

Isso é um equívoco - linguagens dinâmicas não são uma nova tecnologia, são bastante antigas. O problema é que, se você já teve um problema causado por uma linguagem dinâmica (por exemplo, digitação fraca / dinâmica) e esse problema custou muito dinheiro, você pode aceitar uma política que o impediria de cometer o mesmo erro novamente - por exemplo, banir o uso de linguagens dinâmicas em sistemas sensíveis.

Linguagens dinâmicas geralmente "engolem" erros e acabam com algum comportamento inesperado. Isso é muito perigoso em sistemas sensíveis. Se algo de errado está acontecendo, você deve saber o mais rápido possível.

Se a segurança estiver em causa, seria necessário ver o caso de uso real. Por exemplo, eu não acho que uma página da web do Ruby on Rails seja automaticamente menos segura que uma página da Java.

Sulthan
fonte
2
IMHO mais bugs foram "engolidas" por estouros de buffer não detectados do que qualquer outra coisa, o que é precisamente algo que as línguas mais dinâmicas não vai permitir que, em primeiro lugar ... apenas dizendo
miraculixx
@miraculixx É verdade que existe uma razão pela qual Java / C # e linguagens similares estão sendo usadas muito mais que o Ruby. Eles estão na defensiva - checam tudo. Em C / C ++, a defesa pode ser aplicada usando um bom padrão de codificação. Você também pode aplicar verificações para tudo. Mas você pode imaginar escrever um aplicativo sensível em ruby ​​ou javascript? A possibilidade de erros ocultos é grande.
Sulthan
Na verdade eu posso. Provavelmente concordamos que o software precisa ser testado completamente, independentemente da linguagem de programação. Para evitar regressões, o teste é melhor automatizado usando, por exemplo, teste de unidade, BDD et al. Presumindo uma abordagem profissional (aplicativo sensível, certo?), Obter uma cobertura suficiente de teste é um processo gerenciado, não deixado ao acaso. Com isso, duvido que C / C ++, Java tenha uma vantagem sobre os gostos de ruby ​​ou javascript em termos de bugs ocultos. Habilidades de programador? Provavelmente mais técnico com C ++, duvidoso com Java, mas dificilmente um problema de linguagem. Mais técnico! = Qualidade do produto.
22415
6

Gostaria de acrescentar às respostas existentes descrevendo o SA-CORE-2014-005 do Drupal , que é uma vulnerabilidade altamente crítica que permite a injeção de SQL e, finalmente, a execução arbitrária de código. É causado pelas regras de digitação dinâmica do PHP e de lax runtime.

A totalidade do patch para esse problema é:

-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {

Esse código faz parte de uma camada de abstração SQL projetada para impedir a injeção de SQL. É necessária uma consulta SQL com parâmetros nomeados e uma matriz associativa que fornece um valor para cada parâmetro nomeado. É permitido que o valor seja uma matriz, em casos como WHERE x IN (val1, val2, val3), em que todos os três valores podem ser passados ​​como um único valor de matriz para um único parâmetro nomeado.

A vulnerabilidade ocorre porque o código assume que $ino $i => $valuedeve ser um número inteiro de índice do valor. Ele continua e concatena esse "índice" diretamente na consulta SQL como parte de um nome de parâmetro, porque números inteiros não precisam ser escapados, certo?

Infelizmente para o Drupal, o PHP não fornece essa garantia. É possível passar em outro array associativo, cujas chaves são strings, e esse loop concatenará alegremente a chave da string na consulta, como está (lembre-se de que o código pensa que só pode ser um número inteiro).

Embora existam maneiras de ocorrer um erro semelhante em um idioma estaticamente digitado, elas são improváveis. Um bom desenvolvedor consideraria as possíveis coisas $iantes de concatená-las na consulta. Com uma linguagem de tipo estaticamente, é muito fácil aplicar que $ideve ser um número inteiro e, em códigos sensíveis à segurança como este, isso certamente seria feito.

Além disso, o código realmente verifica se o valor é uma matriz antes de iterar sobre os itens. E aqui está uma segunda parte da falha que habilita essa vulnerabilidade: um array associativo e um array "normal" retornam true para is_array. Embora também seja verdade que em C #, tanto dicionários quanto matrizes IEnumerable, é difícil construir código que conflite as chaves do dicionário com índices de matriz como esse mesmo intencionalmente, e muito menos acidentalmente.

Roman Starkov
fonte
2

A segurança ou não de uma base de código depende de como você escreve seu código, de como testá-lo e de como validar e monitorar seu processo de desenvolvimento e implantação. Os idiomas não são seguros nem inseguros, é como você codifica.

A maioria dos incidentes de segurança devido a entradas maliciosas (injeções de sql, estouros de buffer), vírus, rootkits e cavalos de Troia. Nenhum idioma pode protegê-lo disso.

Portanto, proibir classes de idiomas por serem "inseguras" não é uma razão válida.

Suspeito que alguém, por qualquer motivo - informado ou não - tenha decidido proibir esses idiomas. Depois de um tempo, tornou-se uma verdade organizacional . Pode ter sido verdade naquele momento em alguns projetos, mas as culturas de controle não gostam de mudar decisões (admitem que estavam erradas) e preferem regras simples. Eles prosperam em regras e regulamentos e não importa se fazem sentido ou não, é a segurança percebida que conta.

Isso acontece o tempo todo em culturas de controle. Eu vejo isso mais ou menos diariamente. Não faz sentido, mas é assim que acontece. Se você quiser ler mais sobre este tópico altamente relevante, recomendo o livro de Schneider " The Alternative Reengineering ". Aqui está um diagrama de cultura de Michael Sahoto / Agilitrix , baseado no livro de Schneider: insira a descrição da imagem aqui

Martin Wickman
fonte
18
-1 Existem muitas razões técnicas válidas para a escolha de um idioma em detrimento de outro (verificação em tempo real, tipagem estática, tempo de execução) para sistemas críticos de segurança. Você implica que os motivos são 100% de cultura, nós vs. eles e arbitrários, que a IMO está totalmente incorreta nesse caso.
Michael Jasper
8
"Os idiomas não são seguros ou inseguros" - consulte stackoverflow.com/a/14313277/602554 . Alguns idiomas são definitivamente "mais seguros" que outros.
22630 Michael Jasper
2
Atualizado minha resposta, talvez ao seu gosto. Ainda acredito que a segurança de um sistema depende mais do código que você escreve do que do idioma que você usa, embora alguns idiomas ajudem a evitar certos problemas (enquanto, possivelmente, introduz outros).
Martin Wickman
2
@MartinWickman: a) As injeções de SQL / HTML e os estouros de buffer são resolvidos por alguns sistemas de tipos - você tem tipos diferentes para entradas com e sem escape, para saber qual deve ser tratado de que maneira. b) nem todos os problemas de segurança em 'projetos seguros' significam necessariamente comprometimento. Não quero que o software que está executando o avião tenha algum bug, mesmo que não seja um problema de 'segurança' (ou seja, não pode ser usado para controlar o sistema).
Maciej Piechotka
5
-1 para problemas de precisão factual. Explorações de estouro de buffer são um problema altamente específico para a linguagem C; você nunca ouve falar deles em idiomas que não permitem que você aloque um buffer de string na pilha. E não é difícil imaginar um dialeto SQL hipotético no qual o uso de Parâmetros não fosse simplesmente permitido, mas necessário . A injeção de SQL seria impossível nessa linguagem. Portanto, sim, uma linguagem projetada corretamente pode protegê-lo contra vários tipos comuns de ataques.
Mason Wheeler
2

Pelo que sei, a política oficial do Departamento de Defesa geralmente não proíbe idiomas dinâmicos.

Os padrões para software desenvolvido ou adquirido pelo Departamento de Defesa são promulgados pela Agência de Sistemas de Informação de Defesa (DISA). Sua Application Security - Application Security & Development Guia de Implementação Técnico de Segurança (STIG) não proíbe qualquer linguagem particular. Não menciona Ruby, mas menciona Perl e Python, que são igualmente dinâmicos. Ele os menciona no contexto de vários tópicos (seguindo os padrões de codificação estabelecidos, evitando as vulnerabilidades de injeção de comando, etc.).

Provavelmente, o que você está vendo é uma ferramenta de varredura excessivamente rigorosa (existem várias diferentes mencionadas no STIG, cada uma pode ter sua própria interpretação das regras) e / ou interpretação excessivamente rigorosa de sua saída.

Andrew Medico
fonte