http://www.hardware.no/nyheter/desem...rhetshull.html
Noen som vet hvordan det virker litt mer detaljert?
Noen som vet hvordan det virker litt mer detaljert?
LOGG INN
... eller du kan registrere deg nå
Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang.
Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
|
5
1016
|
erm.. ville bare komme med en usaklig kommentar som er veldig offtopic (shoot me allready)..
skuffende at hardware.no først skriver om det 21/12.. dette hullet begynner å bli ganske gammalt.. dem burde kunne dekket en så viktig nyhet litt raskere.
pronte!
.......................
The first vulnerability is a buffer overrun vulnerability. There is an unchecked buffer in one of the components that handle NOTIFY directives – messages that advertise the availability of UPnP-capable devices on the network. By sending a specially malformed NOTIFY directive, it would be possible for an attacker to cause code to run in the context of the UPnP subsystem, which runs with System privileges on Windows XP. (On Windows 98 and Windows ME, all code executes as part of the operating system). This would enable the attacker to gain complete control over the system.
The second vulnerability results because the UPnP implementations don’t sufficiently limit the steps to which they will go to obtain information on using a newly discovered device. Within the NOTIFY directive that a new UPnP device sends is information telling interested computers where to obtain its device description, which lists the services the device offers and instructions for using them. By design, the device description may reside on a third-party server rather than on the device itself. However, the UPnP implementations don’t adequately regulate how it performs this operation, and this gives rise to two different denial of service scenarios:
An attacker could send a NOTIFY directive to a UPnP-capable computer, specifying that the device description should be downloaded from a particular port on a particular server. If the server was configured to simply echo the download requests back to the UPnP service (e.g., by having the echo service running on the port that the computer was directed to), the computer could be made to enter an endless download cycle that could consume some or all of the system’s availability. An attacker could craft and send this directive to a victim's machine directly, by using the machine's IP address. Or, he could send this same directive to a broadcast and multicast domain and attack all affected machines within earshot, consuming some or all of those systems' availability.
An attacker could specify a third-party server as the host for the device description in the NOTIFY directive. If enough machines responded to the directive, it could have the effect of flooding the third-party server with bogus requests, in a distributed denial of service attack. As with the first scenario, an attacker could either send the directives to the victim directly, or to a broadcast or multicast domain.
skuffende at hardware.no først skriver om det 21/12.. dette hullet begynner å bli ganske gammalt.. dem burde kunne dekket en så viktig nyhet litt raskere.
pronte!
.......................
The first vulnerability is a buffer overrun vulnerability. There is an unchecked buffer in one of the components that handle NOTIFY directives – messages that advertise the availability of UPnP-capable devices on the network. By sending a specially malformed NOTIFY directive, it would be possible for an attacker to cause code to run in the context of the UPnP subsystem, which runs with System privileges on Windows XP. (On Windows 98 and Windows ME, all code executes as part of the operating system). This would enable the attacker to gain complete control over the system.
The second vulnerability results because the UPnP implementations don’t sufficiently limit the steps to which they will go to obtain information on using a newly discovered device. Within the NOTIFY directive that a new UPnP device sends is information telling interested computers where to obtain its device description, which lists the services the device offers and instructions for using them. By design, the device description may reside on a third-party server rather than on the device itself. However, the UPnP implementations don’t adequately regulate how it performs this operation, and this gives rise to two different denial of service scenarios:
An attacker could send a NOTIFY directive to a UPnP-capable computer, specifying that the device description should be downloaded from a particular port on a particular server. If the server was configured to simply echo the download requests back to the UPnP service (e.g., by having the echo service running on the port that the computer was directed to), the computer could be made to enter an endless download cycle that could consume some or all of the system’s availability. An attacker could craft and send this directive to a victim's machine directly, by using the machine's IP address. Or, he could send this same directive to a broadcast and multicast domain and attack all affected machines within earshot, consuming some or all of those systems' availability.
An attacker could specify a third-party server as the host for the device description in the NOTIFY directive. If enough machines responded to the directive, it could have the effect of flooding the third-party server with bogus requests, in a distributed denial of service attack. As with the first scenario, an attacker could either send the directives to the victim directly, or to a broadcast or multicast domain.
|
|