In che modo le modifiche al codice dannoso in una richiesta di pull GitHub possono essere mascherate da un utente malintenzionato?

Question

In che modo le modifiche al codice dannoso in una richiesta di pull GitHub possono essere mascherate da un utente malintenzionato?

#1 da (2 voti)

6

Quando visualizzi una richiesta di pull su GitHub (o l'equivalente su qualsiasi altra piattaforma), l'interfaccia web mostra una differenza tra le modifiche da revisionare.

La revisione del diff è ovviamente vulnerabile all'errore umano, poiché è possibile inserire modifiche dannose (vedere mortenson / pr-sneaking ).

Esistono tecniche di offuscamento che non possono essere ragionevolmente individuate da una persona che esegue una revisione approfondita del codice nell'interfaccia Web di GitHub?

Un esempio è un attacco omogeneo, che potrebbe potenzialmente far apparire una serie di personaggi a un umano come un valore mentre in realtà è un altro.

Potrebbe esserci anche una vulnerabilità / bug nel motore diff o nella visualizzazione di output che potrebbe essere sfruttata per nascondere o mascherare il codice dannoso in una richiesta pull.

Per chiarire non sto chiedendo sulla capacità di un umano di esaminare con precisione le modifiche al codice - sto chiedendo potenziali vulnerabilità di spoofing / mascheramento che potrebbero essere sfruttate da un utente malintenzionato per ingannare un essere umano ad accettare una richiesta apparentemente legittima.

github spoofing

posta jamieweb 05.10.2018 - 04:36

fonte

1 risposta

Leggi altre domande sui tag github spoofing

Il telegramma dipende da una chiave radice CA? Sicurezza Conseguenze dei dati del passaporto compromessi

score 2 · Accepted Answer

Gli errori nel processo di generazione di diff sono improbabili. Praticamente tutte le interfacce Web per un sistema VCS richiamano effettivamente lo strumento VCS stesso per generare le differenze. Praticamente, qualsiasi bug che potrebbe esserci è abbastanza probabile che venga trovato e risolto rapidamente (sta generando dati di fronte all'utente, quindi qualsiasi bug è molto visibile).

Dato che, le tue opzioni ammontano a:

Attacchi agli omagli, che hai già menzionato. Non vedo questi come molto probabile, in quanto dipendono dal tipo di carattere utilizzato per il rendering e dovrebbero essere in letterali di dati nella maggior parte dei linguaggi di programmazione per non causare errori di sintassi, il che a sua volta limita notevolmente i tipi di bug che puoi introdurre.
Modifica dei file binari nel repository. Quando si ha a che fare con dati binari, la maggior parte dei sistemi VCS ti dice solo che il file è cambiato, non come è cambiato, quindi non ci sono cambiamenti da rivedere nel PR a corto di download e utilizzo del file modificato. Questo è uno dei due motivi per cui le persone sane non usano il controllo di versione per i dati binari, l'altro è che è veramente brutto gestirlo in modo efficiente. Perché non molte persone lo fanno, non è un probabile vettore di attacco.
Semplice steganografia. Questo essenzialmente dipende dal fatto che il revisore non presti attenzione o non capisca il codice che sta esaminando. I due approcci ovvi includono una piccola modifica che introduce il bug nel mezzo di un paio di sezioni con molte modifiche o che si avvantaggia del fatto che le modifiche sono mostrate per linea.