2010-11-17 10 views
23

Questa domanda è simile a Exploitable PHP Functions.Funzioni Python utilizzabili

I dati contaminati provengono dall'utente o in particolare da un utente malintenzionato. Quando una variabile contaminata raggiunge una funzione sink, allora hai una vulnerabilità. Ad esempio, una funzione che esegue una query sql è un sink e le variabili GET/POST sono fonti di taint.

Quali sono tutte le funzioni sink in Python? Sto cercando funzioni che introducono una vulnerabilità o software weakness. Sono particolarmente interessato alle vulnerabilità di Remote Code Execution. Ci sono intere classi/moduli che contengono pericolosi funzionalmente? Avete qualche esempio di interessanti vulnerabilità Python?

+6

Che ne dici di renderlo un wiki della comunità? –

+0

@Sven Marnach come renderebbe questo migliore? Non l'ho mai fatto prima. – rook

+0

È (sarebbe?) Molto difficile proteggere Python in gran parte; la lingua è semplicemente troppo flessibile per questo. Se stai cercando di creare un ambiente Python sicuro, hai un compito molto grande davanti a te. – katrielalex

risposta

6

Il modulo subprocess contiene entrata funzionalmente che sconsigliata questi modi di eseguire comandi/processi:

os.system 
os.spawn* 
os.popen* 
popen2.* 
commands.* 

C'è anche exec che eseguiranno il codice pitone e eval che "valutare" un'espressione e può essere utilizzato per manipolare le variabili.

14

eval e exec sono i classici. Tuttavia, può abusare open e file troppo:

open('/proc/kcore', 'w').write('0' * 1000 * 1000 * 1000) 

Poi vi sono le os, sys, subprocess e dircache moduli. Praticamente tutto ciò che tocca il filesystem o può essere usato per trasformare i dati in codice eseguibile (come os.system) sarà sulla lista.

Come ha sottolineato S. Lott nei commenti, la scrittura sul filesystem e l'esecuzione di programmi esterni arbitrari non sono specifici di Python. Tuttavia, valgono la pena considerarli per i revisori della sicurezza. La maggior parte di queste funzioni può essere tranquillamente utilizzata senza troppa preoccupazione per la sicurezza. eval e exec, d'altra parte, sono grandi grandi bandiere rosse. Usarli in modo sicuro richiede una cura meticolosa.

+2

L'apertura '/ proc/kcore' richiede i privilegi che la maggior parte dei processi non ha. Questo è un tipo diverso di exploit perché richiede dei privilegi e non è solo una trasandata programmazione. –

+2

@ S.Lott: certo, ma quello era solo un esempio (drammatico). Forse un utente malintenzionato si aspetta di essere in esecuzione come utente del server Web e apre invece '/ var/www/index.html'. Una buona sicurezza è stratificata. Non possiamo aspettarci che tutti gli amministratori dei nostri utenti si assicurino che tutto funzioni sempre con permessi ottimali, quindi vale la pena prestare un po 'più di attenzione e cercare questo genere di cose. – nmichaels

+0

"Buona sicurezza è stratificata". Questo non è interamente il punto. 'Eval' e' exec' sono exploit Python che non si basano sulla sicurezza. L'altro exploit è diverso nel suo genere - è irrilevante per Python, poiché tutte le lingue ce l'hanno. Fa parte della gestione dei privilegi del sistema operativo. Se lo si elenca, è necessario iniziare a elencare tutti gli exploit del sistema operativo che non hanno nulla a che fare con Python. Penso che dovresti segregare questo più chiaramente nella tua risposta come un diverso tipo di exploit che capita solo per usare Python. –

14

proprio dalla documentazione pickle:

Warning 

The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source. 
+1

I dati sottoposti a picking sono i peggiori, poiché non sono strutturati o leggibili a sufficienza per disinfettare e il codice arbitrario può essere eseguito ** mentre ** deselezionando. Ad esempio, l'invio di strutture di dati decapitati su DBUS (o qualche altro meccanismo IPC open-ish) può costituire un enorme buco di sicurezza, ma questo non è necessariamente ovvio per chi è nuovo a Python o DBUS. Un approccio migliore consiste nel scrivere un metodo di serializzazione esplicita, utilizzando JSON o XML, e inviarlo su qualunque protocollo tu stia utilizzando. – detly

3

La funzione input, che valuta la stringa e restituisce il risultato, ha alcune limitazioni, ma ancora può essere sfruttabili.

+0

Posso confermare che è sfruttabile. '__import __ ('os'). system ('ls')' Inserendo la stringa sopra in stdin, si ottiene l'esecuzione del comando 'ls' nella shell. – gtux

9

Tendo al paranoico quando cerco questo genere di cose. Ancora di più perché tendo a fare un sacco di metaprogrammazione.

  • comandi effetti collaterali più (che coprono altri messaggi)
    • manipolazione dei file (open, tarfile, zipfile, ...)
    • chiamate di rete (urllib2, socket, ...)
    • serializzazione dei dati/persistenza (pickle, shelve, ...)
    • processo/gestione filetto (subprocess, os.fork, os.kill, ...)
  • builtins
    • getattr
    • setattr
    • delattr
    • eval
    • exec
    • execfile
    • __import__

e probabilmente altri che sto dimenticando. Sono anche cauto sull'input dell'utente che passa attraverso le funzioni in cui sto modificando sys.path, sys.modules, ecc.

Problemi correlati