| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Por aquilo que li, trata-se simplesmente do velho conhecido conceito de separar segmentos de dados e segmentos de instruções, tornando os segmentos de dados não executáveis.
Isso diminui a possibilidade de explorar alguns vectores de ataque (nomeadamente buffer-overflows) mas não faz nada quanto a outros (código malicioso disfarçado) que são também usados por virus e outro código mal-intencionado.
Cumps, JB |
| |
| |
| | | "separar segmentos de dados e segmentos de instruções" Isto já é possivel na ISA x86. O que não é possível é especificar permissão apenas de execução ou apenas de leitura nas páginas de um segmento. Em x86 existe apenas bit para escrita e outro para leitura e execução (se podes ler, podes executar). Aliás, já existe há alguns anos patches para o kernel Linux para uma stack não executável: Owl O facto de não se usar actualmente segmentos de dados e stack sem permissões de execução deve-se aos vários usos (legais) para regiões de dados executáveis: JIT compilers, funções aninhadas, signal handlers (no caso de Linux), etc.. O facto de JITs e etc. não explicitarem regiões de dados que irão precisar de ser executados é devido a essa característica singular dos x86: diferente das outras arquitecturas (MIPS, Sparc, Alpha, se a memória não me falha) não ter o bit individual de execução. De qualquer modo, uma stack sem permissão de execução não elimina os buffer-overflows, apenas aqueles baseados em introdução de código na stack, em oposição a outros que usam código já da aplicação (ou, no caso de uma heap executável, introdução de código na heap). Exemplos de ataques:
hugs
Strange |
| |
| | O que não é possível é especificar permissão apenas de execução ou apenas de leitura nas páginas de um segmento. Em x86 existe apenas bit para escrita e outro para leitura e execução (se podes ler, podes executar). Ha' uma forma de lhe dar a volta: openbsd/2003-04/13 62.html
|
| |
| | Isso baseia-se no que o Strange referiu: segmentação.
|
| |
| | | Muitos virus como o Blaster utilizavam buffer-overflow em computadores vulneráveis para se replicarem. Os tipos da MS é que devem estar todos contentes, finalmente vão uma gestão de memória com protecções decentes (made by intel/amd) :)
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| |
| | O Linux e outros Unices também irão se beneficiar. Afinal, também no ano passado houve vários exploits que usaram essa técnica de buffer overflow.
Para os usuários de Windows só vai haver uma solução definitiva contra vírus e outros furos de segurança quando a Intel ou AMD conseguirem desenvolver processadores com inteligência humana para poderem pensar e decidir por eles :-)))
|
| |
| | | Penso que Microsoft e AMD já andam a trabalhar nisto há algum tempo (de notar que não basta as features de hardware, o SO tb tem que colaborar): Execution protection (NX, or no execute) is an operating system feature that relies on processor hardware to mark memory with an attribute indicating that code should not be executed from that memory. Execution protection functions on a per-virtual memory page basis, most often leveraging a bit in the page table entry (PTE) to mark the memory page. Execution protection prevents code execution from data pages such as the default heap, various stacks, and memory pools. Protection can be applied in both user and kernel-mode. As execution protection prevents data execution from the stack, the specific exploit leveraged by the recent MSBlaster worm would have resulted in a memory access violation and termination of the process. On a system with execution protection, MSBlaster would have been limited to a Denial-of-Service (DOS) attack, but would not have had the ability to replicate and spread to other systems. This would have significantly limited the scope and impact of the worm. And although MSBlaster in its original form may have been less malicious, it should be noted that execution protection is by no means a comprehensive defense against all viruses, worms, and other malicious code. The actual hardware implementation of execution protection and marking of the virtual memory page varies by processor architecture. However, processors supporting execution protection are capable of raising an exception when code is executed from a page marked with the appropriate attribute set. The 32-bit version of Windows currently leverages the NX processor feature, as defined by the AMD64 Architecture Programmer's Manual. This processor feature requires the processor run in Physical Address Extension (PAE) mode. Although the only currently shipping processor families with Windows-compatible hardware support for execution protection are the AMD K8 and the Intel Itanium Processor Family, it is expected that future 32 and 64-bit processors will provide execution protection. Microsoft is preparing for and encouraging this trend by supporting execution protection in its flagship Windows operating systems. Microsoft will be supporting emerging processors with execution protection by making additions to Windows, beginning with SP2. Execution protection has obvious advantages concerning buffer overrun exploits and promoting general good coding practices for Microsoft and third-party developers. Table 1 below outlines various types of user-mode memory regions and their default execution protection.
|
| |
| | Nao seria melhor eliminar a porcaria do "blind execution" caracteristico dos cpu's ? Eles executam tudo o que se lhes manda. Para quem nao leu, aconselho o Hacking the XBOX, que é uma leitura interessante de ataques a hardware, e foi que li sobre algumas propostas contra o "blind execution" (se nao foi aqui, foi noutro lado qq, mas o livro é bastante interessante na mesma!).
No fim de contas, é mais uma para dificultar e dar trabalho, aumentando o tempo do ataque (afinal não é isso que a criptografia faz ?). Com tempo da-se a volta e volta-se ao jogo do rato (o que é bastante divertido...).
|
| |
| |
| | | Nao seria melhor eliminar a porcaria do "blind execution" caracteristico dos cpu's ? Eles executam tudo o que se lhes manda.
Se tiveres alguma teoria sobre como criar sistemas clarividentes que saibam se o código que executam é ou não prejudicial nós estamos interessados em conhecê-la!
|
| |
| | Pega num livro e le um bocado, ou entao googla.. Existem propostas para isso...
|
| |
| | Algo mais substancial era bem vindo..
|
| |
| | Sim, tens razao ! Eu trago o livro pq nao o tenho aqui à mao e dou-te alguns indicadores para algumas soluções que eram lá mencionadas (isto se é que estava naquele livro, mas tenho quase a certeza que sim!).
|
| |
| | boas e qual é a grande vantagem disso? o maximo que podias fazer em relação a isso era por cada opcode enviado ao processador mais respectivos parametros gerar uma espécie de checksum que verificasse a validade da operação, numa espécie de verificação sintática mas nunca semântica (verificação contextual - evil - de uma dada aplicação). Ou o objectivo será parar o processador quando não há nada util que o SO lhe possa atribuir? Se não gostas do idle process podes sempre tentar encontrar numeros primos, lutar contra o cancro ou então procurar vida extraterrestre. jrmfe
|
| |
| | Wtf ? que tem isso a ver com o resto ? e ja agora, o idle cpu gasta energia... Ate gostava de saber quanto eh que custou a brincadeira do rc5 e do SETI e restantes amigos... Numa altura em que se fala de problemas de energia, gastam-se qt's brutais para nada (ou marginalmente util, como provar que o rc5-64 eh quebrado em 3 anos ou que existem aliens...duh!).
|
| |
| | Este artigo é no mínimo hilariante, além da tecnologia não ser novidade nenhuma esta não tem nada a ver com anti-virús, virús são apenas uma forma de explorar falhas que as referidas tecnologias procuram conter.
|
| |
