Os aplicativos em execução no modo raiz poderão substituir a seção de memória do sistema operacional ou de outro programa?


3

Eu leio Aqui que qualquer aplicativo em execução no modo raiz pode emitir uma chamada do kernel e executar no modo kernel. É possível que QUALQUER aplicação em execução no modo raiz faça uma chamada ao kernel, vá para o modo kernel e adultere a área de memória de outro programa ou mexa na seção de memória do sistema operacional, porque quase todos os tutoriais dizem que o modo kernel dá ACESSO COMPLETO meu hardware, e se for assim, não seria uma grande falha de segurança, onde o programa logo após adquirir o acesso ao nível da raiz teria acesso a qualquer local de memória em RAM / DISK?

(Eu tenho Linux em mente enquanto faço esta pergunta)
EDITAR:
Bom eu estou realmente convencido do fato de que no linux a memória está completamente exposta, alguém pode explicar se é da mesma forma no Windows e no Unix


Deve ser o mesmo no Windows. A distinção entre o modo kernel e o modo de usuário é um recurso x86, os programas em execução no Ring 0, ou seja, no modo kernel, têm total privilégio sobre tudo, incluindo a memória e a MMU.
Lie Ryan

Respostas:


2

Sim, certamente é possível - muitos sistemas Linux até expõem a memória através dos dois arquivos do dispositivo /dev/mem (para memória física) e /dev/kmem (para memória virtual). Você pode acessar o espaço de endereço virtual do kernel via /proc/kcore. Naturalmente, não é recomendável escrever para esses dispositivos, pois você pode facilmente danificar seu sistema.

Não sei por que isso pode ser considerado um problema de segurança - você geralmente precisa ser root para gravar nesses dispositivos e, se tiver acesso root, já poderá fazer o que quiser.


Ei obrigado pela resposta, vc pode me ajudar com a minha edição ???
vikkyhacks

Outros sistemas Unix também podem fornecer /dev/mem ou /dev/kmem, mas embora o Windows usado para fornecer uma maneira de ler diretamente da memória física chamada Device\PhysicalMemory, parece ter sido desativado em versões recentes. Você pode usar ReadProcessMemory para ler a partir do espaço de memória de um único processo, no entanto.
user55325

2

Você parece estar misturando maçãs e laranjas. Para citar a resposta para a pergunta que você faz referência, "modo kernel e raiz são duas ideias separadas que não são relacionadas entre si. O conceito de executar um processo como root é um termo Unix / Linux que significa que você está logado como administrador do sistema. … Qualquer processo executado, seja como usuário root ou normal, geralmente é executado tanto no modo de usuário quanto no modo kernel. ” uma aplicação Executar como root geralmente não pode simplesmente mudar e começar a correr no modo kernel. Tudo o que ele pode fazer é a mesma coisa que um processo não-raiz pode fazer: chamar uma função do sistema, que faz com que o kernel do sistema operacional seja executado no modo kernel.

Dito isso, é verdade que a maioria dos sistemas baseados em Unix fornece privilégios de usuário root que não estão disponíveis para usuários / processos não-root. Por exemplo, como a user55325 aponta, a maioria dos sistemas baseados em Unix tem pseudo-dispositivos como /dev/mem, /dev/kmeme /proc/kcore que concedem aos processos privilegiados acesso à memória que não pertence a eles. Além disso, os processos raiz podem kill qualquer processo, e pode manipular o processo de várias maneiras /proc. E, é claro, o root tem acesso total a todos os arquivos. Por isso, é verdade que um processo que obtém acesso root tem muito poder; mas é assim que acontece.

Aliás, a menos que você sempre inicialize a partir de um disco óptico (CD / DVD) ou da rede, o sistema operacional é armazenado em arquivos de disco, e um invasor que tenha acesso à sua máquina como root pode reescrever todo o sistema operacional e de volta e espere que você reinicie. (E, oh ​​sim, eu quase me esqueci; um processo raiz também pode reiniciar seu sistema.) Então, novamente, sim, o privilégio de root é muito poderoso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.