Neowin.net

eMachines, the third largest vendor of desktop PCs sold through U.S. retailers, has begun shipping its entire line of affordable, high-value PCs preloaded with the new Microsoft Windows XP operating system. The PCs start at $399 after manufacturer's rebate and are available from retailers nationwide.

All eMachines PCs have been qualified by Microsoft's Windows Hardware Quality Labs (WHQL) for meeting or exceeding the requirements for Windows XP and feature the Microsoft "Designed for Windows XP" logo on all product packaging.

As part of its new customer care initiative, eMachines is the first PC vendor to integrate the Windows XP "Remote Assistance" feature within its customer call center operations. With the customer's permission, the Remote Assistance feature makes it easy for users to receive the help they need by allowing eMachines' technical support personnel to directly evaluate, identify and resolve problems on the end-user's PC through an Internet connection, dramatically reducing customer call time and frustration.

eMachines' PCs also offers a clean, uncluttered desktop screen without unsolicited icons promoting third-party products and services. Based on eMachines' and Microsoft's research and experience, consumers prefer an uncomplicated desktop. (ed. :))

Pricing of various eMachines PC's are as follows...

• eMachines T1090 with Intel Celeron 900MHz CPU, 128MB SDRAM, 20GB hard drive, 56K built-in fax/modem and 48x CD-ROM drive (Price: $399 with $75 rebate)
• eMachines T1100 with Intel Celeron 1GHz CPU, 128MB SDRAM, 20GB hard drive, 56K built-in fax/modem and 8x CD-RW drive (Price: $499 with $75 rebate)
• eMachines T4150 with Intel Pentium4 1.5GHz CPU, 256MB SDRAM, 40GB hard drive, 56K built-in fax/modem and 8x CD-RW drive and Ethernet card (Price: $699)
• eMachines T4155 with Intel Pentium4 1.5GHz CPU, 256MB SDRAM, 60GB hard drive, 56K built-in fax/modem and 8x CD-RW/DVD combo drive and Ethernet card (Price: $799)

News source: CBS MarketWatch

This patch eliminates three vulnerabilities affecting Internet
Explorer. The first involves how IE handles URLs that include dotless
IP addresses. If a web site were specified using a dotless IP format
(e.g., http://031713501415 rather than http://207.46.131.13), and the
request were malformed in a particular way, IE would not recognize
that the site was an Internet site. Instead, it would treat the site
as an intranet site, and open pages on the site in the Intranet Zone
rather than the correct zone. This would allow the site to run with
fewer security restrictions than appropriate. This vulnerability does
not affect IE 6.

The second involves how IE handles URLs that specify third-party
sites. By encoding an URL in a particular way, it would be possible
for an attacker to include HTTP requests that would be sent to the
site as soon as a connection had been established. These requests
would appear to have originated from the user. In most cases, this
would only allow the attacker to send the user to a site and request
a page on it. However, if exploited against a web-based service
(e.g., a web-based mail service), it could be possible for the
attacker to take action on the user's behalf, including sending a
request to delete data.

The third is a new variant of a vulnerability discussed in Microsoft
Security Bulletin MS01-015, affecting how Telnet sessions are invoked
via IE. By design, telnet sessions can be launched via IE. However, a
vulnerability exists because when doing so, IE will start Telnet
using any command-line options the web site specifies. This only
becomes a concern when using the version of the Telnet client that
installs as part of Services for Unix (SFU) 2.0 on Windows NT(r) 4.0
or Windows(r) 2000 machines. The version of the Telnet client in SFU
2.0 provides an option for creating a verbatim transcript of a Telnet
session. An attacker could start a session using the logging option,
then stream an executable file onto the user's system in a location
that would cause it to be executed automatically the next time the
user booted the machine. The flaw does not lie in the Telnet client,
but in IE, which should not allow Telnet to be started remotely with
command-line arguments.