Newsgroup: it.comp.os.dibattiti
Titolo: LOL

http://news.wintricks.it/web/patch-prodotti-microsoft/28307/windows-7-problemi-con-luac/
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
http://news.wintricks.it/web/patch-prodotti-microsoft/28307/windows-7-problemi-con-luac/
Non capisco cosa intenda l'articolo con 'attacchi remoti'. La PoC e` un
VBS con SendKeys che simila una sequenza di azioni da tastiera. Immagino
vada eseguita dall'utente.
Se il livello e` inferiore di High il sistema non richiede una conferma
delle modifiche al sistema; tra cui a UAC.
Se si e` loggati come amministratori: altrimenti chiede come al solito
una password, quindi la soluzione e` come sempre avere account separati.
O se proprio si tiene ad usare l'admin, tenere la protezione alta.
Quello che infastidisce Zheng di 
istartedsomething.com
 e` che la cosa
potrebbe 'aggirata' rimuovendo in qualche modo il pannello UAC dalla
whitelist in modo che richieda SEMPRE una conferma.
Tuttavia oggi Rivera di 
withinwindows.com
 indica altre possibili falle
nell'approccio ad eseguibili "segnati"; che comunque funzionano sempre a
patto di loggarsi come admin.
Io a MS criticherei piuttosto di non forzare il setup di due utenti
admin e standard, e di non richiedere una password di default
sull'admin.
Ora lancio il sasso, nascondo la mano, e paro le bastonate (:D) : per
curiosita`, supponendo di loggarmi come root su un qualche *NIX dove
sudo sia disponibile, non e` concettualmente altrettanto semplice
aggiungere :NOPASSWD nel sudoers via script?
Ciao!

 aggiungere :NOPASSWD nel sudoers via script?
Ni, nel senso che il file e` di proprieta` di root ed ha i permessi
impostati in sola lettura per l'utente ed il gruppo. In queste
condizioni, un eventuale attacco del genere deve tenere conto di questi
fattori:
- Lo script deve contenere o la password di root, o la password
  di uno degli utenti che possono utilizzare sudo.
- Lo script deve prima impostare i permesis in scrittura sul file.
Se il secondo punto e` abbastanza banale, il primo scoraggerebbe
praticamente tutti ad attuare un attacco del genere. Inoltre, bisogna
sempre considerare una cosa: non tutte le distribuzioni usano e/o hanno
installato sudo, di conseguenza bisogna tener conto anche di questo
particolare non indifferente
Enrico

 fattori:
Vero, vero, infatti premettevo il 'loggarmi come root';  volevo
semplicemente dire che queste 'falle' sono a mio parere piu` legate
alla perversione del login come amministratore che Windows continua a
privilegiare, piuttosto che al sistema in se` vero e proprio :)
ciao

 privilegiare, piuttosto che al sistema in se` vero e proprio :)
Questo perché i criticoni non sono mai contenti e Microsoft fa l'errore 
di dar loro retta. UAC andava benissimo com'era in Vista: la sua 
invadenza era principalmente dovuta a programmi scritti coi piedi che, 
invece di funzionare tranquillamente in user space, chiedevano i 
privilegi di amministratore per eseguire qualsiasi stronzata, 
pretendevano di scrivere all'interno della propria cartella (invece di 
usare le cazzo di cartelle utenti come MS dice di fare da anni), più 
tutta una totalità di piccole e grandi idiozie che gli utenti stessi, 
abituati a usare il PC alla cazzo, facevano senza comprendere 
l'importanza di essere amministratori in quel momento.
Chi ha usato Vista per tutto 'sto tempo si sarà certamente accorto che, 
con il passare del tempo e con l'uso di software scritto meglio, gli 
interventi di UAC si sono già ridotti al minimo indispensabile per conto 
loro. E, chi vuole, può sempre disattivarlo e tanti saluti.
L'UAC di Sette non è nient'altro che l'UAC di Vista con impostazioni 
meno restrittive, lo si poteva già ottenere da Vista in quel modo 
smanettando nel pannello di controllo, alla voce "Strumenti di 
amministrazione". Ed, essendo meno restrittivo, apre la strada a 
possibili falle di sicurezza. Chi vuole, però, può rimettere anche l'UAC 
di Sette allo stesso livello di guardia di quello di Vista, chiudendole 
immediatamente. Insomma, più che accusare Microsoft di attuare una 
politica troppo permissiva direi che la sua unica colpa è quella di dare 
retta ai whiners che, sui forum, attaccano Vista perché "UAC è un 
rompiballe", senza nemmeno capire quanto certa pedanteria sia salvifica 
in diversi casi.
Così si attira le critiche dei maniaci della sicurezza. Non si può 
accontentare tutti, qualcuno comunque si lamenterà.
p.bes

 accontentare tutti, qualcuno comunque si lamenterà.
Ti do` ragione su tutto. IMO 'soluzioni' che MS dovrebbe adottare per il
problema attuale sono due, eventualmente alternative:
1) livello di sicurezza alto di default (uguale a Vista)
in modo tale che lo smanettone cacaca**i possa abbassarlo e poi
lamentarsi come fa di solito :D (pero` almeno gli si puo` dire che se e`
un cialtrone doveva tenerlo alto)
2) creazione di default del secondo utente standard (vs. Admin *con
password*), e 'spiegare' in qualche modo l'importanza di questa
separazione. 
Quest'ultima e` la parte ovviamente piu` difficile dato che
nell'ambiente casalingo non e` un setup tipico.

 
http://news.wintricks.it/web/patch-prodotti-microsoft/28307/windows-7-problemi-con-luac/
NeoWin
http://www.neowin.net/news/main/09/02/05/microsoft-update-on-windows-7-uac-issues
Risposta direttamente da Engineering Windows 7:
http://blogs.msdn.com/e7/archive/2009/02/05/update-on-uac.aspx
In effetti e` vero che un VBS creato in locale non genera (giustamente!)
nessun messaggio di avvertimento, mentre quello proposto da Rivera no
(anche se e` linkato come .txt, il flag 'not trusted' sopravvive!)

 
http://blogs.msdn.com/e7/archive/2009/02/05/update-on-uac.aspx
...e infine:
http://blogs.msdn.com/e7/archive/2009/02/05/uac-feedback-and-follow-up.aspx
| With this feedback and a lot more we are going to deliver two changes to
| the Release Candidate that we’ll all see. First, the UAC control panel
| will run in a high integrity process, which requires elevation. That was
| already in the works before this discussion and doing this prevents all
| the mechanics around SendKeys and the like from working. Second,
| changing the level of the UAC will also prompt for confirmation.

 nemmeno capire quanto certa pedanteria sia salvifica in diversi casi.
A parte gli scherzi:
http://www.tomshw.it/news.php?newsid=13715
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 
http://www.tomshw.it/news.php?newsid=13715
Meno male non hai solo citato "UAC e` progettata per rompere le scatole
agli utenti", altrimenti semplicemente non avresti centrato il punto. 
L'idea e` che i produttori si sarebbero resi conto che se i loro programmi
scritti MALE gli utenti non fossero stati corretti, gli utenti si sarebbero
lamentati.
L'unico difetto e` che cosi` la colpa e` stata imputata al SO piu` che ai
programmi.
Ciao

 lamentati.
fix'd :D

 programmi.
Infatti.


 Ma infatti non era minimamente mia intenzione.
:) 
allora chiedo venia, nella maggior parte delle 'discussioni' viene fuori
solo come argomento a sfavore (praticamente a sproposito)
ciao!

 
http://blogs.msdn.com/e7/archive/2009/02/05/uac-feedback-and-follow-up.aspx
La saga pero` continua, perche` e` comunque possibile che eseguibili non
segnati iniettino codice in eseguibili non-segnati.
PoC e screencast:
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
http://www.withinwindows.com/2009/02/05/list-of-windows-7-beta-build-7000-auto-elevated-binaries/#comment-2432
| I’ve finished my proof-of-concept code now.
| 
| This allows:
| 
| - Any *unelevated* process
| - On an x64 or x86 Windows 7 with default settings
| - To create elevated COM objects without any UAC prompts
| - Using code injection into *any* process that is flagged for silent elevation.
E' un cane che si morde la coda...