Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
linux-4.1.15_CVE-2018-5873 — Albero del codice sorgente del kernel Linux con un commit specifico che mira a CVE-2018-5873, fornendo un riferimento per studiare e sfruttare questa vulnerabilità del kernel. | Kitploit
Strumenti/GitHubGitHub/trinadh465/linux-4.1.15_cve-2018-5873
Analisi delle VulnerabilitàExploitPaper e RicercaApprendimento e FormazioneBinary Exploitation
GitHubtrinadh465/linux-4.1.15_cve-2018-5873

linux-4.1.15_CVE-2018-5873

Albero del codice sorgente del kernel Linux con un commit specifico che mira a CVE-2018-5873, fornendo un riferimento per studiare e sfruttare questa vulnerabilità del kernel.

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
3 anni faNon ancora revisionato

Rilascio del kernel Linux 4.x http://kernel.org/

Queste sono le note di rilascio per Linux versione 4. Leggetele attentamente, poiché spiegano di cosa si tratta, come installare il kernel e cosa fare se qualcosa va storto.

COS'È LINUX?

Linux è un clone del sistema operativo Unix, scritto da zero da Linus Torvalds con l'assistenza di un gruppo informale di hacker sparsi per la Rete. Mira alla conformità con POSIX e la Single UNIX Specification.

Possiede tutte le caratteristiche che ci si aspetta da un Unix moderno e completo, tra cui vero multitasking, memoria virtuale, librerie condivise, caricamento su richiesta, eseguibili copy-on-write condivisi, corretta gestione della memoria, e networking multistack che include IPv4 e IPv6.

È distribuito sotto la GNU General Public License - consultare il file COPYING allegato per maggiori dettagli.

SU QUALI HARDWARE FUNZIONA?

Sebbene originariamente sviluppato per PC basati su x86 a 32 bit (386 o superiore), oggi Linux funziona anche (almeno) su Compaq Alpha AXP, Sun SPARC e UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, Xtensa, Tilera TILE, AVR32 e architetture Renesas M32R.

Linux è facilmente portabile alla maggior parte delle architetture generiche a 32 o 64 bit purché abbiano un'unità di gestione della memoria a pagine (PMMU) e una versione del compilatore GNU C (gcc) (parte della GNU Compiler Collection, GCC). Linux è stato anche portato su diverse architetture senza PMMU, sebbene la funzionalità sia ovviamente alquanto limitata.

Linux è stato anche portato su se stesso. Ora è possibile eseguire il kernel come applicazione in spazio utente - questo si chiama UserMode Linux (UML).

DOCUMENTAZIONE:

  • Esiste molta documentazione disponibile sia in formato elettronico su Internet sia in libri, sia specifica per Linux sia relativa a domande generali su UNIX. Consiglio di consultare i sottodirectory di documentazione su qualsiasi sito FTP Linux per i libri del LDP (Linux Documentation Project). Questo README non vuole essere documentazione sul sistema: ci sono fonti molto migliori disponibili.

  • Ci sono vari file README nella sottodirectory Documentation/: questi tipicamente contengono note di installazione specifiche del kernel per alcuni driver, per esempio. Vedere Documentation/00-INDEX per un elenco di ciò che è contenuto in ogni file. Si prega di leggere il file Changes, poiché contiene informazioni sui problemi che potrebbero derivare dall'aggiornamento del kernel.

  • La sottodirectory Documentation/DocBook/ contiene diverse guide per sviluppatori e utenti del kernel. Queste guide possono essere visualizzate in vari formati: PostScript (.ps), PDF, HTML e pagine man, tra gli altri. Dopo l'installazione, "make psdocs", "make pdfdocs", "make htmldocs", o "make mandocs" renderà la documentazione nel formato richiesto.

INSTALLAZIONE del sorgente del kernel:

  • Se si installano i sorgenti completi, posizionare il tarball del kernel in una directory in cui si hanno i permessi (es. la propria home directory) e decomprimerlo:

    xz -cd linux-4.X.tar.xz | tar xvf -

    Sostituire "X" con il numero di versione dell'ultimo kernel.

    NON utilizzare l'area /usr/src/linux! Quest'area contiene un set (di solito incompleto) di header del kernel utilizzati dai file header delle librerie. Dovrebbero corrispondere alla libreria, e non essere alterati da qualsiasi kernel del giorno capiti.

  • Si può anche eseguire l'upgrade tra release 4.x tramite patch. Le patch sono distribuite in formato xz. Per installare tramite patch, ottenere tutti i file di patch più recenti, entrare nella directory principale del sorgente del kernel (linux-4.X) ed eseguire:

    xz -cd ../patch-4.x.xz | patch -p1

    Sostituire "x" per tutte le versioni successive alla versione "X" del proprio albero sorgente, in ordine, e tutto dovrebbe funzionare. Si consiglia di rimuovere i file di backup (some-file-name~ o some-file-name.orig), e assicurarsi che non ci siano patch fallite (some-file-name# o some-file-name.rej). Se ce ne sono, o io o voi abbiamo commesso un errore.

    A differenza delle patch per i kernel 4.x, le patch per i kernel 4.x.y (noti anche come kernel -stable) non sono incrementali ma si applicano direttamente al kernel base 4.x. Ad esempio, se il kernel base è 4.0 e si vuole applicare la patch 4.0.3, non si devono prima applicare le patch 4.0.1 e 4.0.2. Allo stesso modo, se si sta eseguendo il kernel versione 4.0.2 e si vuole passare a 4.0.3, è necessario prima invertire la patch 4.0.2 (cioè, patch -R) prima di applicare la patch 4.0.3. Maggiori informazioni in Documentation/applying-patches.txt

    In alternativa, lo script patch-kernel può essere utilizzato per automatizzare questo processo. Determina la versione corrente del kernel e applica eventuali patch trovate.

    linux/scripts/patch-kernel linux

    Il primo argomento nel comando sopra è la posizione del sorgente del kernel. Le patch vengono applicate dalla directory corrente, ma è possibile specificare una directory alternativa come secondo argomento.

  • Assicurarsi di non avere file .o obsoleti e dipendenze in giro:

    cd linux make mrproper

    Ora si dovrebbero avere i sorgenti installati correttamente.

REQUISITI SOFTWARE

La compilazione e l'esecuzione dei kernel 4.x richiedono versioni aggiornate di vari pacchetti software. Consultare Documentation/Changes per i numeri di versione minima richiesti e come ottenere aggiornamenti per questi pacchetti. Fare attenzione che l'uso di versioni eccessivamente vecchie di questi pacchetti può causare errori indiretti molto difficili da rintracciare, quindi non dare per scontato che si possano semplicemente aggiornare i pacchetti quando sorgono problemi evidenti durante la compilazione o il funzionamento.

DIRECTORY BUILD per il kernel:

Durante la compilazione del kernel, tutti i file di output saranno per impostazione predefinita memorizzati insieme al codice sorgente del kernel.

Usando l'opzione "make O=output/dir" è possibile specificare un percorso alternativo per i file di output (incluso .config).

Esempio:

root@kitploit:~
 codice sorgente del kernel: /usr/src/linux-4.X
 directory build:    /home/name/build/kernel

Per configurare e compilare il kernel, usare:

root@kitploit:~
 cd /usr/src/linux-4.X
 make O=/home/name/build/kernel menuconfig
 make O=/home/name/build/kernel
 sudo make O=/home/name/build/kernel modules_install install

Nota: Se si usa l'opzione 'O=output/dir', allora deve essere usata per tutte le invocazioni di make.

CONFIGURAZIONE del kernel:

Non saltare questo passaggio anche se si sta solo aggiornando una versione minore. Nuove opzioni di configurazione vengono aggiunte in ogni release, e problemi imprevisti si presenteranno se i file di configurazione non sono impostati come previsto. Se si desidera trasferire la configurazione esistente a una nuova versione con il minimo sforzo, usare "make oldconfig", che chiederà solo le risposte alle nuove domande.

  • I comandi di configurazione alternativi sono:

    "make config" Interfaccia di testo semplice.

    "make menuconfig" Menu colorati basati su testo, elenchi di opzioni e finestre di dialogo.

    "make nconfig" Menu colorati basati su testo migliorati.

    "make xconfig" Strumento di configurazione basato su X windows (Qt).

    "make gconfig" Strumento di configurazione basato su X windows (Gtk).

    "make oldconfig" Imposta tutte le domande in base al contenuto del file ./.config esistente e chiede informazioni sui nuovi simboli di configurazione.

    "make silentoldconfig" Come sopra, ma evita di ingombrare lo schermo con domande già risposte. Inoltre aggiorna le dipendenze.

    "make olddefconfig" Come sopra, ma imposta i nuovi simboli ai loro valori predefiniti senza chiedere.

    "make defconfig" Crea un file ./.config usando i valori predefiniti dei simboli da arch/$ARCH/defconfig o arch/$ARCH/configs/${PLATFORM}_defconfig, a seconda dell'architettura.

    "make ${PLATFORM}_defconfig" Crea un file ./.config usando i valori predefiniti dei simboli da arch/$ARCH/configs/${PLATFORM}_defconfig. Usare "make help" per ottenere un elenco di tutte le piattaforme disponibili per la propria architettura.

    "make allyesconfig" Crea un file ./.config impostando i valori dei simboli a 'y' il più possibile.

    "make allmodconfig" Crea un file ./.config impostando i valori dei simboli a 'm' il più possibile.

    "make allnoconfig" Crea un file ./.config impostando i valori dei simboli a 'n' il più possibile.

    "make randconfig" Crea un file ./.config impostando i valori dei simboli a valori casuali.

    "make localmodconfig" Crea una configurazione basata sulla configurazione corrente e sui moduli caricati (lsmod). Disabilita qualsiasi opzione di modulo non necessaria per i moduli caricati.

    root@kitploit:~
                        Per creare un localmodconfig per un'altra macchina,
                        salvare l'lsmod di quella macchina in un file
                        e passarlo come parametro LSMOD.
    
                target$ lsmod > /tmp/mylsmod
                target$ scp /tmp/mylsmod host:/tmp
    
                host$ make LSMOD=/tmp/mylsmod localmodconfig
    
                        Quanto sopra funziona anche durante la cross-compilazione.
    

    "make localyesconfig" Simile a localmodconfig, tranne che convertirà tutte le opzioni dei moduli in opzioni integrate (=y).

COMPILAZIONE del kernel:

  • Assicurarsi di avere almeno gcc 3.2 disponibile. Per maggiori informazioni, fare riferimento a Documentation/Changes.

    Si noti che è ancora possibile eseguire programmi utente a.out con questo kernel.

  • Eseguire "make" per creare un'immagine del kernel compressa. È anche possibile eseguire "make install" se si ha lilo installato per adattarsi ai makefile del kernel, ma potrebbe essere opportuno verificare prima la propria configurazione lilo.

    Per eseguire l'installazione vera e propria, è necessario essere root, ma nessuna delle normali operazioni di build dovrebbe richiederlo. Non prendere il nome di root invano.

  • Se si è configurata una qualsiasi parte del kernel come `moduli', sarà necessario eseguire anche "make modules_install".

  • Output verbose di compilazione/build del kernel:

    Normalmente, il sistema di build del kernel funziona in modalità abbastanza silenziosa (ma non del tutto silenziosa). Tuttavia, a volte voi o altri sviluppatori del kernel avete bisogno di vedere i comandi di compilazione, collegamento o altri esattamente come vengono eseguiti. Per questo, usare la modalità di build "verbose". Si fa inserendo "V=1" nel comando "make". Ad es.:

    make V=1 all

    Per fare in modo che il sistema di build dica anche il motivo della ricostruzione di ogni target, usare "V=2". Il valore predefinito è "V=0".

  • Tenere a portata di mano un kernel di backup nel caso qualcosa vada storto. Questo è particolarmente vero per le release di sviluppo, poiché ogni nuova release contiene nuovo codice che non è stato ancora sottoposto a debug. Assicurarsi di conservare anche un backup dei moduli corrispondenti a quel kernel. Se si sta installando un nuovo kernel con lo stesso numero di versione del proprio kernel funzionante, fare un backup della directory dei moduli prima di eseguire "make modules_install".

    In alternativa, prima di compilare, usare l'opzione di configurazione del kernel "LOCALVERSION" per aggiungere un suffisso univoco alla versione regolare del kernel. LOCALVERSION può essere impostata nel menu "General Setup".

  • Per avviare il nuovo kernel, sarà necessario copiare l'immagine del kernel (ad es. .../linux/arch/i386/boot/bzImage dopo la compilazione) nel luogo in cui si trova il kernel avviabile regolare.

  • L'avvio di un kernel direttamente da un floppy senza l'assistenza di un bootloader come LILO non è più supportato.

    Se si avvia Linux dal disco rigido, probabilmente si usa LILO, che usa l'immagine del kernel specificata nel file /etc/lilo.conf. Il file immagine del kernel è di solito /vmlinuz, /boot/vmlinuz, /bzImage o /boot/bzImage. Per usare il nuovo kernel, salvare una copia della vecchia immagine e copiare la nuova immagine sopra quella vecchia. Quindi, è NECESSARIO RIESEGUIRE LILO per aggiornare la mappa di caricamento!! Altrimenti, non si sarà in grado di avviare la nuova immagine del kernel.

SE QUALCOSA VA STORTO:

  • Se si hanno problemi che sembrano dovuti a bug del kernel, controllare il file MAINTAINERS per vedere se c'è una persona specifica associata alla parte del kernel con cui si hanno problemi. Se non c'è nessuno elencato, la seconda cosa migliore è inviare una mail a me ([email protected]), e possibilmente a qualsiasi altra mailing-list pertinente o al newsgroup.

  • In tutte le segnalazioni di bug, per favore specificare di quale kernel si sta parlando, come riprodurre il problema e qual è la propria configurazione (usare il buon senso). Se il problema è nuovo, comunicarmelo; se il problema è vecchio, cercare di dirmi quando lo si è notato per la prima volta.

  • Se il bug produce un messaggio come

    unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

    o informazioni di debug simili del kernel sullo schermo o nel log di sistema, si prega di riprodurlo esattamente. Il dump può sembrare incomprensibile, ma contiene informazioni che possono aiutare nel debug del problema. Anche il testo sopra il dump è importante: dice qualcosa sul perché il kernel ha generato il dump (nell'esempio sopra, è a causa di un puntatore del kernel errato). Ulteriori informazioni su come interpretare il dump si trovano in Documentation/oops-tracing.txt

  • Se si è compilato il kernel con CONFIG_KALLSYMS, si può inviare il dump così com'è, altrimenti si dovrà usare il programma "ksymoops" per interpretare il dump (ma compilare con CONFIG_KALLSYMS è di solito preferibile). Questa utility può essere scaricata da ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . In alternativa, si può eseguire la ricerca del dump a mano:

  • Nel debug di dump come quello sopra, aiuta enormemente poter cercare il significato del valore EIP. Il valore esadecimale in sé non aiuta molto me o chiunque altro: dipenderà dalla particolare configurazione del kernel. Quello che si dovrebbe fare è prendere il valore esadecimale dalla riga EIP (ignorare "0010:"), e cercarlo nella lista dei nomi del kernel per vedere quale funzione del kernel contiene l'indirizzo incriminato.

    Per trovare il nome della funzione del kernel, sarà necessario trovare il binario di sistema associato al kernel che ha mostrato il sintomo. Questo è il file 'linux/vmlinux'. Per estrarre la lista dei nomi e confrontarla con l'EIP del crash del kernel, eseguire:

    nm vmlinux | sort | less

    Questo darà un elenco di indirizzi del kernel ordinati in ordine crescente, dal quale è semplice trovare la funzione che contiene l'indirizzo incriminato. Notare che l'indirizzo fornito dai messaggi di debug del kernel non corrisponderà necessariamente esattamente agli indirizzi delle funzioni (anzi, è molto improbabile), quindi non si può semplicemente fare 'grep' dell'elenco: l'elenco, tuttavia, darà il punto di partenza di ogni funzione del kernel, quindi cercando la funzione che ha un indirizzo di partenza inferiore a quello che si sta cercando ma è seguita da una funzione con un indirizzo più alto, si troverà quella desiderata. In effetti, potrebbe essere una buona idea includere un po' di "contesto" nella segnalazione del problema, fornendo alcune righe intorno a quella interessante.

Scarica lo strumento

Ulteriori informazioni sull'uso degli strumenti di configurazione del kernel Linux si trovano in Documentation/kbuild/kconfig.txt.

  • NOTE su "make config":

    • Avere driver non necessari ingrandisce il kernel e può in alcune circostanze portare a problemi: il rilevamento di una scheda controller inesistente potrebbe confondere gli altri controller

    • Compilare il kernel con "Processor type" impostato a un valore superiore a 386 produrrà un kernel che NON funziona su un 386. Il kernel lo rileverà all'avvio e si arrenderà.

    • Un kernel con emulazione matematica compilata userà comunque il coprocessore se presente: l'emulazione matematica semplicemente non verrà mai utilizzata in quel caso. Il kernel sarà leggermente più grande, ma funzionerà su macchine diverse indipendentemente dal fatto che abbiano o meno un coprocessore matematico.

    • I dettagli di configurazione "kernel hacking" di solito producono un kernel più grande o più lento (o entrambi), e possono persino rendere il kernel meno stabile configurando alcune routine per cercare attivamente di rompere codice difettoso per trovare problemi del kernel (kmalloc()). Pertanto, probabilmente si dovrebbe rispondere 'n' alle domande per le funzionalità "di sviluppo", "sperimentali" o "di debug".

  • Reinstallare LILO di solito significa eseguire /sbin/lilo. Potrebbe essere opportuno modificare /etc/lilo.conf per specificare una voce per la vecchia immagine del kernel (ad esempio, /vmlinux.old) nel caso in cui quella nuova non funzioni. Consultare la documentazione di LILO per maggiori informazioni.

    Dopo aver reinstallato LILO, tutto dovrebbe essere a posto. Spegnere il sistema, riavviare e godersi il sistema!

    Se mai si dovesse cambiare il dispositivo root predefinito, la modalità video, la dimensione del ramdisk, ecc. nell'immagine del kernel, usare il programma 'rdev' (o in alternativa le opzioni di avvio di LILO quando appropriate). Non è necessario ricompilare il kernel per modificare questi parametri.

  • Riavviare con il nuovo kernel e godersi il sistema.

  • Se per qualche motivo non si può fare quanto sopra (si ha un'immagine del kernel precompilata o simile), raccontarmi il più possibile sulla propria configurazione aiuterà. Si prega di leggere il documento REPORTING-BUGS per i dettagli.

  • In alternativa, è possibile usare gdb su un kernel in esecuzione. (sola lettura; cioè non è possibile modificare valori o impostare punti di interruzione.) Per fare ciò, prima compilare il kernel con -g; modificare arch/i386/Makefile in modo appropriato, poi eseguire "make clean". Sarà anche necessario abilitare CONFIG_PROC_FS (tramite "make config").

    Dopo aver riavviato con il nuovo kernel, eseguire "gdb vmlinux /proc/kcore". Ora si possono usare tutti i soliti comandi di gdb. Il comando per cercare il punto in cui il sistema è crashato è "l *0xXXXXXXXX". (Sostituire le XXX con il valore EIP.)

    Usare gdb su un kernel non in esecuzione attualmente fallisce perché gdb (erroneamente) ignora l'offset di partenza per cui il kernel è compilato.