I myself quickly switched from the Voodoo3 to a GeForce2 GTS not long before 3Dfx folded. I was informed and wary of the better chips appearing at the time. These days it's difficult to stay informed and make that purchasing decision with a somewhat degree of satisfaction with companies like NVIDIA, ATI and now SiS all wanting a slice of the graphics pie.

I dont know if this has been posted previously but I just read a fantastic review over @ Maxreboot on the ATI Radeon 8500 64MB DDR card which kind of makes me want one of these instead of the expensive GeForce3 Ti500 or Geforce4 (not MX) series. I am looking to upgrade soon so I have been looking at these types of reviews.. Comments are welcome.

Snip from the review: The ATi Radeon 8500. Until recently, arguably the fastest video card manufactured for gamers. Today we will be taking a in depth look at the Radeon 8500. We will probe and pock it in every way possible and see if it lives up to its reputation. Recently ATi released the "All In Wonder" Radeon 8500 and we have seen a steady stream of reviews. But not all of us need the video editing / TV tuner functions and certainly not all of us is willing to break the bank for it. ATi sent us the Radeon 8500 because they think that there is still a lot of potential left from this card. Maybe not as the "Ultimate gaming Video card", but more like the "Video card for the rest of us".

View: Ati Radeon 8500 64mb DDR review @ Maxreboot

unlike previous exploits that went unanswered this one saw a prompt response:

Vendor response:
Finjan Malicious Code Research Center had an interesting discussion with Microsoft Security Response Center. This is their response:

Hi, Thanks very much for your note and for sending this on. We really appreciate it. To understand the issue fully, it would be good to expand this somewhat. There really are two issues here: One related to the ability to mount an attack successfully, and one related to how data is stored on a system and what could happen to that in light of a successful attack. To be clear, none of the attack scenarios that you've described are mounted through MBSA itself. Also, the attack you've described does not exploit a vulnerability in any product: in a default system this attack fails. It's only when a user chooses to run code from an untrusted source and proceed despite the security warnings provided that this attack could succeed. Protecting systems against untrusted code is vitally important, and we call this out in our 10 Immutable Laws of Security as Law #1 ( http://www.microsoft.com/technet/columns/security/10imlaws.asp ), to underscore its importance. If an attacker were able to convince a user to run their code, that code would then be able to take any actions on the system that the user can take. While it is true that MBSA stores its information in a known location, storing it in an unpredictable location would not measurably change the situation. An attacker's code could just as easily search the local system for the file. Likewise, it is true that MBSA's information can be read by the user (or code running as the user). However, even if the MBSA information were not present on the system, code running as the user would be able to determine the presence or absence of patches, simply by consulting the time/date information contained in the publicly available MSSecure XML database. Again, it is a question of degree rather than feasibility. The larger issue in both cases is the presence of code running with the user's privileges. If the attacker cannot run code, it does not matter how the MBSA data is stored, because the attacker cannot access it. If the attacker can run code, he or she does not need the MBSA data, as they already have all the privileges needed to duplicate the MBSA processing. (For that matter, the attacker could simply run MBSA itself and do a "screen scrape"). That said, we are always looking to make improvements and we appreciate concerns and feedback like this. Our MBSA team is looking at these suggestions along with others that we have received and consider them as they design future versions of this tool.
Thanks again for sending this on, we really appreciate it.
Regards,
secure@microsoft.com


There are 2 additional comments
Advertisement


Commenting has either been disabled on this article or you are not logged in. Click here to login or register, its free!

Note: Anonymous commenting is disabled in order to keep the quality of responses to a high standard.


Scroll to the Top
....
My Preferences
....
Communicating with server
Loading
Please Wait...
....
Loading
 X 
....