“Bin / sh: não pode acessar o tty; controle de trabalho desativado ”ao executar o shellcode”

Eu estou escrevendo shellcode para explorar uma vulnerabilidade de estouro de buffer em um servidor. Para fazer isso eu tenho shellcode de ligação de porta que eu envio para o servidor e então eu corro (de um terminal linux) o comando telnet serverAdress 4444 onde 4444 é a porta que eu abri. A esperança é que eu receba um shell de volta que eu possa usar para executar comandos. No entanto, eu sempre acabo com o comando

bin / sh: não pode acessar o tty; controle de trabalho desativado

Eu não posso alterar o código do servidor, e eu acredito que o shellcode está correto, porque eu peguei este site ( http://www.tsirogiannis.com/exploits-vulnerabilities-videos-papers-shellcode/linuxx86-port- binding-shellcode-xor-encoded-152 bytes / ). Da minha pesquisa, parece que isso pode ter a ver com o modo que o meu terminal está executando (algo chamado modo interativo ... ou algo parecido).

Todos os computadores envolvidos são máquinas linux e a máquina em que estou está executando a última versão do Ubuntu.

Alguma idéia do que esse erro de controle de trabalho significa e como posso corrigi-lo?

Basta remover /dev/console

cd /dev
rm -f console
ln -s ttyS0 console

editar / alterar o /etc/inittabconteúdo

::askfirst:/bin/sh

para:

ttyS0::askfirst:/bin/sh

Isso significa que comandos avançados como Ctrl + Z e Ctrl + C não estão disponíveis, porque sh não está escrevendo para um tty, mas para um soquete. Por esse motivo, sh não suportará os processos em segundo plano ( command &) e os comandos associados bg / fg / disown / jobs. Mas observe que os processos de se forçar e fechar suas entradas ainda funcionarão.

Você deve ter notado que, se um job em background tentar ler dados do terminal, o shell o interromperá (como em SIGSTOP) e informará que ele pausou o processo. Se o shell não o fizer, você tem uma condição de corrida e o que você escreve pode acabar no processo em segundo plano ou no shell. Isso cria uma confusão interessante e irritante na sua sessão de shell.

Ou use um shellcode mais elaborado que crie um terminal virtual (mas isso não é mais um shellcode quando isso acontecer), ou apenas esteja ciente de que o seu hack feio tem limitações.

Eu tive o mesmo problema no Debian Mate. Eu apenas corro um fsck de um live usb no dev / sda1 onde o diretório foi instalado.

Espero ter ajudado alguém

Se você pode mudar o comando do shell, tente: em sh +mvez de sh. Isso funcionou perfeitamente para mim.

Pessoal, eu tive o mesmo problema, mas espero consertá-lo

Não há como corrigir este problema Reinstalar o sistema Kali Linux, em seguida, quando ele veio na partição do disco, você deve excluir todos os outros discos apenas deixados 1 disco e, em seguida, bateu continuar então escrever todos os arquivos em um disco espero ter ajudado