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
Strumenti/GitHubGitHub/satheesh575555/linux-4.1.15_cve-2022-45934
Memory ForensicsAnalisi delle VulnerabilitàExploitDebuggerAnalisi di Binari
GitHubsatheesh575555/linux-4.1.15_cve-2022-45934

linux-4.1.15_CVE-2022-45934

Linux kernel 4.1.15 codice sorgente con un focus su CVE-2022-45934, che fornisce un riferimento per l'analisi delle vulnerabilità e la ricerca sullo sfruttamento.

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
43 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é vi dicono di cosa si tratta, spiegano 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.

Ha tutte le funzionalità che ci si aspetterebbe da un Unix moderno e completo, incluso il vero multitasking, la memoria virtuale, le librerie condivise, il caricamento a richiesta, gli eseguibili condivisi copy-on-write, una corretta gestione della memoria e il networking multistack, incluso IPv4 e IPv6.

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

SU QUALE HARDWARE FUNZIONA?

Sebbene sia stato originariamente sviluppato prima per PC basati su x86 a 32 bit (386 o superiori), oggi Linux funziona anche su (almeno) le architetture 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 Renesas M32R.

Linux è facilmente portabile sulla maggior parte delle architetture generiche a 32 o 64 bit, purché abbiano una memory management unit a pagine (PMMU) e un porting del compilatore GNU C (gcc) (parte di The GNU Compiler Collection, GCC). Linux è stato anche portato su alcune architetture senza PMMU, sebbene in tal caso la funzionalità sia ovviamente alquanto limitata. Linux è stato anche portato a se stesso. Ora potete eseguire il kernel come applicazione in spazio utente - questa è chiamata UserMode Linux (UML).

DOCUMENTAZIONE:

  • C'è molta documentazione disponibile sia in formato elettronico su Internet sia in libri, sia specifica per Linux sia relativa a questioni UNIX generali. Consiglio di cercare nei sottodirectory di documentazione di qualsiasi sito FTP Linux i libri del LDP (Linux Documentation Project). Questo README non è pensato per essere una documentazione del sistema: ci sono fonti molto migliori disponibili.

  • Ci sono vari file README nel sottodirectory Documentation/: questi contengono tipicamente 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. Leggete il file Changes, poiché contiene informazioni sui problemi che potrebbero derivare dall'aggiornamento del kernel.

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

INSTALLAZIONE dei sorgenti del kernel:

  • Se installate i sorgenti completi, mettete il tarball del kernel in una directory in cui avete i permessi (es. la vostra home directory) ed estraetelo:

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

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

    NON usate l'area /usr/src/linux! Quest'area ha un set (di solito incompleto) di header del kernel che vengono usati dai file header delle librerie. Dovrebbero corrispondere alla libreria e non essere alterati da qualunque kernel-di-turno ci sia.

  • Potete anche fare l'aggiornamento tra le release 4.x applicando le patch. Le patch sono distribuite nel formato xz. Per installare applicando le patch, procuratevi tutti i file di patch più recenti, entrate nella directory di livello superiore del sorgente del kernel (linux-4.X) ed eseguite:

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

    Sostituite "x" con tutte le versioni successive alla versione "X" del vostro albero dei sorgenti attuale, in_ordine, e dovreste essere a posto. Potreste voler rimuovere i file di backup (some-file-name~ o some-file-name.orig) e assicurarvi che non ci siano patch fallite (some-file-name# o some-file-name.rej). Se ce ne sono, o avete sbagliato voi o ho sbagliato io.

    A differenza delle patch per i kernel 4.x, le patch per i kernel 4.x.y (detti anche kernel -stable) non sono incrementali ma si applicano direttamente al kernel 4.x base. Per esempio, se il vostro kernel base è 4.0 e volete applicare la patch 4.0.3, non dovete prima applicare le patch 4.0.1 e 4.0.2. Analogamente, se state eseguendo la versione 4.0.2 del kernel e volete passare alla 4.0.3, dovete prima invertire la patch 4.0.2 (cioè, patch -R) prima di applicare la patch 4.0.3. Potete leggere di più su questo in Documentation/applying-patches.txt

    In alternativa, lo script patch-kernel può essere usato per automatizzare questo processo. Determina la versione corrente del kernel e applica tutte le 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 una directory alternativa può essere specificata come secondo argomento.

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

    cd linux make mrproper

    A questo punto dovreste avere i sorgenti installati correttamente.

REQUISITI SOFTWARE

La compilazione e l'esecuzione dei kernel 4.x richiede versioni aggiornate di vari pacchetti software. Consultate Documentation/Changes per i numeri di versione minimi richiesti e su come ottenere gli aggiornamenti di questi pacchetti. Attenzione: usare versioni eccessivamente vecchie di questi pacchetti può causare errori indiretti molto difficili da rintracciare, quindi non date per scontato di poter semplicemente aggiornare i pacchetti quando sorgono problemi evidenti durante la build o il funzionamento.

Directory BUILD per il kernel:

Quando compilate il kernel, tutti i file di output saranno per impostazione predefinita memorizzati insieme al codice sorgente del kernel. Usando l'opzione "make O=output/dir" potete specificare una posizione alternativa per i file di output (incluso .config). Esempio:

root@kitploit:~
 kernel source code: /usr/src/linux-4.X
 build directory:    /home/name/build/kernel

Per configurare e compilare il kernel, usate:

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 viene usata l'opzione 'O=output/dir', allora deve essere usata per tutte le invocazioni di make.

CONFIGURAZIONE del kernel:

Non saltate questo passaggio anche se state solo aggiornando una versione minore. In ogni release vengono aggiunte nuove opzioni di configurazione e compariranno strani problemi se i file di configurazione non sono impostati come previsto. Se volete portare la vostra configurazione esistente a una nuova versione con il minimo sforzo, usate "make oldconfig", che vi chiederà solo le risposte alle nuove domande.

  • I comandi di configurazione alternativi sono:

    "make config" Interfaccia a testo semplice.

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

    "make nconfig" Menu colorati basati su testo potenziati.

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

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

    "make oldconfig" Imposta come predefinite tutte le domande basandosi sul contenuto del vostro file ./.config esistente e chiede informazioni sui nuovi simboli di configurazione.

    "make silentoldconfig" Come sopra, ma evita di ingombrare lo schermo con domande a cui si è già risposto. Aggiorna inoltre le dipendenze.

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

    "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. Usate "make help" per ottenere un elenco di tutte le piattaforme disponibili della vostra 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,
                       salvate l'lsmod di quella macchina in un file
                       e passatelo 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 per il fatto che converte tutte le opzioni dei moduli in opzioni integrate (=y).

COMPILAZIONE del kernel:

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

    Notate che potete ancora eseguire programmi utente a.out con questo kernel.

  • Eseguite "make" per creare un'immagine compressa del kernel. È anche possibile eseguire "make install" se avete lilo installato in modo adatto ai makefile del kernel, ma potreste voler controllare prima la vostra specifica configurazione di lilo.

    Per fare l'installazione vera e propria, dovete essere root, ma nessuna parte della normale build dovrebbe richiederlo. Non prendete il nome di root invano.

  • Se avete configurato una qualsiasi delle parti del kernel come `modules', dovrete anche eseguire "make modules_install".

  • Output di compilazione/build del kernel verbose:

    Normalmente, il sistema di build del kernel funziona in una modalità abbastanza silenziosa (ma non del tutto). 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, usate la modalità di build "verbose". Ciò si ottiene inserendo "V=1" nel comando "make". Es.:

    make V=1 all

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

  • Tenete 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 debuggato. Assicuratevi di conservare anche un backup dei moduli corrispondenti a quel kernel. Se state installando un nuovo kernel con lo stesso numero di versione del vostro kernel funzionante, fate un backup della directory dei moduli prima di eseguire "make modules_install".

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

  • Per avviare il vostro nuovo kernel, dovrete copiare l'immagine del kernel (es. .../linux/arch/i386/boot/bzImage dopo la compilazione) nel posto in cui si trova il vostro normale kernel avviabile.

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

    Se avviate Linux dal disco rigido, è probabile che usiate LILO, che usa l'immagine del kernel come specificato nel file /etc/lilo.conf. Il file dell'immagine del kernel è di solito /vmlinuz, /boot/vmlinuz, /bzImage o /boot/bzImage. Per usare il nuovo kernel, salvate una copia della vecchia immagine e copiate la nuova immagine sopra quella vecchia. Poi, DOVETE RIESEGUIRE LILO per aggiornare la mappa di caricamento!! Se non lo fate, non potrete avviare la nuova immagine del kernel.

SE QUALCOSA VA STORTO:

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

  • In tutte le segnalazioni di bug, per favore dite di quale kernel state parlando, come riprodurre il problema e qual è la vostra configurazione (usate il buon senso). Se il problema è nuovo, ditemelo e, se il problema è vecchio, cercate di dirmi quando lo avete 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 del kernel simili sul vostro schermo o nel vostro log di sistema, riproducetele esattamente. Il dump può sembrarvi incomprensibile, ma contiene informazioni che possono aiutare a debuggare il problema. Anche il testo sopra il dump è importante: dice qualcosa sul perché il kernel ha scaricato il codice (nell'esempio sopra, è dovuto a un puntatore del kernel errato). Ulteriori informazioni su come dare un senso al dump si trovano in Documentation/oops-tracing.txt

  • Se avete compilato il kernel con CONFIG_KALLSYMS potete inviare il dump così com'è, altrimenti dovrete usare il programma "ksymoops" per dare un senso al 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, potete fare la ricerca nel dump a mano:

  • Nel debuggare dump come quello sopra, aiuta enormemente se potete cercare cosa significa il valore EIP. Il valore esadecimale in sé non aiuta molto me né nessun altro: dipenderà dalla vostra particolare configurazione del kernel. Quello che dovreste fare è prendere il valore esadecimale dalla riga EIP (ignorando il "0010:") e cercarlo nella namelist del kernel per vedere quale funzione del kernel contiene l'indirizzo incriminato.

    Per scoprire il nome della funzione del kernel, dovrete trovare il binario di sistema associato al kernel che ha mostrato il sintomo. Questo è il file 'linux/vmlinux'. Per estrarre la namelist e confrontarla con l'EIP del crash del kernel, fate:

    nm vmlinux | sort | less

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

Scarica lo strumento

Potete trovare maggiori informazioni sull'uso degli strumenti di configurazione del kernel Linux in Documentation/kbuild/kconfig.txt.

  • NOTE su "make config":

    • Avere driver non necessari renderà il kernel più grande e può in alcune circostanze portare a problemi: il probing di una scheda controller inesistente può confondere gli altri controller

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

    • Un kernel con la math-emulation compilata userà comunque il coprocessore se presente: in quel caso l'emulazione matematica non verrà mai usata. 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 di "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 il codice difettoso per trovare problemi del kernel (kmalloc()). Quindi probabilmente dovreste rispondere 'n' alle domande sulle funzionalità "development", "experimental" o "debugging".

  • Reinstallare LILO di solito è una questione di eseguire /sbin/lilo. Potreste voler modificare /etc/lilo.conf per specificare una voce per la vecchia immagine del kernel (ad esempio, /vmlinux.old) nel caso quella nuova non funzioni. Consultate la documentazione di LILO per maggiori informazioni.

    Dopo aver reinstallato LILO, dovreste essere a posto. Spegnete il sistema, riavviate e godetevi il risultato!

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

  • Riavviate con il nuovo kernel e godetevi il risultato.

  • Se per qualche motivo non potete fare quanto sopra (avete un'immagine del kernel precompilata o simili), dirmi il più possibile sulla vostra configurazione aiuterà. Leggete il documento REPORTING-BUGS per i dettagli.

  • In alternativa, potete usare gdb su un kernel in esecuzione. (sola lettura; cioè non potete cambiare valori o impostare breakpoint.) Per fare questo, prima compilate il kernel con -g; modificate arch/i386/Makefile in modo appropriato, poi eseguite "make clean". Dovrete anche abilitare CONFIG_PROC_FS (tramite "make config").

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

    Eseguire gdb su un kernel non in esecuzione attualmente fallisce perché gdb (erroneamente) ignora l'offset iniziale per il quale il kernel è compilato.