Vulnerabilità del codice nello script Shell

Naviga le tue risposte
1

Mi è stato assegnato un incarico per la mia classe di sicurezza informatica. Ci è stato dato un pezzo di codice per analizzare e determinare le vulnerabilità che potrebbe avere. 

#!/bin/sh
# shell script to create a copy of the shadow file to the /tmp directory

echo > /tmp/shadowcopy

# allow only root access
chmod 600 /tmp/shadowcopy

# append the original file to the copy
cat /etc/shadow >> /tmp/shadowcopy

# Hint: the access permissions of a file in linux are verified when the file is opened.
# the process will keep the original permissions as long as it keeps the file open, even
# if permissions change.

Alcuni compagni di classe e ho determinato che questo script potrebbe soffrire di vulnerabilità legata alle condizioni della competizione se due processi separati tentano di aprire / tmp / shadowcopy.

Pensiamo anche che la vulnerabilità di comando di iniezione potrebbe essere possibile se il / tmp / shadowcopy viene modificato prima che inizi l'append.

Le nostre ipotesi su questo script di shell sono corrette? o ci manca una vulnerabilità importante che potrebbe essere sfruttata se lo script è usato?

    
posta Alan W 13.05.2015 - 19:22
fonte

2 risposte

3

Il cat binario non impianta le chiamate flock () utilizzando il LOCK_EX per l'accesso in scrittura esclusivo, quindi la tua ipotesi è corretta.

È possibile verificare che seguendo i problemi delle chiamate di sistema da parte di questo o di qualsiasi file binario eseguendo il file strace cat.

Un modo per prevenire il problema sarebbe il seguente: 

#!/bin/bash

set -e

(
  flock -n 200

  echo > /tmp/shadowcopy

  chmod 600 /tmp/shadowcopy

  cat /etc/shadow >> /tmp/shadowcopy
) 200>/var/lock/.mylock

Le autorizzazioni possono anche creare una condizione di competizione in quanto qualcuno può emettere un tail -f / tmp / shadowcopy prima del comando chmod per accedere.

Per ulteriori informazioni sulle migliori pratiche di sicurezza riguardanti le condizioni di gara dovresti dare un'occhiata a fnctl (), flock () & stat ().

O se sul dispositivo era presente un'altra persona che stava guardando il buffer, potevano accedere anche agli hash, vedi link .

È una prova di concetto per raschiare memoria da un processo in esecuzione.

    
risposta data 13.05.2015 - 19:41
fonte
3

Sono d'accordo sul fatto che l'esecuzione è intesa a rilevare la condizione di competizione, ma poiché non ci sono errori nel controllo (solo un set -e funzionerebbe), ci sono più buchi disponibili:

Poiché /tmp è una cartella condivisa, posso creare un /tmp/shadowcopy con la modalità 666 (così puoi aprirlo e scriverlo, ma non chmod). Se il tuo script è stato eseguito da un membro di un gruppo shadow (così / etc / shadow può essere letto senza essere root), ti ritroverai perfettamente leggibile dal tuo utente.

Nota inoltre che la condizione di gara è infinitamente lunga, poiché l'attaccante può creare e aprire il file in anticipo, non ha bisogno di razza tra echo e chmod .

Se /tmp/shadowcopy è stato creato come collegamento simbolico, è possibile creare un file con un nome arbitrario e il contenuto del file shadow (assumendo che lo script sia eseguito da root). Principalmente utile come negazione del servizio, ad es. ln -s /tmp/shadow /boot/vmlinuz-3.16.0-4-amd64 sostituisce il kernel e rende quindi la macchina non avviabile.

    
risposta data 14.05.2015 - 01:42
fonte

Leggi altre domande sui tag

Burp Suite non intercetta le risposte JSON [chiuso] Quale tipo di certificato SSL è il più grande?