Roma – La versione avanzata di Google Earth, che finora ha permesso a coloro che spendessero 399 dollari all’anno di sfruttare appieno i dati georeferenziati e le immagini satellitari di Google è ora disponibile gratuitamente.
Mountain View lo ha comunicato sul proprio blog ufficiale dedicato alle mappe: tutti gli utenti, professionisti e curiosi, aziende e pubbliche amministrazioni, potranno sbizzarrirsi nelle misurazioni e nella creazione di mappe personalizzate, nell’importazione e nella gestione di indirizzi, nell’elaborazione di informazioni sul traffico, di dati demografici e catastali, nella creazione di video e nella stampa di immagini ad alta risoluzione.
Per fruire del servizio e dei relativi strumenti professionali è ora sufficiente scaricare il client per Windows o Mac OS X e richiedere il codice di licenza : gli utenti hanno sperimentato qualche problema nella registrazione, che sembra risolversi con un semplice aggiornamento della pagina.
Coloro che avessero finora pagato per Google Earth Pro otterranno gratuitamente il rinnovo della licenza.
Gaia Bottà
leggi i 28 commenti
-
Re: GHOST, la falla che aleggia su Linux
- Scritto da: maxsix
Fiero di essere gay!maxsix, ce n'eravamo già accorti, non c'erano bisogno di ulteriori conferme. Non ho nulla contro i gay, però a questo punto vorrei chiederti: ma la cover dell'iPhone ce l'hai tutta rosa coi brillantini? -
GHOST, la falla che aleggia su Linux
GHOST, la falla che aleggia su Linux o GHOST, la falla che XXXXXXXXX su Linux?Meditate gente, meditate.-
Re: GHOST, la falla che aleggia su Linux
Meglio gay che linari! Fiero di essere gay!-
Re: GHOST, la falla che aleggia su Linux
- Scritto da: maxsix
Meglio gay che linari! Fiero di essere gay!Questo spiega molte cose di panda e della sua avversione verso i gay (rotfl)
-
-
-
Ma non era sicuro?
(rotfl)-
Re: Ma non era sicuro?
- Scritto da: Taphex Win
(rotfl)No, solo più sicuro di molti altri, chi pensa all'invulnerabilità è semplicemente: http://it.wiktionary.org/wiki/stupido -
Re: Ma non era sicuro?
- Scritto da: Taphex Win
(rotfl)Eh no! Quello sicuro è il kernel!Questo bug può rendere i server bucati come nemmeno il Gran Sasso, ma vuoi mettere la soddisfazione di poter comunque urlare "ma non è il kernel!111" con le lacrime agli occhi?-
Re: Ma non era sicuro?
- Scritto da: il piu grande comico vivente
Eh no! Quello sicuro è il kernel!
Questo bug può rendere i server bucati come
nemmeno il Gran Sasso, ma vuoi mettere la
soddisfazione di poter comunque urlare "ma non è
il kernel!111" con le lacrime agli
occhi?che poi tecnicamente parlando è il kernel bucato, perché se da una chiamata di libreria riesci a ottenere i privilegi di kernel, come appunta succede con questa falle, allora vuol dire che è il kernel ad essere buggato. Il codice tecnicamente esegue nel contesto del kernel, quindi contrariamente a quanto dicono i linari, è una falla di linux-
Re: Ma non era sicuro?
- Scritto da: malina
che poi tecnicamente parlando è il kernel bucato,
perché se da una chiamata di libreria riesci a
ottenere i privilegi di kernel, come appunta
succede con questa falle, allora vuol dire che è
il kernel ad essere buggato. Il codice
tecnicamente esegue nel contesto del kernel,
quindi contrariamente a quanto dicono i linari, è
una falla di linuxMi passi un proof of concept che dimostri la tua teoria ?-
Re: Ma non era sicuro?
- Scritto da: Pixel
Mi passi un proof of concept che dimostri la tua
teoria
?non serve un poc, basta vedere con ps in che contesto gira la libc: kernel! -
Re: Ma non era sicuro?
- Scritto da: malina
- Scritto da: Pixel
Mi passi un proof of concept che dimostri
la tua teoria ?
non serve un poc, basta vedere con ps in che
contesto gira la libc: kernel!Come ti fanno notare anche altri non basta. A meno che, naturalmente, non mi dimostri il contrario. -
Re: Ma non era sicuro?
- Scritto da: malina
non serve un poc, basta vedere con ps in che
contesto gira la libc:
kernel!HAHAHAHAHAHAHAHA cosa??????la libc gira in kernel mode? ma che 'azzo stai addì???la libc, in quanto libreria, gira nello stesso contesto del proXXXXX che l'ha richiamatae no, nessun proXXXXX utente gira in kernel mode o ha qualsivoglia tipo di acXXXXX allo spazio d'indirizzamento del kernel
-
-
Re: Ma non era sicuro?
teoria sbagliata, se fosse come dici tu otterresti l'acXXXXX a root con privilege escalation, invece ammesso che l'exploit funziona e che non ci siano strumenti come appmor, selinux, grsecurity che potrebberro ostacolare l'exploit, ti ritroveresti solo i permessi dell'utente specifico del server mail, quindi potresti manomettere soltanto esso, e dovresti trovare altri buchi aperti, altri exploit, il fatto che linux sia mediamente sicuro non significa che in ambito server non vanno prese ulteriori misure di sicurezza, come linux container che aggiungerebbe un ulteriore ostacolo. -
Re: Ma non era sicuro?
mamma mia, mamma mia, devo correggere questa serie di castronerie ( altrimenti qualche studente magari le legge e poi le va a raccontare al suo professore di sistemi operativi )1. questa falla non permette la privilege escalation2. questa falla permette l'iniezione ed esecuzione di codice da remoto NEL CONTESTO E CON I PRIVILEGI DEL PROXXXXX CHE VIENE BUCATO https://access.redhat.com/articles/13322133. il contesto del kernel ( come lo chiami tu ) non è l'esecuzione con privilegi di root ( sono due cose completamente separate e che stai confondendo alla grande )quindi caro amico, leggi prima qualche libricino come il Tanenbaum prima di sparare XXXXXte su un forum
-
-
-
Re: Ma non era sicuro?
Fincè i sistemi operativi saranno scritti da essere umani difficilmente un S.O. sarà sicuro al 100% . Chi dice il contrario non sa quello che dice, oppure è un markettaro...-
Re: Ma non era sicuro?
stessa cosa si può dire delle applicazioni.... -
Re: Ma non era sicuro?
- Scritto da: Il rettiliano ben informato
Fincè i sistemi operativi saranno scritti da
essere umani difficilmente un S.O. sarà sicuro al
100% . Chi dice il contrario non sa quello che
dice, oppure è un markettaro...O una persona poco intelligente, molto molto poco...Comunq, tutti discorsi già fatti:http://punto-informatico.it/b.aspx?i=3937484&m=3938168#p3938168 -
Re: Ma non era sicuro?
se si cominciano ad eliminare i linguaggi ad cazzum come il C, si può già fare un bel passo avanti
-
-
Re: Ma non era sicuro?
- Scritto da: Taphex Win
(rotfl)Senti, winaro di sta XXXXXXX, il tuo PC sarà probabilmente già dentro qualche botnet (come il 90% dei PC windows connessi in rete), per ogni falla trovata in una libreria o nel kernel linux ce ne saranno come minimo 3 dentro windows, con la differenza che queste ultime sono molto più difficili da scoprire vista la natura closed del sistema, e magari alcune nemmeno sono involontarie. Goditi la tua zombificazione digitale.-
Re: Ma non era sicuro?
- Scritto da: linaro_tant us_felix
- Scritto da: Taphex Win
(rotfl)
Senti, winaro di sta XXXXXXX, il tuo PC sarà
probabilmente già dentro qualche botnet (come il
90% dei PC windows connessi in rete), per ogni
falla trovata in una libreria o nel kernel linux
ce ne saranno come minimo 3 dentro windows, con
la differenza che queste ultime sono molto più
difficili da scoprire vista la natura closed del
sistema, e magari alcune nemmeno sono
involontarie. Goditi la tua zombificazione
digitale.ed ecco puntuale l'argomentazione i tuoi bug sono peggio dei miei.Come se questo cancellasse FIGURACCE lunghe 15 anni!
-
-
-
il massimo risultato per ora
il massimo risultato per ora ottenuto, con XML-RPC e pingback attivi, e' far crashare il sw.... interessante, ma non molto utile per i mass-exploiter lameroni...(ovviamente e' ora di fare un apt-get update ....) -
Ma è la libreria!
Ricordiamoci, è la libreria, non il kernel. E nessun attacco ancora noto, e mai ci sarà. E se c'è è l'amministratore che è un incapace.-
Re: Ma è la libreria!
Se compili un programma con una libreria buggata allora anche il tuo programma rischia di essere afflitto dallo stesso bug. Se l'interprete del PHP e' scritto in C allora anche le chiamate gethostbyname() rischiano di essere buggate. Se un programma buggato (web server, mail server, interprete, ecc.. ) gira con permessi elevati allora rischi di avere un sistema compromesso. E' un rischio da non sottovalutare sopratutto per la disclosure di informazioni sensibili: mail utenti, siti web condivisi, ecc..-
Re: Ma è la libreria!
- Scritto da: Massimo
allora rischi di avere un sistema compromesso. E'
un rischio da non sottovalutare sopratutto per la
disclosure di informazioni sensibili: mail
utenti, siti web condivisi,
ecc..si paga lo scotto di non utilizzare un sistema di sandboxing dei processi come fa Androidma c'è chi lo sa e sta provvedendo, come ad esempio Canonical con Ubuntu Core Snappy
-
-
Re: Ma è la libreria!
- Scritto da: Acciderbole
Ricordiamoci, è la libreria, non il kernel. è uguale, ti sfonda lo stesso il kernel essendo la chiamata eseguita a livello kernel.-
Re: Ma è la libreria!
- Scritto da: malina
- Scritto da: Acciderbole
Ricordiamoci, è la libreria, non il kernel.
è uguale, ti sfonda lo stesso il kernel essendo
la chiamata eseguita a livello kernel.http://punto-informatico.it/b.aspx?i=4218859&m=4219123#p4219123 -
Re: Ma è la libreria!
- Scritto da: malina
- Scritto da: Acciderbole
Ricordiamoci, è la libreria, non il kernel.
è uguale, ti sfonda lo stesso il kernel essendo
la chiamata eseguita a livello
kernel.uguale manco un po visto che se non riesci a trovare un servizio attaccabile che gira su root non lo vedi manco da lontano il kernel, al massimo puoi far crashare un servizio -
Re: Ma è la libreria!
rimando qui http://punto-informatico.it/b.aspx?i=4218859&m=4220046#p4220046 per correzione alle castronerie che questo tizio sta scrivendo
-
-
