Posted By: imekon | Aug 25th, 2004 @ 11:25 AM
page 1 of 1
Comments: 5 | Views: 6790
imekon
imekon
Bah humbug!
Is this likely to be the last we hear about this?
Well, as soon as I read the phrase in the article "Of course we made that last part up." I stopped reading.  What I don't get is why Microsoft is not addressing the real vulnerabilities...lighting strikes, floods, like that.  I mean, all they would have to do is put some pontoons around the PC tower, and have it float to whatever the water level rises up to in your house.  Wait, those are hardware issues.
My rebuttal at http://mikedimmick.blogspot.com/2004/08/i-knew-something-was-bugging-me.html.

Basically, in order to exploit it, the code would have to be running as an administrator, at which point you've already lost - what's the point of faking the firewall status when the code can use the firewall APIs to open a port? Or it can install device drivers, or a rootkit?

Everyone should be running as a Limited User. If you're not, go change it now. Aaron Margosis has a useful pair of batch files at http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx for temporarily putting yourself into the Administrators group in order to launch a new command prompt. He also has a useful IE/Explorer toolbar at http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/195350.aspx for showing your current privilege level.
I read your links, interesting.. but I have tried running as a user and had to give it up.

I don't blame Windows, instead I blame software developers that ONLY test and develop their software for administrator level accounts. Clearly anything used in a corp. environment will be tested and will work fine but most of the software I have issues with was never tested or designed in this way.

Some games have this issue, even modern ones.. you will go onto the support pages and they simply put 'X must be launched from an administrator level account'.
How true that is Manip.

Simple example: I play Asheron's Call.  A month ago, it worked perfectly as a non admin. 

Then someone over in the zone made some changes to their launching tools and now you can't run AC as a non admin - AC still works just fine, but the launching program tries to delete a file that's got an admin-only ACL on it.

Sigh.
So use Run As or Aaron's makemeadmin batch file as appropriate. Alternatively work out what the problems are. For this, tools like FileMon and RegMon are really useful.

When I wrote the post above, I lied a little. I'd stopped being an Administrator at home but not at work. I've now switched over - most things are still working.

I have noticed that VS.NET 2003's Smart Device debugging requires you to have administrative rights the first time you connect to a particular device (and after cold booting the device) but is fine after that - I think it's establishing a new key-pair for encrypting the connection. eMbedded Visual C++ 3.0 complains that no SDKs have been installed; eVC 4.0 says 'Failed to connect the Drop-in CPU database'.

eVC 3.0 can be fixed by allowing Users to write to %ProgramFiles%\Microsoft eMbedded Tools\Common\EVC\Bin (so that Jet can write a .LDB lock file) and allowing Users full control on the HKEY_LOCAL_MACHINE\Software\Windows CE Tools\Platform Manager key and subkeys. The problem on that last one is that the code asks for KEY_ALL_ACCESS when it only appears to need KEY_READ. The remote tools (CE Remote Registry Editor etc) don't have this problem.

Unfortunately eVC 3.0 will no longer be serviced, despite being required to support Pocket PC devices more than a year old.

I also had to allow the Awasu news aggregator to write to its Users directory, below its install directory in Program Files. Its support for the feed: URL scheme no longer works but then it didn't work on XP SP2 anyway because it requires a firewall exception...
page 1 of 1
Comments: 5 | Views: 6790
Microsoft Communities