Newsgroup: it.comp.os.dibattiti
Titolo: "Sicurezza" di NT

and gain debug-leve access to the system
Since there was zero technical detail reported in that sentence
(and NT security types seem so reluctant to post source of sploits,
wonder why) we'll borrow from Microsoft's own security advisory:
  * Locates the memory address of a particular API function
   used by the DebugActiveProcess function.
So WindowsNT leaves a piece of memory wide open to reading and
writing that doesn't even contain _my_ data and then, in a context
of privilege, starts relying on code in that data range to execute
as designed?!  Oversight or _deep_ design flaw?
Where else is this known to happen in NT?  (Where is this not known
to happen but not known not to happen, if you get my drift?)
Does this mean that no Win32 programs that run with ANY sort of
privilege, be it user context, secret keys (ActiveX anyone?) or
business logic, can keep a secret if they load in evil DLL's?  Does
this extend to DLL's loaded from the search path?  Can DLL's be
preloaded into a process a la LD_PRELOAD (as seen in many Unices)?
Can this dangerous behavior of locally modifiable program text
be disabled?  Is Win32 irrecoverably insecure?
(These are all honest questions; answers will be gratefully
appreciated whether I'm on or off the mark.)
-jhp
PS: While we're on the subject, I notice that most NT sploits, once
they've got LSA context, tend to add themselves to the admin group.
It's weird.  If they were meant to be hacker's tools, there's SO
much more evil that can be wielded -- loading "device drivers",
shredding audit logs, and playing other merry havoc in ring 0, just
for starters.  If they were meant to be demonstrations of vulnerability,
there are far more benign things that a sploit could do --
st{op,art}ing the Gopher service, deleting particular named files
from C:\TEMP no matter whose they are -- that still demonstrates
divine power just fine without providing free fun for lazy script
kiddiez.
--
"Windows NT 4.0 is 16.5 million lines of code that will never be debugged."
  -Bill Joy
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

Non fa più "figo" postare in inglese ... crea confusione e basta.
Il messaggio è troppo, troppo, troppo lungo per poter essere letto su
Internet in ligua inglese e peraltro i termini utilizzati non sempre
sono di uso comune ed è un casino leggere un messaggio come questo.
Scuasami se te lo dico ... ma d'altra parte esiste pure il problema che
se io mastico l'inglese e tu anche questo non vuol dire che tutti lo
masticano.
-- 
Ciao ....
         Massimiliano ADAMO
Via F.P.Michetti, 1 - 20158 Milano --  Via G.Spontini, 51 - 97100 Ragusa
E-mail: 
maxa...@usa.net
 - 
maxa...@tin.it
 - 
maxa...@publispace.com

 wrote:
 >Non fa più "figo" postare in inglese ... crea confusione e basta.
Cosa ti aspettavi che lo traducessi?
 >Il messaggio è troppo, troppo, troppo lungo per poter essere letto su
 >Internet in ligua inglese e peraltro i termini utilizzati non sempre
 >sono di uso comune ed è un casino leggere un messaggio come questo.
 >Scuasami se te lo dico ... ma d'altra parte esiste pure il problema che
 >se io mastico l'inglese e tu anche questo non vuol dire che tutti lo
 >masticano.
Stiamo parlando di Internet e di sicurezza. Chiunque si occupi
professionalmente di queste cose e non e` in grado di leggere un
semplice testo in inglese come quello che ho forwardato dovrebbe essere
licenziato all'istante perche` e` un potenziale pericolo per i propri
clienti e per il resto della rete.


 masticano.
Molto bene. Fa qualcosa per migliorare il mondo! Traduci tu il
messaggio di Marco in Italiano, e postalo per tutti i
non-english-readers! 
Se non hai tempo, puoi sempre passarlo attraverso Babelfish.
Oppure, io mi ricordo male, e tu *NON* sei la stessa persona che ha
postato un lungo messaggio di Marketing, proveniente da un sito
microsloth, riguardante la certificazione C2 e *RIGOROSAMENTE IN
INGLESE* e con la subject line che diceva "NT4 is C2 certified"
(Subject falso, tra l'altro' perche' l'articolo diceva che NT4 sarebbe
stato certificato C2 presto) ????
Perche' se mi ricordo bene, allora dimmi quale tra le seguenti ipotesi
gistifica il fatto che non ti sia balenata l'idea di tradurlo...
i) Faceva ancora figo postare in inglese
ii) Il tuo messaggio era sufficientemente piu' corto di quello di
Marco da non creare confusione
iii) Il tuo messaggio faceva comodo a te, quindi andava benone.
Ma anche se mi ricordo male, e il msg. in questione non l'hai postato
tu, spiegami come mai in quell'occasione non sei insorto in difesa
della lingua Italiana, come ora.
E poi, postare in Inglese *FA* figo (almeno quanto postare in siciliano).
Cheers,
	Alessandro
-- 
One standard to rule them all, one standard to find them,
One standard to bring them all, and in darkness bind them.
In the land of Microsoft, where the Shadow lie.
Alessandro Forghieri              
http://www.orion.it/~alf

intrinsecamente insicuro.
Il tuo esempio non mi convince per nulla.Probabilmente e' colpa del mio
inglese ridicolo. E' vero che per motivi storici le DLL sono state e possone
essere usate come memoria shared, ma questo non vuol dire molto. 
La domanda corretta che dovresti fare e', puo' un processo *ostile* inettare
una sua dll nel mio spazio di indirizzamento? Se e' un administrator
ovviamente si (un *pochino* complicato n.d.p.). Se non e' si e'
administrator la negazione di questa possibilita' e' solo teorica. In
realta' si puo' fare, e vari crack mostrano questa capacita' di andare
nell'altrui spazi di indirizzamento.
Pero' non vedo questo grave problema architetturale. Mi sembra un problema
di implementazione.
Detto cio' ...
Personalmente credo che dovrebbero esserci tre ambienti di sviluppo in NT.
Quello per fare i drive (in kernell space), quello per fare i servizi, e
quello per fare gli applicativi.
Ecco, i servizi fanno uso degli stessi principi di sicurezza degli
applicativi, e trovo questo sbagliato. A livello di programma potere
infilare dll nei processi altrui ti permette personalizzazioni che un
sistema Unix si scorda (IMHO diversa filosovia di vita n.d.p.). A livello di
servizi ci vorrebbero regole molto piu' ferree.
Per la cronaca una servizio puo' non essere scritto per l'ambiente win32, ma
.. adesso basta. Il cocomero mi aspetta.
--- (Elimina il papero per le repliche) ---

papero...@tin.it
 wrote:
 >La domanda corretta che dovresti fare e', puo' un processo *ostile* inettare
 >una sua dll nel mio spazio di indirizzamento? Se e' un administrator
Non ne ho idea, ma il messaggio che ho forwardato non parla di questo,
la DLL non e` fornita dal cracker.
 >Pero' non vedo questo grave problema architetturale. Mi sembra un problema
 >di implementazione.
Visto che tutto NT e` fatto cosi` diventa un problema architetturale...


Visto che tutto NT e` fatto cosi` diventa un problema architetturale...
Se sbagli l'architettura finisce che fai prima a rifare il S.O. Uno sbaglio
di implementazione lo correggi strada facendo.
Non e' perche' qualche carneade si e' dimenticato di controllare la
dimensione del pacchetto di ping siamo davanti ad un difetto architetturale.
