Recentemente ho scoperto che una grande azienda utilizza un prodotto obsoleto nei propri server di archiviazione file (ho il nome e la versione nascosti) . Il bug è stato corretto nella versione recente, ma non erano né cve né exploit fino a quando non li ho creati. (non sono ancora disponibili e molte distribuzioni sono ancora pecore pacchetti git interessati nelle filiali correnti
Stabiliscono limiti sull'utilizzo della ram sui loro back-end http ma non sui loro server di storage virtuali (un singolo processo può arrestare il server su swap)
Esse eseguono il bilanciamento del carico per account, il che significa che ogni server di archiviazione contiene l'intero dato degli account http (hanno centinaia di account) . Non sono riuscito a trovare quanti ne hanno, ma considerando che il loro sito è un sito web top (in termini di traffico mondiale) immagino che questo dovrebbe essere molto.
Ho provato il problema e alla fine ho bloccato uno dei loro server di archiviazione per diverse ore con una singola richiesta (il server http inviava 500 pagine agli utenti che tentavano di accedere agli account memorizzati su di esso)
Mi sono scusato e ho inviato loro mail sul comportamento. Ho sollevato la preoccupazione di un attacco su larga scala che avrebbe spento tutti i file server guidati da un gruppo di 5 ~ 10 persone senza richiedere botnet.
Hello again,
In these cases we feel that our compensating controls can make this significantly harder to exploit. You are probably correct that all of these things are possible and ideally would be fixed, but we consider this to be very low risk. I'm very impressed with the investigations you have done !
Sembra davvero trattarli come attacchi classici da botnet che influenzano la larghezza di banda.
Ho imparato ad aggiornare sempre il software che soffre di perdite di memoria sfruttabili. Tuttavia, sono solo uno studente, non ho esperienza nella gestione di un sito web così grande (~ 47 richieste valide al minuto) . Ma qui ci sono alcuni punti:
- Secondo la loro pagina di stato, nessuno dei classici attacchi dos che hanno affrontato ha colpito gli utenti (che non è il caso qui)
- Anche se i loro "controlli" potrebbero impedire la messa offline dell'intero sito, sicuramente non impediranno un grande downtime di molti dei loro server di storage (che interessano migliaia di utenti) .
- Lo scopo del sito è quello di ospitare software, è perfettamente possibile scegliere quelli più scaricati.
- Poiché i server di archiviazione hanno 50 GB di RAM, non credo che ne abbiano così tanti (non so se grandi esigenze come questa possano richiedere un & 20Tb di ram)
- Può essere utilizzato solo per dos . Non c'è più possibilità per cose come l'esecuzione di codice remoto.
- Una volta ripristinato un server di archiviazione, è possibile riporlo immediatamente poiché nulla impedisce che una richiesta elaborata venga creata da un'altra macchina con un IP diverso e non richiede l'accesso (quindi la il repository non è disponibile la maggior parte del tempo per diversi giorni)
- Nel frattempo, fanno molte cose per impedire a una richiesta push di riempire ram, come limitare la dimensione massima dell'oggetto, o disabilitare oggetti ad albero nidificati profondi. Hanno anche intrapreso azioni su un problema precedente che consentiva l'esaurimento del ram da uno dei miei report .
Qualcosa che non riesco a capire è che si preoccupano dell'esecuzione di codice remoto non root su uno di quei server mentre il software che li alimenta è pubblico (non si preoccupano del fatto che gran parte di loro la configurazione è accessibile dall'esterno) .
Quindi ci sono situazioni in cui mantenere perdite di memoria utilizzabili è ok? (sono necessari solo 1,2 Gb di dati di rete per lo stallo di un server da 50 Gb) O più in generale, dovrebbe ram essere limitato su ɢɪᴛ server?