Funzioni Python utilizzabili

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?

fonte

2010-11-17 rook

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

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

È (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

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.

fonte

2010-11-17 17:52:40 rook

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.

fonte

2010-11-17 17:58:06 nmichaels

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. –

@ 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

"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. –

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.

fonte

2010-11-17 18:44:40 admalledd

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

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

fonte

2010-11-24 19:58:07 khachik

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

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.

fonte

2010-11-24 22:50:14 dietbuddha

risposta

Problemi correlati