Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Sparalink #5

-quack

Potrebbero interessarti anche:
Commenti (5):
1. navigatore_solitario
sabato 8 dicembre 2007 alle 10:05 AM - unknown unknown unknown
   
   
2. FDG
giovedì 13 dicembre 2007 alle 6:11 PM - unknown unknown unknown
   

Grazie dell'ultimo link. Ho sostenuto, e questo link rafforza la mia opinione, che il problema maggiore è purtroppo nella debolezza del meccanismo che sta alla base del passaggio dei parametri. Mi viene in mente una cosa a proposito dei compilatori Microsoft: se ci si premura di far comparire dei warning nell'usare delle funzioni standard C che non ci difendono dai buffer overflow, cosa che dimostra una certa attenzione rispetto alle problematiche di sicurezza, allora si potrebbe pure aggiungere una chiamata di sistema che permetta di specificare singolarmente i parametri della shell così da proteggersi da potenziali errori nel codice altrui, codice su cui Microsoft ha poco controllo.

Spero questa volta di esser stato chiaro. La mia è una critica costruttiva... almeno spero.

p.s.: in .net 3 l'equivalente chiamata che interfaccia ha?

   
3. Paperino
giovedì 13 dicembre 2007 alle 11:53 PM - unknown unknown unknown
   

@FDG:

la tua critica è molto interessante e ricca di spunti. Le due soluzioni diverse hanno vantaggi diversi, non avendole provate entrambe non posso neanche esprimere un parere *soggettivo* su quale sia il sistema migliore. Tra l'altro questo non diminuisce assolutamente la responsabilità di chi scrive codice su una qualsiasi piattaforma facendo riferimento ad una piattaforma diversa: in Windows il passaggio di parametri avviene via stringa, far finta che non sia così non porta da nessuna parte. Smile

Dal punto di vista puramente della sicurezza il vero punto è un altro: chiunque riceva parametri dall'esterno deve considerarli come potenziali vettori di attacco, senza se e senza ma ed indipendentemente da come vengano passati. I commenti al post di cui parli poi sono molto illuminanti.

In .Net i parametri vengono separati in array di stringhe ma non lasciarti trarre in inganno, si tratta di "syntactic sugar". Prima di essere parsati erano un'unica stringa. E se crei un processo via C# devi usare un'unica stringa per passarli al processo figlio ( msdn2.microsoft.com/.../h6ak8zt5.aspx ). Spero sia stato chiaro visto che la faccenda è alquanto intricata. Wink

   
4. FDG
venerdì 14 dicembre 2007 alle 2:53 PM - unknown unknown unknown
   

Eliminando un problema a monte (uno, non tutti) sei meno soggetto all'irresponsabilità altrui. Cercare un paradigma migliore è un metodo per affrontare certe problematiche. Esempio: void* VS ByteArray (ti parlo in Java perché conosco questo). Nella prima condizione si è costretti a dire che i programmatori devono essere responsabili. Nella seconda ti trovi comunque in una situazione migliore che nell'altra anche considerando tutti i programmatori responsabili. In pratica, ce la possiamo prendere con gli sviluppatori di Firefox, ma purtroppo non possiamo dimenticarci di tutti gli altri. Abbiamo un elenco completo degli irresponsabili? Quanto siamo sicuri che sia completo? Certo, mi ripeterai, questo non risolve tutti i problemi di interpretazione dei parametri. Si, vero, ma risolve un problema che potenzialmente riguarda tutte le applicazioni. Magari, studiando bene la problematica si potrebbero scoprire altri potenziali problemi e trovare modi adeguati di affrontarli. Io non mi limiterei a difendere una scelta fatta anni e anni or sono. E poi stiamo parlando del modo in cui dei processi comunicano, non del modo in cui un utente scrive una linea di comando testuale.

   
5. Paperino
venerdì 14 dicembre 2007 alle 5:33 PM - unknown unknown unknown
   

Il tuo atteggiamento è troppo ottimista per vari motivi di cui te ne elenco un paio:

che il passaggio di parametri sia l'elemento chiave della questione che avrebbe eliminato il problema. Non mi sembra così perché il nocciolo della questione era la chiave del registry che è rappresentata come stringa. Eliminiamo anche le stringhe dal sistema operativo perché passibili di SQL injection?

che provvedendo una nuova API (immagino in aggiunta a quella vecchia se non si vuole rompere il 99% delle applicazioni esistenti che prendono parametri) alcune applicazioni ne avrebbero fatto immediatamente uso. Questa l'ho già sentita vedi protected mode e ti assicuro che non ha funzionato.

Se guardi l'ingenuità di tutti gli elementi in questione (perché aggiungere un nuovo handler? Che senso hanno le cazzate di Window e di Shrep?) l'unica cosa che può fare il sistema operativo per salvare gli utenti da "quelli sicuri" è evitare che certe applicazioni vengano lanciate. La mia è cattiveria però. Smile

Però in generale sono d'accordo con te con misure a tappeto invece che patch all'occorrenza.

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)