linux user group brescia

Ben fatto :DAvevo capito male la critica.Le mie scuse 

    Il Venerdì 19 Febbraio 2016 13:52, Francesco Rmp <atomikramp a gmail.com> ha scritto:
 

 Ciao,
rielaboro la mia mail precedente scritta di fretta, in prima battuta scusandomi per i toni adottati.

Riagganciandomi al bug delle glibc.
PoC sta per proof of concept, google ne ha rilasciato uno su github ed è linkato nel loro security blog.
per Proof of concept non armato si intende che questo PoC non permette direttamente l'esecuzione di codice arbitrario sul sistema vittima, ma causa unicamente un crash.
Tuttavia di per sè il bug non è particolarmente complicato, e con un pochino di lavoro, nemmeno troppo, è abbastanza facile arrivare ad avere un exploit funzionante in grado di eseguire codice sul target.

Ciò che rende veramente arduo l'exploiting sono le protezioni sulla memoria presenti nelle distribuzioni moderne
- ASLR: randomizzazione dell'address space della memoria
- PIE: position independent executable, che randomizza anche l'area di static code del programma
- NX: che blocca l'esecuzione di codice da aree di memoria non esplicitamente preposte (es stack)
- RELRO: che imposta la relocation table in read only.

Tuttavia, le protezioni sopra citate (tranne ASLR) vengono abilitate a compile time, e dal momento che il bug risiede in una libreria, il fatto che queste protezioni siano o meno presenti dipende dal binario da cui esse vengono linkate.

Per fare un esempio pratico:
curl su KALI Linux 2:
$ checksec
CANARY    : ENABLED
FORTIFY   : ENABLED
NX        : ENABLED
PIE       : ENABLED
RELRO     : FULL

e curl su Debian GNU/Linux 7
$ checksec
CANARY    : ENABLED
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : Partial

lo stesso identico software, su due distro diverse è compilato con criteri di protezione differenti, ed è inutile dire che se PIE è disabilitato, e RELRO è parziale, l'exploiting è decisamente più semplice.

Infine, la cosa più preoccupante sta nel fatto che questo bug, sarà per lo più pericoloso in ambienti server, dove gli aggiornamenti sono meno frequenti, e dove si possono tranquillamente trovare sistemi vetusti, per i quali magari non esistono più nemmeno le maintenance patch (ho visto ancora in giro delle ubuntu 10.x)

Per quanto riguarda uno scenario problematico, anche se ancora devo provare, mi viene in mente un postfix, che fa query DNS per tutti i domini a cui deve fare delivery.. basterebbe far mandare una mail dall'MTA verso un dominio malevolo per creare problemi ENORMI. questa cosa però è da prendere con le pinze, perchè non so se il bug si applica anche alla risoluzione di record MX.


2016-02-19 12:18 GMT+01:00 Francesco Rmp <atomikramp a gmail.com>:

comunque appena ho un attimo elaboro meglio la risposta
2016-02-19 12:15 GMT+01:00 Francesco Rmp <atomikramp a gmail.com>:

Alessandro, hai frainteso, non era una risposta spocchiosa nei tuoi confronti, probabilmente mi sono espresso male.
era più un commento diretto all'articolo, che sicuramente è di natura divulgativa, ma divulga cose che se lette da chi non è tecnico, potrebbero passare un'errata percezione del problema.
2016-02-19 12:02 GMT+01:00 Alessandro Partesotti <a.partesotti a yahoo.it>:

Qui si possono trovare info per la mitigazione
Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo
|   |
|   |   |   |   |   |
| Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overfloThis is the mail archive of the libc-alpha a sourceware.orgmailing list for the glibc project. Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] Message Nav:  |
|  |
| Visualizza su www.sourceware.org | Anteprima per Yahoo |
|  |
|   |


 

    Il Venerdì 19 Febbraio 2016 11:54, Alessandro Partesotti <a.partesotti a yahoo.it> ha scritto:
 

 Con sicurezza intendo networking e simili. ovviamente il bug in oggetto può avere risvolti di security. 

    Il Venerdì 19 Febbraio 2016 11:52, Alessandro Partesotti <a.partesotti a yahoo.it> ha scritto:
 

 Il PoC? ammetto che non ho idea di cosa siaIl problema si è di sforamento della memoria ma era per dire che il punto critico non è di sicurezza. L'articolo è introduttivo e divulgativo ed è normale che ci possano essere incongruenze e inesattezze. Penso che risposte meno arroganti siano un buon punto di partenza per permettere di comprendere topic anche ai meno esperti anche con articoli di carattere divulgativo e non prettamente tecnico!
Detto questo non replicherò oltre.

 

    Il Venerdì 19 Febbraio 2016 11:41, Francesco Rmp <atomikramp a gmail.com> ha scritto:
 

 il PoC non è armato, ma non ci vuole molto ad armarlo.
Il problema principale sono le protezioni sulla memoria, i "firewall avanzati"... please no bullshit.
gli scenari problematici sono ben altri cmq.
2016-02-19 11:01 GMT+01:00 Alessandro Partesotti <a.partesotti a yahoo.it>:

Giusto per completezza:http://punto-informatico.it/4302223/PI/News/libreria-glibc-bug-linux-sistemico.aspx


 

    Il Mercoledì 17 Febbraio 2016 9:04, Enrico Colombini <erix a erix.it> ha scritto:
 

 <<  we were able determine that the issue could result in remote code 
execution >>

https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

-- 
  .Erix.

-- 
Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com

   
--
Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com




   

   

   
--
Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com








  
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lugbs.linux.it/pipermail/lug/attachments/20160219/dcf72c0d/attachment-0001.html>