NX Bit: novità dal fronte sicurezza per Microsoft

Nockmaar: dato che i buffer overflow non sono eliminabili, come non è possibile eliminare i bug, una soluzione di questo tipo è l'unica che ti garantisce un grado di affidabilità che prescinde dall'effettiva esposizione del codice al problema... sono mille volte più efficaci e proponibili soluzioni come il flag NX o il codice managed che pensare di avere su decine di milioni di righe di codice (indipendentemente dall'os) nemmeno un buffer esposto al rischio di overflow... a meno che la polemica sia strumentale... se tu dicevi "oltre al bit NX dovrebbero anche" era diverso (e sarei stato d'accordo), se ci vieni a dire "al posto di" evidentemente lo dici per un fine: polemica strumentale

imho hai ragione in generale, ma se non ho caipto male la news, non è un problema di workaround che magari a qualcuno non piace (perché si sente "insicuro" nel momento incui deve disabilitare l' nx bit per quel tipo di eseguibili o, al contrario, perché trova scomodo doverlo fare):

il problema è che a causa di quel controllo in ntdll.dll, se si eseguono eseguibili compressi con starforce & co l'nx bit è per forza inutilizzato in quel caso (indipendentemente dalle scelte dell'utente) venendo meno la protezione e la cosa offre ad esempio la possibilità(almeno teorica) ad un malware, che sfrutta un bug noto per un possibile buffer overflow, se compresso con quei sistemi, di funzionare anche con la copertura nxbit "totale" attivata.
(questo non per dire che sia una situazione ad alto rischio o meno, per definirlo servono sicuramente altre condierazioni statistiche e tecniche fuori dalla mia portata)

Volendo da parte di ms cambiare tale comportamento del sistema (come si dice nella news in via ufficiosa) e dato che da come è spiegato sembra basti rimuovere un controllo in ntdll.dll mi sarei aspettato un patch... invece (sempre ufficiosamente) si parla delle prossime versioni di Win x64 (Vista? XP x64 SP1 ?)...

Vero, ma probabilmente al momento della pacchettizzazione e distribuzione di xp non era nota l'esistenza del bug sul servizio unplug'nplay o altri casi analoghi, se no, per semplice buon senso , credo avrebbero distribuito con il bug già corretto o almeno con il servizio disabilitato di default.

beh, il plug&play dette problemi all' inizio, ora come ora difficilmente ne potresti fare a meno senza tanti traumi, data l' accoppiata con usb e hot swap

Lo Universal Plug'nPlay è una cosa, il Plug 'n Play un'altra

Premetto che il mio livello di conoscenza in questo ambito è abbastanza scarso..tuttavia...mi viene da dire: CHE SVISTA!

A cosa pensavano quando progettavano e scrivevano il codice del NX bit?

no, no, se leggi bene la notizia è chiaro che non è un svista, bug o come vuoi chiamarlo... è una "feature" (riciclando una battuta che spesso si fa per ironizzare )

Ma non è questo il caso, nel senso che è veramente una feature, una scelta consapevole e voluta, di lascire che quel particolare tipo di eseguibili, pur compiendo essi operazioni che la funzionlità nxbit previene a scopo precauzionale, funzionasse anche con protezione nx bit attivata.

(e non ho scritto le righe qui sopra per esprimere un concetto tipo:"buuuu! che errore! asini!", probabilmente ci saranno anche stati buoni(se non da quello della sicurezza da altri punti di vista) motivi a monte di tale scelta)

Sono due cose diverse... ASPack è un runtime packer (come UPX per intenderci) e ha poco a che fare con programmi quali WinRAR, WinZip, etc.

E perchè no? Ci sono molti router ormai che integrano il supporto allo Universal Plug & Play, e può risultare veramente comodo in determinate occasioni...