Attualmente sto cercando di risolvere una sfida di Capture The Flag che prevede il tentativo di intensificare i privilegi sfruttando un exploit in uno script bash.
Lo script esegue innanzitutto le seguenti operazioni per ottenere tutti i socket con protocollo TCP nello stato LISTEN:
output=$($_netstat -ntpl 2> /dev/null | $_egrep '^t')e quindi analizza l'output riga per riga. Una delle cose che fa per ogni riga è questa:
if [[ "$cur_syn" == "0" || "$max_syn" != "$cur_syn" ]]
then continue
fi$cur_synè il valore della Recv-Qcolonna restituito da netstat ed $max_synè il valore della Send-Qcolonna.
Quindi, solo un socket che si trova nello stato LISTEN e con Recv-Q! = 0 e Recv-Q == Send-Q supererà questi controlli.
netstatL 'uomo afferma che:
Recv-Q
stabilito: il conteggio dei byte non copiati dal programma utente collegato a questo socket. Ascolto: dal kernel 2.6.18 questa colonna contiene il backlog di sincronizzazione corrente.
e
Send-Q
stabilito: il numero di byte non riconosciuti dall'host remoto. Ascolto: dal kernel 2.6.18 questa colonna contiene la dimensione massima del backlog di syn.
Il fatto è che non riesco a creare un socket con un Send-Q diverso da 0.
Se la mia interpretazione è corretta, il valore Send-Q per una presa che è in ascolto è la dimensione massima del portafoglio ordini, che è il backlogparametro a della C (2) ascoltare la funzione. Ma anche quando creo un socket del server di ascolto con un backlog di dimensioni 3, netstatsegnala comunque che Send-Q è 0! Che cosa sto facendo di sbagliato?
Cordiali saluti, sono riuscito a apportare la Recv-Qmodifica avendo più client connessi a un socket del server che ha ricevuto un SIGSTOP. Recv-Qsale fino a maximum size of the syn backlog + 1, quindi tutte le connessioni vengono rifiutate. Ma purtroppo, Send-Qrimane invariato.