XP, rush finale per il Service Pack 2

Microsoft sta per rilasciare quella che potrebbe essere l'ultima pre-release del secondo service pack per Windows XP, un update che dovrà assicurare un'ottima compatibilità con i software di sicurezza di terze parti


Redmond (USA) – Durante un recente incontro con la stampa, Microsoft ha detto di essere pronta a rilasciare, verso metà maggio, la seconda release candidate (RC2) del Service Pack 2 (SP2) per Windows XP. Come noto, le release candidate sono versioni praticamente definitive di un software in cui vengono corretti solo i bug più gravi e urgenti.

Microsoft sostiene che il rilascio della release finale dell’SP2 rimane fissato per la prima metà dell’anno, con buona probabilità verso la fine di giugno. Questo arco temporale potrebbe tuttavia spostarsi in avanti se, come ha ipotizzato da Microsoft, i tester ritenessero necessario rilasciare una terza release candidate.

Questo service pack è il primo nella storia di Microsoft a passare attraverso un vero e proprio programma di beta testing. L’impegno profuso dal colosso nel realizzare questo update è dimostrato dal tempo e dalle risorse dedicatovi, in parte sottratte al progetto di sviluppo della prossima versione di Windows, Longhorn.

Microsoft ha spiegato che sta lavorando a stretto contatto con i produttori di antivirus e firewall personali per assicurare la compatibilità fra le loro applicazioni e il Windows Security Center , un componente che verrà aggiunto a Windows XP dall’SP2 e che servirà per gestire tutte le principali funzionalità per la sicurezza da un unico centro di controllo. Microsoft sostiene che, attualmente, il Windows Security Center è in grado di riconoscere oltre il 70% degli antivirus sul mercato.

La compatibilità con le applicazioni di terze parti sarà un fattore importante anche per il buon funzionamento del Windows Firewall, un software che rimpiazzerà l’attuale Firewall connessione Internet integrato in Windows XP e potrà essere attivato anche in presenza di altri prodotti analoghi. Microsoft incoraggerà gli utenti ad attivare questa funzionalità per beneficiare del “boot security”, una caratteristica che, secondo l’azienda, è in grado di proteggere il PC dagli attacchi anche in fase di avvio.

L’SP2 conterrà anche nuovi filtri anti-spam e anti-script per Outlook e Outlook Express, nuove politiche di sicurezza per Internet Explorer e il supporto alla funzionalità di sicurezza implementata da AMD sulle proprie CPU a 32/64 bit.

Secondo Microsoft, l’80% del codice dell’SP2 riguarda la sicurezza, mentre il rimanente 20% è costituito da nuove funzionalità e aggiornamenti relativi, ad esempio, ad un miglior supporto dei dispositivi Bluetooth e dei Tablet PC.

A causa del cospicuo numero di cambiamenti introdotti dall’SP2, Microsoft ha stilato un documento Word di 156 pagine che descrive nei particolari l’impatto che queste modifiche potrebbero avere sul sistema e sulle altre applicazioni.

L’SP2 conterrà i venti fix di sicurezza rilasciati da Microsoft questo mese.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • fsdfs scrive:
    fsfs
    [url=http://www.inrolexwatches.com/rolex-datejust-c-2]Rolex DateJust watches[/url], Rolex DateJust watches [url=http://www.inrolexwatches.com/rolex-day-date-c-3]Rolex Day Date watches[/url], Rolex Day Date watches [url=http://www.inrolexwatches.com/rolex-daytona-c-4]olex Daytona watches[/url], Rolex Daytona watches [url=http://www.inrolexwatches.com/rolex-explorer-c-5]Rolex Explorer watches[/url], Rolex Explorer watches [url=http://www.inrolexwatches.com/rolex-gmt-c-6]Rolex GMT watches[/url], Rolex GMT watches [url=http://www.inrolexwatches.com/rolex-masterpiece-c-7]Rolex Masterpiece watches[/url], Rolex Masterpiece watches [url=http://www.inrolexwatches.com/rolex-milgauss-c-8]Rolex Milgauss watches[/url], Rolex Milgauss watches
  • fsdfs scrive:
    fsfs
    [url=http://www.inrolexwatches.com/rolex-datejust-c-2]Rolex DateJust watches[/url], Rolex DateJust watches [url=http://www.inrolexwatches.com/rolex-day-date-c-3]Rolex Day Date watches[/url], Rolex Day Date watches [url=http://www.inrolexwatches.com/rolex-daytona-c-4]olex Daytona watches[/url], Rolex Daytona watches [url=http://www.inrolexwatches.com/rolex-explorer-c-5]Rolex Explorer watches[/url], Rolex Explorer watches [url=http://www.inrolexwatches.com/rolex-gmt-c-6]Rolex GMT watches[/url], Rolex GMT watches [url=http://www.inrolexwatches.com/rolex-masterpiece-c-7]Rolex Masterpiece watches[/url], Rolex Masterpiece watches [url=http://www.inrolexwatches.com/rolex-milgauss-c-8]Rolex Milgauss watches[/url], Rolex Milgauss watches
  • Anonimo scrive:
    Re: uhm...sempre dubitare
    hai ragione,chiedo venia, ho linkato al pdf sbagliatoquello corretto e'quihttp://www.phenoelit.de/stuff/18C3.pdfScusateN0p- Scritto da: samu

    - Scritto da: Anonimo

    Non e' facile ne' immediato...

    ma possibile, anche se alla portata di
    pochi

    credo.



    "Routing and tunneling protocol attacks"

    by Fx dei Phenoelit.




    www.phenoelit.de/stuff/Phenoelit20c3.pdf


    bello .. peccato il pdf sia sui buffer
    overflow unicode...
  • Anonimo scrive:
    Re: Non è una novità

    maddaihttp://www.autistici.org/ginox/ipsec-howto/ipsec-howto.html
  • Anonimo scrive:
    Re: non e' cosi semplice
    - Scritto da: samu
    Questa vulnerabilita' permette unicamente di
    chiudere una connessione TCP tra due host;
    per utilizzare questa vulnerabilita' bisogna
    conoscere
    a priori:
    (supponendo una connessione A -
    B)
    1 Indirizzo IP della vittima A
    2 Porta sorgente vittima A
    3 Indirizzo IP della vittima B
    4 Porta destinazione Vittima B

    Ora, supponendo che si voglia bloccare tutte
    le connessioni di tutti gli utenti al sito
    punto-informatico,
    3 e' conosciuto ( www.punto-informatico.it)
    , 4 e' conosciuto ( 80 ) ma 1 e 2 no .
    1 e 2 sono dei valori molto grandi, nella
    fattispecie
    1 diventano gli IP italiani, 2 un valore
    compreso tra 1024 e 65536 ...
    Certo, uno puo' sparare a casaccio e sperare
    di beccarci ma i risultati non sono
    facilmente ottenibili...

    Diverso discorso per chi voglia invece
    chiudere una connessione IRC del tizio
    rompib***e ...
    in questo caso 1,3 e 4 sono a conosciuti ..
    basta "soltanto" inviare 65536 - 1024 *
    (intervallo SEQ) pacchetti ...Tutto vero! ma hai trascurato un piccolo (ma non insignificante) particolare devi avere banda sufficiente a effettuare il send di tali pacchetti abbastanza velocemente (in ogni caso piu' velocemente) di chi stai attaccando altrimenti NON FUNZIONA!Il che riporta la faccenda alla sua reale misura... e' praticamente molto difficile operare tale attacco con successo fuori dalla propria LAN....
  • sigsegv scrive:
    Re: UNIX and NetBSD wins
    - Scritto da: BSD_like
    www.netsys.com/cgi-bin/displaynews?a=720 "Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did not even check that a RST's sequence number was inside the window. RSTs anywhere to the left of the window were treated as valid."Sbaglio o ci stiamo preoccupando della serratura del cancello quando manca tutto il resto della recinzione? Qualcuno sa come sono messi gli altri sistemi basati sullo stesso stack e quelli, mmmh, ispirati?
  • samu scrive:
    Re: non e' cosi semplice
    - Scritto da: Anonimo
    sii più preciso: stai dicendo che
    è impossibile sniffare i pacchetti
    diretti a un sito preciso? e comunque lo
    sniffaggio avviene solo all'interno di una
    lan, quindi non posso sniffare dati del mio
    stesso subnet (ad esempio del mio router)?

    (non ti sto criticando, voglio solo saperlo)beh non ti resta che provare no ? se riesci a vedere i pacchetti di altri connessi al tuo provider oppure no...
  • samu scrive:
    Re: non e' cosi semplice
    - Scritto da: Anonimo
    La pericolosità sta nel chiudere le
    connessioni BGP fra router, specialmente
    quelli di ISP, backbones e grossi carrier in
    generale. In questo caso indirizzi IP dei
    router che usano il BGP e in diversi casi le
    porte possono essere facilmente reperite
    tramite tools di looking glass. questo solo se il router e' "aperto" a comunicarequeste informazioni a tutti .
  • samu scrive:
    Re: uhm...sempre dubitare
    - Scritto da: Anonimo
    Non e' facile ne' immediato...
    ma possibile, anche se alla portata di pochi
    credo.

    "Routing and tunneling protocol attacks"
    by Fx dei Phenoelit.

    www.phenoelit.de/stuff/Phenoelit20c3.pdf
    bello .. peccato il pdf sia sui buffer overflow unicode...
  • Di-Gi scrive:
    Ecco qui un exploit fresco fresco...
    TCP Connection Reset Remote Windows 2K/XP Attack Tool Source Codehttp://www.k-otik.com/exploits/04222004.reset.dpr.phpNon so quanto funzioni, ma c'è...
  • Anonimo scrive:
    Re: Ma come si fa?
    - Scritto da: Anonimo
    dove che si puo leggere tutta la relazione?
    voglio proprio vedere se e cosi facile
    mandare down tutta tutta la rete....Lascia perdere non hai banda a sufficienza! ;-)
  • Anonimo scrive:
    Re: Intanto CISCO avvisa i clienti...
    - Scritto da: Bejelit
    Ho letto sul sito della Repubblica (quanto
    sia affidabile l'articolo non lo so) che e`
    vero che era conosciuto, ma che appunto poco
    utilizzabile, solo che ora pare sia stato
    trovato un modo per sfruttarlo
    velocemente... non so i particolari cmq.Ti ripto non slo ho letto ma lo uso da tempo (sulle implementazioni che sono soggette)...Ripeto dove e' la novita? il punto sta tutto nell'azzeccare il "sequence number" giusto e per farlo devi avere anche un tot di banda! ;-)
  • Anonimo scrive:
    Re: Non è una novità
    - Scritto da: Anonimo
    perche` ipsec non gira sopra il tcp/ip?

    maddaiMaddai tu! ipsec (lo dice il nome oltre che i fatti) gira su IP capito? IP non TCP! :@ipsec lo puoi trasportare addirittura (vedi rfc nat-trasversal) su UDP !Altro che tcp!Studiare mai vero? :@
  • Anonimo scrive:
    Re: Non è una novità
    perche` ipsec non gira sopra il tcp/ip?maddai
  • Anonimo scrive:
    Ma come si fa?
    dove che si puo leggere tutta la relazione?voglio proprio vedere se e cosi facile mandare down tutta tutta la rete....
  • Bejelit scrive:
    Re: Intanto CISCO avvisa i clienti...
    Ho letto sul sito della Repubblica (quanto sia affidabile l'articolo non lo so) che e` vero che era conosciuto, ma che appunto poco utilizzabile, solo che ora pare sia stato trovato un modo per sfruttarlo velocemente... non so i particolari cmq.
  • BSD_like scrive:
    Re: UNIX and NetBSD wins
    Cmq va detto che per sfruttare il "buco" occorre parecchia banda.Era già stato teorizzato all'inizio degli anni '90, solo che era reso altamente improbabile (impossibile) per la poca banda a disposizione allora.Il progresso tecnologico l'ha reso più possibile; anche se di non facile sfruttabbilità.Si conferma UNIX, in particolare quelli *BSD che sono di base per lo studio delle tecnologie informatiche e non solo, come leader.Considerando che poi tutti pescano (ed implementano) da lì, è una bella conferma per l'open source.
  • BSD_like scrive:
    UNIX and NetBSD wins
    La notizia del "buco" l'avevo già letta ieri su netsys.Oggi ne arriva un'altra che sancisce la vittoria di UNIX e NetBSD in particolare nel rilasciare lo stack TCP/IP del kernel immune a questo attacco.http://www.netsys.com/cgi-bin/displaynews?a=720
  • Anonimo scrive:
    Re: Intanto CISCO avvisa i clienti...
    - Scritto da: Gianluca70
    Malgrado la complessita' per sfruttare il
    baco, da ieri CISCO sta avvisando tutti i
    propri piu' grandi clienti (sto parlando di
    fornitori di fonia cellulare italiani,
    indovinate quali sono...) degli
    impatti/problemi possibili sui loro
    apparati.
    A questo punto qualche dubbio comincia a
    sorgere...Sorgera' a te!Questo "bug" e' noto da secoli e io lo ho addirittura "sfruttato" diverse volte in piccole reti winzozz per fare "penetration test" e spacciarmi per una macchina con un certo ip (gia' utilizzato nella rete) .Non vedo la novita'!Il buco tuttavia non e' semplice da sfruttare (nella maggior parte dei protocolli applicativi) ed e' praticamente inusabile in una rete ad alto traffico dato che la "window" di numeri da predire aumenta in proporzione!;-)
  • Anonimo scrive:
    Re: non e' cosi semplice
    Mi sa che tra poco vedremo i CCIE iniziare a correre :-))
  • Anonimo scrive:
    uhm...sempre dubitare
    Non e' facile ne' immediato...ma possibile, anche se alla portata di pochi credo."Routing and tunneling protocol attacks"by Fx dei Phenoelit.http://www.phenoelit.de/stuff/Phenoelit20c3.pdfN0p- Scritto da: Anonimo

    - Scritto da: Anonimo

    sii più preciso: stai dicendo che

    è impossibile sniffare i
    pacchetti

    diretti a un sito preciso?

    Se non sei nello stesso dominio di
    collisione, si.
    L'unico modo e' quello di prendere il
    controllo di un router che smisti il
    traffico per quell'host.

    e comunque lo

    sniffaggio avviene solo all'interno di
    una

    lan, quindi non posso sniffare dati del
    mio

    stesso subnet (ad esempio del mio
    router)?

    Puoi solo sniffare pacchetti della tua
    stessa subnet, poiche' il traffico ip che ti
    raggiunge e' solo quello che il tuo router
    indirizza alla tua subnet. Non puoi invece
    sniffare il traffico che il router instrada
    verso altre subnet.

  • Anonimo scrive:
    Anche gli uomini non sono immortali
    Anche gli uomini non sono immortali. A chi dare la colpa di una morte prematura e violenta? All'uomo che non è in grado di soppravvivere ad una coltellata ben inferta, o a chi dà la coltellata?
  • Anonimo scrive:
    Dichiarazioni gonfiate,parziale smentita
    Leggere qui:http://news.com.com/2100-1002_3-5197184.html?tag=nefd.top
  • Gianluca70 scrive:
    Intanto CISCO avvisa i clienti...
    Malgrado la complessita' per sfruttare il baco, da ieri CISCO sta avvisando tutti i propri piu' grandi clienti (sto parlando di fornitori di fonia cellulare italiani, indovinate quali sono...) degli impatti/problemi possibili sui loro apparati.A questo punto qualche dubbio comincia a sorgere...
  • Anonimo scrive:
    Re: non e' cosi semplice
    Il problema non è tanto quello. Il vero problema sta nelle connessioni usate dal BGP per stabilire quali router sono attivi e quindi come instradare il traffico sui grandi carrier nazionali ed internazionali.Se va giù una connessione, in molti casi significa che il router non è più disponibile e va tagliato fuori dall'instradamento per un certo intervallo di tempo. Di conseguenza il rischio è che una fetta della rete venga tagliata fuori se più router si disconnettono in un breve lasso di tempo.
  • GNUuser scrive:
    Re: Non è una novità
    - Scritto da: Anonimo
    - Scritto da: Anonimo
    ...

    Il TCP non è nato per essere
    sicuro e

    quindi bisogna conviverci. Se volete la

    sicurezza usate IPSec.

    Ma in questo caso a che servirebbe IPSEC
    visto che si basa su Tcp/ip ed e` proprio
    quest'ultimo vulnerabile?TCP ed IP sono due protocolli differenti che operano a livello diverso.IPSec su basa su IP, non su TCP.
  • Anonimo scrive:
    Re: non e' cosi semplice
    Evidentemente non hai capito che la pericolosità di quella falla non sta nel chiudere le connessioni (http, ftp, irc o altro) fra due host o fra host e server. La pericolosità sta nel chiudere le connessioni BGP fra router, specialmente quelli di ISP, backbones e grossi carrier in generale. In questo caso indirizzi IP dei router che usano il BGP e in diversi casi le porte possono essere facilmente reperite tramite tools di looking glass. A questo punto si tratta di inviare pacchetti il cui numero di sequenza sia compreso nel range della "finestra" che la connessione in corso ha aperta. Più è grande la finestra e maggiore sarà la probabilità di trovarne uno che viene accettato. A questo punto il gioco è fatto.
  • Anonimo scrive:
    Re: non e' cosi semplice
    - Scritto da: Anonimo
    sii più preciso: stai dicendo che
    è impossibile sniffare i pacchetti
    diretti a un sito preciso?Se non sei nello stesso dominio di collisione, si.L'unico modo e' quello di prendere il controllo di un router che smisti il traffico per quell'host. e comunque lo
    sniffaggio avviene solo all'interno di una
    lan, quindi non posso sniffare dati del mio
    stesso subnet (ad esempio del mio router)?Puoi solo sniffare pacchetti della tua stessa subnet, poiche' il traffico ip che ti raggiunge e' solo quello che il tuo router indirizza alla tua subnet. Non puoi invece sniffare il traffico che il router instrada verso altre subnet.
  • Anonimo scrive:
    Re: non e' cosi semplice
    - Scritto da: samu
    Questa vulnerabilita' permette unicamente di
    chiudere una connessione TCP tra due host;econ la comunicazione inter router come la mettiamo? L'aggiornamento delle tabelle di routing non avviene con il tcp?
  • Anonimo scrive:
    Re: Non è una novità
    - Scritto da: Anonimo...
    Il TCP non è nato per essere sicuro e
    quindi bisogna conviverci. Se volete la
    sicurezza usate IPSec.Ma in questo caso a che servirebbe IPSEC visto che si basa su Tcp/ip ed e` proprio quest'ultimo vulnerabile?
  • KrecKer scrive:
    Re: non e' cosi semplice
    - Scritto da: Anonimo
    sii più preciso: stai dicendo che
    è impossibile sniffare i pacchetti
    diretti a un sito preciso? ora impossibile è un parolone, così su due piedi ti direi di si.
    e comunque lo
    sniffaggio avviene solo all'interno di una
    lan, quindi non posso sniffare dati del mio
    stesso subnet (ad esempio del mio router)?certo, è proprio nel tuo subnet che li puoi sniffare.Il tuo router sta nella tua stessa rete, quindi lo puoi sniffare.Ciao,
  • Anonimo scrive:
    Re: non e' cosi semplice
    sii più preciso: stai dicendo che è impossibile sniffare i pacchetti diretti a un sito preciso? e comunque lo sniffaggio avviene solo all'interno di una lan, quindi non posso sniffare dati del mio stesso subnet (ad esempio del mio router)?(non ti sto criticando, voglio solo saperlo)
  • Anonimo scrive:
    Ma quante falle .....
    Quante notizie di questo tiposono state pubblicate e non e' ancora sucesso nulla di grave!Di falle ce ne sono ovunque. Se qualcuno vuole fare dei danni non avrebbe nessun problema a trovarsi un tecnica.E comuque mi sembra che la patch vengano rilasciate quasi subito.Pero' ci sono sempre dei giornalisti (esperti) che vogliono annuciare la fine del mondo e quindi si attaccano a una qualsiasi notizia.Il vero problema peso sia propio il secondo (e non le falle).
  • samu scrive:
    Re: non e' cosi semplice
    - Scritto da: Anonimo
    Scusa la mia ignoranza, ma non basta
    mettersi li a sniffare i pacchetti?se il tizio non e' nella tua stessa lan, non riesci a sniffarei suoi pacchetti verso un qualsiasi sito.
  • Anonimo scrive:
    Re: non e' cosi semplice
    Scusa la mia ignoranza, ma non basta mettersi li a sniffare i pacchetti?
  • samu scrive:
    non e' cosi semplice
    Questa vulnerabilita' permette unicamente di chiudere una connessione TCP tra due host;per utilizzare questa vulnerabilita' bisogna conoscerea priori:(supponendo una connessione A -
    B)1 Indirizzo IP della vittima A2 Porta sorgente vittima A3 Indirizzo IP della vittima B4 Porta destinazione Vittima BOra, supponendo che si voglia bloccare tutte le connessioni di tutti gli utenti al sito punto-informatico, 3 e' conosciuto ( www.punto-informatico.it) , 4 e' conosciuto ( 80 ) ma 1 e 2 no .1 e 2 sono dei valori molto grandi, nella fattispecie 1 diventano gli IP italiani, 2 un valore compreso tra 1024 e 65536 ...Certo, uno puo' sparare a casaccio e sperare di beccarci ma i risultati non sono facilmente ottenibili...Diverso discorso per chi voglia invece chiudere una connessione IRC del tizio rompib***e ...in questo caso 1,3 e 4 sono a conosciuti .. basta "soltanto" inviare 65536 - 1024 * (intervallo SEQ) pacchetti ...
  • Anonimo scrive:
    Non è una novità
    Quella segnalata 2 giorni fa è solo uno dei tantissimi possibili attacchi dovuti alla intrinseca debolezza del numero di sequenza del TCP. Tutto questo scalpore non è giustificato. Fatevi un giro degli archivi delle vulnerabilità per averne un'idea.Il TCP non è nato per essere sicuro e quindi bisogna conviverci. Se volete la sicurezza usate IPSec.
  • Anonimo scrive:
    Re: Confondi TCP con IP
    C'è da dire però che IPv6 da specifiche prevede l'implementazione di ipsec in tutti gli stack "compliant". Pertanto l'utilizzo quasi indolore di ipsec impedirebbe di fatto lo sfruttamento di quella falla.
  • Anonimo scrive:
    relazioniamo a questo
    http://punto-informatico.it/p.asp?i=47876
  • Anonimo scrive:
    Confondi TCP con IP
    Con IPv6 la falla rimarrebbe!!!!!
  • Anonimo scrive:
    Re: peccato che non e' grave :-(((((
    Su questo ti sbagli... la gravità c'è. Certo si può correre ai ripari... ma come spesso accade si corre ai ripari solo quando il boss della società chiama d'urgenza i responsabili perchè la rete è crollata... in parole povere quando è già tardi.
  • Anonimo scrive:
    A chi interessa capire...
    Potete trovare un po' di spiegazioni tecniche su questo particolare attacco DoS qui:http://www.uniras.gov.uk/vuls/2004/236929/index.htmSfortunatamente i rischi sono reali soprattutto per quei router che non vengono aggiornati frequentemente (e sono più di quanto si possa credere) e non sono configurati per utilizzare la "TCP MD5 Signature Option" o meglio ancora "ipsec".
  • Anonimo scrive:
    peccato che non e' grave :-(((((
    magari fosse stata grave e irrisolvibilealmeno si poteva fare un pensierino a ipv6 o fastipbe dai
Chiudi i commenti