On Tue, 27 Dec 2005 10:46:54 +0530, "Ramesh, MS-MVP"
Task Scheduler Does Not Run Tasks When "Run As" User Account Has No Password
http://support.microsoft.com/?kbid=311119
This is the start of what can be a safety DISASTER, for folks with no
interest in per-user passwords, especially on the Pro variant of XP.
If you don't want to be hassled with passwords, you have the "option"
of using a blank password. That means no logon prompt on startup or
after the screen saver kicks in, and has the safety factor of killing
remote (network, Internet, WiFi, etc.) access to "admin shares".
Admin shares are a menace - they break fundamental file sharing safety
principles by exposing all hard drive volumes to full access,
including locations from which dropped malware code would be run
automatically when Windows or applications start up.
Admin shares aren't remotely accessible in XP Home, but they are in XP
Pro if the account password is anything other than blank.
Tasks won't run unless a matching password is set - which is goodnews,
as it helps against malware that might drop hostile Tasks - but the
password must be non-blank.
Can you guess the rest, yet?
A user not wanting passwords at all, will have to have a non-blank
password in order to run Tasks (unless on SP1 or SP2 they use the "run
only when logged on" option, and the screen saver does not log out of
the account to return via Welcome screen). So they apply a trivial
password, and if smart, they hide even this via TweakUI autologon and
setting the screen saver not to resume via the Welcome screen.
With a trivial, non-blank password in place, attackers and malware can
easily break into admin shares and seed the system with malware.
There are several defences against this incredibly bad design:
- use a non-trivial password, then hide this via TweakUI etc.
- set Tasks to run when logged on, use blank password
- use XP Home if you don't need Pro's features
- disable hidden admin shares
- don't bind File & Print Sharing to TCP/IP
- don't bind File & Print Sharing to Internet connection
- use a NAT router if LAN cards also connect to Internet
A common problem is where the same LAN card is used to access the LAN
traffic, where File & Print Sharing (F&PS) is required, and the
Internet, where it most definitely is not. If you are forced to use
TCP/IP for F&PS, as seems to be the case in a hetrogenious (Win9x and
XP) LAN, then you can't block it via the local firewall. Your only
hope is that NAT will foil Internet access to those shares.
Disabling admin shares is an excellent idea if you do not use them,
but the setting is prone to being lost, should anything reset this to
the duhfaults - "just" re-installing Windows, av cleanups, etc.
---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
