Disabling automatic Windows logout

Today, my IT department set my Windows desktop up to automatically lock up and require entry of my password after an idle timeout. No big deal -- this sort of thing happens all the time and is, of course, usually blamed on Sarbanes-Oxley.

Well, for me it was a slightly bigger deal for a couple of reasons:

1. My Windows desktop actually runs under my Linux desktop. It's a virtual machine running under VMWARE.
2. Although IT advertised the timeout as 60 minutes, in reality, it was closer to 10 for me.

After a lengthy email exchange, I finally got IT to admit it is really a technical issue -- they need to lock down all the desktops on the domain, they (for some reason) can't distinguish virtual ones from real ones, and that's the way it is. (No word on why the timeout is so short, though.)

Obviously, technical issues call for technical solutions. Here's mine. By the way, it would be very unethical to use this on a "real" Windows desktop as opposed to a virtual one :)

All these steps should be taken inside the Windows VM. If you have a fast internet connection, you should be set up in under 5 minutes:

1. Run the installer for Python:
   http://python.org/ftp/python/2.5.2/python-2.5.2.msi
   
   
   
2. Run the installer for SendKeys:
   http://www.rutherfurd.net/python/sendkeys/SendKeys-0.3.win32-py2.5.exe
   
   
3. Save the following Python script to a file:

import time
from SendKeys import SendKeys

while 1:
  print "Did it again"
  SendKeys('{CAPSLOCK}{CAPSLOCK}')
  time.sleep(5*60)



4. Run the file, e.g. by double-clicking on it.

This script will virtually press the caps lock key twice on the window with the focus, once every 5 minutes. Adjust to taste. You can minimize it after you run it, you can run it at startup, etc.

I have to admit that the idea of using the caps lock key is not original with me. I saw it somewhere, but I cannot remember where at the moment. Anyway, it works great, even when the key is pressed while you are typing.

Security and sector lockdown

I would love to believe that most technical people and technical companies are too smart to succumb to the sort of security theater which is foisted on us by Homeland Security and the TSA.

Unfortunately, I am having a hard time sustaining that belief in the face of hard facts.

Today's example of technical people doing things which ostensibly aid security, but which really just give aid and comfort to the enemy, comes from chip vendor Atmel.

Some of the members of Atmel's DataFlash (TM, etc.) family have a feature called "sector lockdown". (An example datasheet is here).

Once you lock down a sector, it can never be unlocked, or erased or written again.

This sounds great in principle for things like boot sectors. But, let's look at the implementation.

For one thing, there doesn't seem to be any protection on the locking of sectors. Locking a sector is accomplished by a simple command, which is very similar to any other command which is sent to the flash. Sector locking even works when the part is "write protected" via hardware. (Obviously, only good guys would ever write the bits which disallow the writing of other bits, so there is no need to write-protect those lockdown bits.)

Let's examine a few basic usage scenarios for a flash device such as this:

1. Deeply embedded. When an adversary cannot send any commands to the flash, the sector locking is a no-op, except that a hardware or software error could inadvertently issue the command and render the flash useless. Slight disadvantage to sector locking.
   
2. Write-once boot device. In this scenario, the sector locking might be handy. On the other hand, there is a hardware pin which will disallow writes, so sector locking only adds marginal functionality.
3. Upgradeable boot device, no external recovery mechanism. Sector locking the recovery sector seems like a good idea. However, as with the write-once boot device, there is already a hardware mechanism available. And, if a third party can issue commands to write other sectors, they can now issue the sector locking command on those other sectors! So, they may not be able to change the recovery sector, but they can disallow the recovery code from ever writing to the rest of the flash.
4. Upgradeable boot device with an external recovery mechanism (or non-boot device.) If the device is not required for booting, or if it can be written via JTAG or some other mechanism even if the unit it is embedded in cannot otherwise boot, then, before sector locking, malicious code could always be removed. After sector locking, malicious code can lock itself in until the device is disassembled and the flash is desoldered and replaced.
   

Maybe Atmel is rooting for the bad guys, so they can sell more replacement flashes. Or maybe there is some hidden way where this actually works out OK. I don't know because I'm not really a security guy, but it looks like an obvious hole to me after 10 seconds with the datasheet, and a full read of the datasheet didn't explain why it really might be a good idea, so for now, I'm assuming it's a horrible idea and chalking it up to another example of marketing run amok.

That's too bad, because Atmel has some good products. I have to assume that Atmel has at least one person smart enough to recognize this for the looming disaster it appears to be, so their management must not be doing a very good job of listening to the troops.