che palle!!!
La versione 3.2.11 e’ a posto? Ho aggiornato ieri un sito con
RefineryCMS
Grazie per le info
Davide
Integro con questo:
Vi racconto comunque una cosa, nel campo della security spesso si
predilige
l’approccio di disclosure dopo che la vulnerabilit stata notificata e
chi mantiene il codice ha rilasciato la patch.
Quindi di solito quando la patch rilasciata, l’exploit da considerarsi
pubblicabile.
Cos, giusto per dirvi l’approccio che di solito si usa lato security 
Detto questo Marcello, hai assolutamente ragione. Questo aggiornamento
da
fare al volo con priorit massima.
Ciao
Paolo
2013/1/10 Marcello B. (void) [email protected]
Non lo sharo perch sono stati gi distribuiti troppi dettagli in merito
Altro upgrade!
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
Non solo… se ci mettiamo a guardare Sinatra, Padrino, Datamapper…
chiss cosa troviamo… mi sa che tutto materiale per il mio blog
Paolo
2013/1/10 Sante Gennaro R. [email protected]
Anzi sono pronto a scommettere che se ci mettiamo una settimana a guardare
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
Postilla mia a quanto giustamente detto da Paolo, visto il numero di
persone che sta scrivendomi mail e/o sui social
Il fatto che in seguito alla prima vulnerabilit patchata siano emerse le
successive, con conseguente rincorsa alle patch/aggiornamento di una
marea di applicazioni RoR in giro, s un enorme rottura di scatole e
dispendio di tempo, ma da considerarsi una fortuna dato che adesso
queste vulnerabilit sono note e ne siamo al riparo in futuro, mentre
prima erano alla portata di qualsiasi hacker.
Anzi sono pronto a scommettere che se ci mettiamo una settimana a
guardare cos’altro c’ in giro in action pack, active record e soci, ne
troviamo un altro paio di cos gustose, ed quasi certamente questo
quello che hanno pensato quelli che hanno visto il primo cve pubblicato.
My two cents 
Sante
evviva i 0-days insomma…
siete degli hackeroni … 
Considerato il traffico sui sito che mantengo una SQL injection sarebbe
quasi un onore
D
2013/1/10 Davide R. [email protected]
Considerato il traffico sui sito che mantengo una SQL injection sarebbe
quasi un onore
purtroppo non si tratta (solo) di SQL-injection, lasciare rails
unpatched
puo’ portare all’esecuzione remota di comandi sul server
Qui c’e’ la spiegazione piu’ completa che ho trovato del bug:
http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
Luca
Ciao, riguardo il POC
il mio server (rails 3.2.11) mi dice
Hash::DisallowedType (Disallowed type attribute: “yaml”)
e’ male? e’ bene?
Secondo me e’ bene, ma ditemi voi che siete “sul pezzo”
Grazie
Davide
Rails 3.2.11 ha il fix per la vulnerabilit - quindi sei a posto :-).
Occhio solo alle regression che stanno venendo discusse qui:
https://github.com/rails/rails/issues/8832
Ciao
On Jan 10, 2013, at 1:55:57 PM, Davide R. wrote:
Ciao, riguardo il POC
il mio server (rails 3.2.11) mi dice
Hash::DisallowedType (Disallowed type attribute: “yaml”)
e’ male? e’ bene?
Secondo me e’ bene, ma ditemi voi che siete “sul pezzo”
~Marcello
2013/1/10 Marcello B. (void) [email protected]
Eventually - il POC con relative istruzioni per testare le vostre app
dopo update / patch in allegato :-).
grazie!
aggiungo solo che per chi ne avesse ancora online, che rails < 2.0 non
e’
vulnerabile (il parsing dell’xml non faceva typecast su yaml), mentre
rails
2.x < 2.3 e’ vulnerabile. Avendone bisogno ho portato la patch di rails
2.3
su 2.0, poi ci sarebbe da controllare di non avere attivato il YAML tra
i
default parsers: e’ disabilitato da rails 1.1.x, ma poteva essere
riabilitato con:
ActionController::Base.param_parsers[Mime::YAML] = :yaml #per rails <= 2
oppure:
ActionDispatch::ParamsParser::DEFAULT_PARSERS[Mime::YAML] = :yaml #per
rails >= 3
per disabilitarlo dovrebbe essere sufficiente mettere questo in un
initializer:
ActionController::Base.param_parsers.delete(Mime::YAML) #per rails <= 2
oppure:
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::YAML) #per
rails >= 3
infine… visto che la vulnerabilita’ e’ in activesupport non e’ solo
rails
ad essere interessato, ma anche padrino che usa activesupport
ciao,
Luca
2013/1/10 Marcello B. (void) [email protected]
Premesso che il “mondo security” fatto principalmente di fuffa e
celolunghismo :-), la mia personale visione di “responsible disclosure”
Dai… principalmente ma non sempre
sono almeno 3 giorni dalla pubblicazione della patch alla pubblicazione
dell’exploit.
S per considera questo.
Metasploit un prodotto usato anche in azienda, ad esempio assieme a
Nexpose per la parte di assessment. Avere a disposizione il modulo
subito
torna utile per chi fa ethical hacking dall’interno.
D’altro canto, riconosco che molti Ruby dev non siano affatto security
conscious, e quindi un’esperienza di compromise pu essere loro utile a
diventarlo.
Ecco, per io in questo caso non lo auspico.
Spero piuttosto che si siano letti questo (
CVE-2012-5664: Sql Injection on Rails... again | The Armored Code)
e dopo aver pensato “Che palle sto pippone sulla input validation”,
abbiano
detto… "mmmh… per magari tra 1 settimana pu saltar fuori un’altra
vulnerabilit su ActiveRecord e/o similia… se passo al mio ORM un input
fidato, posso andare pi soft con il patching e sono “pi robusto”
rispetto
agli 0 day.
Ancora: avere gi il modulo di metasploit far s che le aziende che
usano Rails e non hanno una policy che permetta di rispondere a queste
evenienze saranno sfondate, e questo pu esser visto come un “bene” per
la loro evoluzione - o come un “male” dato che dati saranno trafugati e
utenti truffati.
Assolutamente, il tuo punto di vista ha ovviamente senso… per in
questo
caso, che la patch fuori… quale sarebbe stato il tempo giusto per
pubblicare l’exploit? Siamo certi che in questo tempo tutti sarebbero
corsi
ai ripari?
Ciao ciao
Paolo
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
Se vi capita di avere applicazioni Rails molto vecchie ( 2.1.2 ), e non
avete tempo ora di aggiornare almeno alla 2.3,
possibile proteggersi come come descritto nel CVE:
E’ sufficiente mettere in un initializer:
ActionController::Base.param_parsers.delete(Mime::YAML)
e se non avete bisogno di parsare XML:
ActionController::Base.param_parsers.delete(Mime::XML)
Se invece dovete parsare XML:
ActiveSupport::CoreExtensions:
:Conversions::XML_PARSING.delete(‘symbol’)
ActiveSupport::CoreExtensions::Conversions::XML_PARSING.delete(‘yaml’)
(PS: correggetemi se sbaglio)
-f
Non ancora finita: anche multi_xml soffre del medesimo bug:
http://news.ycombinator.com/item?id=5040457
https://gist.github.com/d7f6d9f4925f413621aa
Se usate multi_xml per parsare XML che arriva dall’esterno, siete ancora
vulnerabili.
Buon aggiornamento,
~Marcello