28 November 2007
Not that Nick Brown
OK, so I googled myself, and I was second on the list. I'm not this Nick Brown (PHP is more my style than ASP). And I'm definitely not this Nick Brown.
What to ask Santa to bring you
If you're interested in why software goes wrong - and anyone who uses a computer for anything more than reading the occasional e-mail should be - then there are a couple of classic books you should have read by, say, December 30.
The first, little-known but very accessible, is "Digital Woes: Why We Should Not Depend on Software" by Lauren Ruth Wiener. This is about 14 years old and hardly mentions the Internet (!), but it is extremely readable and gives a good insight into the organisational issues around software projects. Anyone who buys software or IT services, and especially anyone who is the business owner of an IT project, should have read this book thoroughly before the salesperson from EDS, CSC, or IBM drops by.
If you're in software development, you could then move on to the daddy of all books on writing software, "The Mythical Man-Month: Essays on Software Engineering" by Frederick P. Brooks. Although most people under 40 will struggle to understand some of the technical references, and some of the suggestions have been made obsolete by hardware improvements, the general principles of how software development works are still as valid as they were 32 years ago when the first edition of the book appeared. My favourite quote: "Adding people to a late project, makes it later". If you can get your pointy-haired boss to understand that, you're half-way there.
The first, little-known but very accessible, is "Digital Woes: Why We Should Not Depend on Software" by Lauren Ruth Wiener. This is about 14 years old and hardly mentions the Internet (!), but it is extremely readable and gives a good insight into the organisational issues around software projects. Anyone who buys software or IT services, and especially anyone who is the business owner of an IT project, should have read this book thoroughly before the salesperson from EDS, CSC, or IBM drops by.
If you're in software development, you could then move on to the daddy of all books on writing software, "The Mythical Man-Month: Essays on Software Engineering" by Frederick P. Brooks. Although most people under 40 will struggle to understand some of the technical references, and some of the suggestions have been made obsolete by hardware improvements, the general principles of how software development works are still as valid as they were 32 years ago when the first edition of the book appeared. My favourite quote: "Adding people to a late project, makes it later". If you can get your pointy-haired boss to understand that, you're half-way there.
11 November 2007
Throw off your mental chains
The first person to link to my blog was Steve Riley, who gets paid to "do security". It was nice of him to mention my AUTORUN.INF hack, even if he didn't recommend it (for reasons I didn't quite gather).
Anyway, while flicking through the archives of Steve's blog, I found this article which questions the whole need for anti-virus software. Yesss!
Having steered a corporate network through three major software generations over the last 17 years, without spending a penny on anti-virus software in that time, I can confirm that you don't need anti-virus software. Not just on your own PC, gentle technically-aware reader; not on your users' PCs, either.
We currently have 1800 PCs, all running XP SP2, with all users having administrator privileges, allowed to install more or less any software they want, allowed to visit most Web sites (except for a few which we've specifically blacklisted for hosting malware), and we have not had a single report that any user has lost a single byte of data to a virus, in all that time, going right back to DOS 3.3 and Digital Pathworks.
Steve tries to suggest that this approach may not be for everybody, although I suspect he's just trying to sound like he's being less radical than he is - kind of like those non-religious people who can't actually bring themselves to say that they're atheists (this is a simile, please don't write in about it). He has hit the nail on the head: if your anti-virus software doesn't ever detect anything, what use is it? Other bloggers tip-toeing around this subject, but not quite ready to fully admit their apostasy in public, are Adam Vero (who, I suspect, has become a non-believer, but - probably correctly - doesn't think his customers are ready for such a drastic step), and Aaron Margosis, who has a "lite" approach (he suggests you don't need an anti-virus if your users don't have administrator privileges).
To me, installing anti-virus software because you're afraid of viruses, is like hiring a retired, but very dumb, police officer to stand guard in your home 24/7 because you're afraid of burglars. Every time any member of your family tries to move from one room to another, they get asked for ID. No ID, no place at the dinner table. And because your oldest kid's name is "Lexy" (geddit?), she gets extra-special treatment: a strip-search every morning when she gets up, to make sure she didn't get converted into a burglar during the night.
I wouldn't object so much, if viruses were even 1% as terrible things as people make out. I know users who would rather have a sudden, unrecoverable, scrape-the-platters hard drive crash, than the idea that any form of worm, virus, or trojan is on their PC. Strange, since pretty much the worst a virus can do is trash all your data (yes yes, I know it could e-mail your grocery list to some randomly-selected guy in Latvia), which is the same thing, and oh yes, modern viruses don't do that. In fact they don't do very much damage to their "host" PC; if they did, rather less that 25% of the world's PCs would be in botnets, because their owners would have noticed and done something about it.
The only bits of malware to have caused significant disruption to our network were the "MS-Blast" and "Sasser" worms. And guess what? Because they exploited a vulnerability in Microsoft's DLLs, anti-virus software didn't work (except, perhaps, to clean them up, which in any case was a one-line registry entry). People flooded to their anti-virus vendor's site, to be told "get the security patches from Microsoft". You paid the cop every day for a year, but he couldn't protect you from a burglar who wore a very small mask.
Talking of disk crashes: we change between 3% and 5% of our PC hard drives every year. We try to get to at least half of them before they die (by monitoring certain disk-related system events), but we know that of the 1800 PCs on our network, about 35 will experience sudden and irreversible disk death. We don't worry too much, because our users keep all their important data (by definition) on network drives. But if users do want to keep data locally, the backups which they make (!) are also useful protection against the day when the evil mega-virus makes the inter-species crossover (the one from "Hollywood" or "the marketing department of anti-virus companies" to "the real world").
So, put up the built-in Windows firewall (just in case the next exploit worm gets on to your Intranet), run some daily checks of the key parts of the registry (I'll write up how we do this, one day), submit suspicious files to VirusTotal (on average, after a week, one-third of the virus engines used by that site still don't detect any given virus, in my experience), build your PCs with a separate disk partition which you can boot to clean up malware in the main partition, and above all, stop worrying. You will get some viruses, worms, and trojans on your network, and they won't kill you. In fact, chances are you already do have several bits of malware anyway, because you're trusting that dumb cop to protect you, and he can't recognise 1/3 of the burglars.
Anyway, while flicking through the archives of Steve's blog, I found this article which questions the whole need for anti-virus software. Yesss!
Having steered a corporate network through three major software generations over the last 17 years, without spending a penny on anti-virus software in that time, I can confirm that you don't need anti-virus software. Not just on your own PC, gentle technically-aware reader; not on your users' PCs, either.
We currently have 1800 PCs, all running XP SP2, with all users having administrator privileges, allowed to install more or less any software they want, allowed to visit most Web sites (except for a few which we've specifically blacklisted for hosting malware), and we have not had a single report that any user has lost a single byte of data to a virus, in all that time, going right back to DOS 3.3 and Digital Pathworks.
Steve tries to suggest that this approach may not be for everybody, although I suspect he's just trying to sound like he's being less radical than he is - kind of like those non-religious people who can't actually bring themselves to say that they're atheists (this is a simile, please don't write in about it). He has hit the nail on the head: if your anti-virus software doesn't ever detect anything, what use is it? Other bloggers tip-toeing around this subject, but not quite ready to fully admit their apostasy in public, are Adam Vero (who, I suspect, has become a non-believer, but - probably correctly - doesn't think his customers are ready for such a drastic step), and Aaron Margosis, who has a "lite" approach (he suggests you don't need an anti-virus if your users don't have administrator privileges).
To me, installing anti-virus software because you're afraid of viruses, is like hiring a retired, but very dumb, police officer to stand guard in your home 24/7 because you're afraid of burglars. Every time any member of your family tries to move from one room to another, they get asked for ID. No ID, no place at the dinner table. And because your oldest kid's name is "Lexy" (geddit?), she gets extra-special treatment: a strip-search every morning when she gets up, to make sure she didn't get converted into a burglar during the night.
I wouldn't object so much, if viruses were even 1% as terrible things as people make out. I know users who would rather have a sudden, unrecoverable, scrape-the-platters hard drive crash, than the idea that any form of worm, virus, or trojan is on their PC. Strange, since pretty much the worst a virus can do is trash all your data (yes yes, I know it could e-mail your grocery list to some randomly-selected guy in Latvia), which is the same thing, and oh yes, modern viruses don't do that. In fact they don't do very much damage to their "host" PC; if they did, rather less that 25% of the world's PCs would be in botnets, because their owners would have noticed and done something about it.
The only bits of malware to have caused significant disruption to our network were the "MS-Blast" and "Sasser" worms. And guess what? Because they exploited a vulnerability in Microsoft's DLLs, anti-virus software didn't work (except, perhaps, to clean them up, which in any case was a one-line registry entry). People flooded to their anti-virus vendor's site, to be told "get the security patches from Microsoft". You paid the cop every day for a year, but he couldn't protect you from a burglar who wore a very small mask.
Talking of disk crashes: we change between 3% and 5% of our PC hard drives every year. We try to get to at least half of them before they die (by monitoring certain disk-related system events), but we know that of the 1800 PCs on our network, about 35 will experience sudden and irreversible disk death. We don't worry too much, because our users keep all their important data (by definition) on network drives. But if users do want to keep data locally, the backups which they make (!) are also useful protection against the day when the evil mega-virus makes the inter-species crossover (the one from "Hollywood" or "the marketing department of anti-virus companies" to "the real world").
So, put up the built-in Windows firewall (just in case the next exploit worm gets on to your Intranet), run some daily checks of the key parts of the registry (I'll write up how we do this, one day), submit suspicious files to VirusTotal (on average, after a week, one-third of the virus engines used by that site still don't detect any given virus, in my experience), build your PCs with a separate disk partition which you can boot to clean up malware in the main partition, and above all, stop worrying. You will get some viruses, worms, and trojans on your network, and they won't kill you. In fact, chances are you already do have several bits of malware anyway, because you're trusting that dumb cop to protect you, and he can't recognise 1/3 of the burglars.
31 October 2007
Removing files which "just won't go away"
A standard way to remove many forms of malware is to remove the registry entry which autoruns them. For example, you might have an entry called windows auto update in HKLM\Software\Microsoft\Windows\CurrentVersion\Run with a value of Activexdebugger32.exe. Once you've determined this executable to be malware, you delete this registry entry, kill the process, delete the executable, and you're done.
But hold on... just refresh the view of HKLM\Software\Microsoft\Windows\CurrentVersion\Run and check that the entry really disappeared. If it didn't, you have some form of self-protecting malware. It could be a real rootkit, a pseudo-rootkit, or just a couple of buddy processes which look after each others' backs.
I won't go into the world of rootkits very far here, except to say that I've yet to see a single example in the flesh of what I would call a real rootkit - that is, one which runs before the OS loader and controls everything. All the ones we've had to deal with on our site are pseudo-rootkits, with the "cloaking" - intercepting API calls and returning fake information to make it look as if the malware isn't there - being done by a boot-time service.
The "buddy processes" which I mentioned might take the form of two or more standard processes, or perhaps a standard malware process plus a DLL loaded at boot (or logon) time, for example via HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify. These processes form a kind of "Whack-a-Mole" game; if you kill one, its buddy pops up another. Killing both simultaneously is hard, and killing Winlogon is generally not a good idea anyway.
Anyway, let's say that you have a file like %SystemRoot%\System32\NTOS.EXE which you can't delete or rename, or that you've used Rootkit Revealer and found a pseudo-rootkit using a driver/service file called %SystemRoot%\System32\drivers\ynhqttqd.sys which you can't even see. You have a couple of choices to get rid of them.
You could boot a different OS copy: from a CD, a memory stick, a separate hard disk partition, a separate hard disk altogether (maybe take the infected PC's disk to a different PC), or even MS-DOS 7.0 from diskette with NTFSDOS Pro, depending on how macho you are. Then go in while the system is under "general anaesthetic" and delete the offending files. You can clean up the registry entries which run the malware once you've rebooted.
If you can't do that - notably, if the PC is "far" away, defined as "further than you're prepared to walk", or if the PC can't be rebooted until midnight and you don't want to be around then - you can have Windows rename the files for you at the next reboot. To do this, we're going to use a registry value which is also used by software installation and patch operations, called PendingFileRenameOperations, which lives in the key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. This is a value whose type is REG_MULTI_SZ, which for our purposes means "a list of strings".
Each element of PendingFileRenameOperations consists of a pair of strings. The first is a full path name to a file, with a bit of magic at the start of it; the second is the name name and extension (only) for the file. Here's a sample REGINI file:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
PendingFileRenameOperations = REG_MULTI_SZ \
"\??\C:\WINDOWS\System32\ntos.exe" "ntos.exe_x" \
"\??\C:\WINDOWS\System32\drivers\ynhqttqd.sys" "ynhqttqd.sys_x" \
I have no idea what the backslash and two question marks are for at the start of the full path name, but I suggest you leave them in. The backslashes at the end of each line say "we're not done yet" (there's a blank line at the end of the file to say "now we are"). If you use a different command-line tool (other than REGINI) to edit your registry, adjust the syntax appropriately.
Now, when you apply this registry change and reboot, Windows will perform the equivalent of the following good old-fashionedDOS boxcommand prompt commands:
REN "C:\WINDOWS\System32\ntos.exe" "ntos.exe_x"
REN "C:\WINDOWS\System32\drivers\ynhqttqd.sys" "ynhqttqd.sys_x"
Because this happens really early in the boot process, it's more or less guaranteed to work. (Only a "true" rootkit, running under the OS loader, would prevent it, I think.) About the only thing that might go wrong is if the target filename already exists, which can happen if you didn't clean up after a previous attack. So your first task whern the PC reboots is to delete the various .EXE_X and .SYS_X files.
But hold on... just refresh the view of HKLM\Software\Microsoft\Windows\CurrentVersion\Run and check that the entry really disappeared. If it didn't, you have some form of self-protecting malware. It could be a real rootkit, a pseudo-rootkit, or just a couple of buddy processes which look after each others' backs.
I won't go into the world of rootkits very far here, except to say that I've yet to see a single example in the flesh of what I would call a real rootkit - that is, one which runs before the OS loader and controls everything. All the ones we've had to deal with on our site are pseudo-rootkits, with the "cloaking" - intercepting API calls and returning fake information to make it look as if the malware isn't there - being done by a boot-time service.
The "buddy processes" which I mentioned might take the form of two or more standard processes, or perhaps a standard malware process plus a DLL loaded at boot (or logon) time, for example via HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify. These processes form a kind of "Whack-a-Mole" game; if you kill one, its buddy pops up another. Killing both simultaneously is hard, and killing Winlogon is generally not a good idea anyway.
Anyway, let's say that you have a file like %SystemRoot%\System32\NTOS.EXE which you can't delete or rename, or that you've used Rootkit Revealer and found a pseudo-rootkit using a driver/service file called %SystemRoot%\System32\drivers\ynhqttqd.sys which you can't even see. You have a couple of choices to get rid of them.
You could boot a different OS copy: from a CD, a memory stick, a separate hard disk partition, a separate hard disk altogether (maybe take the infected PC's disk to a different PC), or even MS-DOS 7.0 from diskette with NTFSDOS Pro, depending on how macho you are. Then go in while the system is under "general anaesthetic" and delete the offending files. You can clean up the registry entries which run the malware once you've rebooted.
If you can't do that - notably, if the PC is "far" away, defined as "further than you're prepared to walk", or if the PC can't be rebooted until midnight and you don't want to be around then - you can have Windows rename the files for you at the next reboot. To do this, we're going to use a registry value which is also used by software installation and patch operations, called PendingFileRenameOperations, which lives in the key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. This is a value whose type is REG_MULTI_SZ, which for our purposes means "a list of strings".
Each element of PendingFileRenameOperations consists of a pair of strings. The first is a full path name to a file, with a bit of magic at the start of it; the second is the name name and extension (only) for the file. Here's a sample REGINI file:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
PendingFileRenameOperations = REG_MULTI_SZ \
"\??\C:\WINDOWS\System32\ntos.exe" "ntos.exe_x" \
"\??\C:\WINDOWS\System32\drivers\ynhqttqd.sys" "ynhqttqd.sys_x" \
I have no idea what the backslash and two question marks are for at the start of the full path name, but I suggest you leave them in. The backslashes at the end of each line say "we're not done yet" (there's a blank line at the end of the file to say "now we are"). If you use a different command-line tool (other than REGINI) to edit your registry, adjust the syntax appropriately.
Now, when you apply this registry change and reboot, Windows will perform the equivalent of the following good old-fashioned
REN "C:\WINDOWS\System32\ntos.exe" "ntos.exe_x"
REN "C:\WINDOWS\System32\drivers\ynhqttqd.sys" "ynhqttqd.sys_x"
Because this happens really early in the boot process, it's more or less guaranteed to work. (Only a "true" rootkit, running under the OS loader, would prevent it, I think.) About the only thing that might go wrong is if the target filename already exists, which can happen if you didn't clean up after a previous attack. So your first task whern the PC reboots is to delete the various .EXE_X and .SYS_X files.
25 October 2007
Protecting your memory stick
If, for some petty corporate reason like "they don't allow me to change the registry", you can't apply the little hack I wrote about on 23 October, then you can at least protect your memory stick itself. This is also useful if you're lending your stick out to someone who will use it in more than one PC and don't want them catching, then transferring viruses (and blaming you, loudly, to their hosts).
All you do is open the memory stick and create a new folder called AUTORUN.INF. This should prevent most worms/viruses from creating a file of the same name, because when the worm sets out to create this file, it will probably use Windows file system calls which either delete, or truncate to zero, any existing regular file with that name; but those calls don't work for folders. (Of course, now I've blown the secret, I expect the virus writers will add code to do just that. So keep this one to yourself...)
All you do is open the memory stick and create a new folder called AUTORUN.INF. This should prevent most worms/viruses from creating a file of the same name, because when the worm sets out to create this file, it will probably use Windows file system calls which either delete, or truncate to zero, any existing regular file with that name; but those calls don't work for folders. (Of course, now I've blown the secret, I expect the virus writers will add code to do just that. So keep this one to yourself...)
23 October 2007
Memory stick worms
Lately, we've been seeing a lot of worms, and even some genuine viruses (*), coming into our network via USB memory sticks (aka "pen drives"). For those of us who remember the first MS-DOS viruses, which spread almost exclusively via diskette, it's rather nostalgic.
The culprit, of course, is Microsoft's desire to make things "simple" - meaning "automatic" - for Joe Sixpack; there's a fundamental incompatibility between a home entertainment system, which Windows has become, and an operating system for getting work done. (Here's a rule of thumb for you: any time you see stuff which starts without the user asking it to, look for malware to pop up in short order.)
These worms pretty much all reproduce the same way, at least in terms of how they jump to and from PCs. They have an AUTORUN.INF file and an executable of some kind. When you put the stick in the PC, Windows finds AUTORUN.INF "automagically". You can find documentation of some of the possible things which this file can do, but basically, the worm version will either run the executable immediately, or modify the Windows Explorer default behaviour so that the worm will run as soon as you open the stick by double-clicking on it. The executable will make a copy of itself and AUTORUN.INF on all the disk partitions and shared drive connections which it can see, and then open the root folder normally. (This takes a fraction of a second, but you won't notice it.) The executable will then sit around in memory and every time you insert a removable storage volume (such as another memory stick) or map a network drive, it will copy the worm "kit" to it.
Sometimes the executable will live in a fake \RECYCLED folder, which is quite clever because hardly anyone ever opens the recycle bin on a memory stick, and because the folder doesn't contain a real recycle bin structure, the worm will be safe, even if you empty the bin while the stick is in the drive.
Now, in theory you can prevent certain drive types from executing the contents of their AUTORUN.INF files using a registry value (NoDriveTypeAutoRun). But this is hard to do in practice. First, it's a per-user key, which in a corporate environment is harder to manipulate reliably than a per-PC key. Secondly, there are several bugs known for it. And thirdly, a little-known registry key called MountPoints2 contains cached information about every memory stick or other removable device which your PC has ever seen, and that overrides the NoDriveTypeAutoRun value if you insert a volume which the PC already knows about.
The only solution I could find from Microsoft is typically light and nimble: prevent all USB storage from running. This is fine if the aim is to stop people using memory sticks altogether, but didn't you just have a 4GB stick custom-printed for everyone in the company, and tell them to make their own backups on it?
Anyway, there seems to be a solution: a one-shot, quick way to prevent AUTORUN.INF files from being used on a PC, from any medium. My colleague and fellow low-budget Windows hacker Emin Atac thought up the idea, and I spent all of 15 minutes testing it. Now it's your turn (well, "the world is our beta site" works well enough as a corporate mantra for Microsoft).
All you do is to copy these three lines into a file called NOAUTRUN.REG (or anything.REG) and double-click it. Corporate network people can transform it into a script for their favourite command-line registry manipulator, or maybe make it a system policy thingy.
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
This hack tells Windows to treat AUTORUN.INF as if it were a configuration file from a pre-Windows 95 application. IniFileMapping is a key which tells Windows how to handle the .INI files which those applications typically used to store their configuration data (before the registry existed). In this case it says "whenever you have to handle a file called AUTORUN.INF, don't use the values from the file. You'll find alternative values at HKEY_LOCAL_MACHINE\SOFTWARE\DoesNotExist." And since that key, er, does not exist, it's as if AUTORUN.INF is completely empty, and so nothing autoruns, and nothing is added to the Explorer double-click action. Result: worms cannot get in - unless you start double-clicking executables to see what they do, in which case, you deserve to have your PC infected.
The only downside of this is that if you insert a CD with software on it, you have to explore it by hand to find the setup program. Of course, if that means your kids install less software, that could also be considered an upside.
If you want to check that the registry settings of this hack are in place, open Regedit, walk down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping, and you should see something like this:
(*) If you don't know the difference, Wikipedia is (probably) your friend.
The culprit, of course, is Microsoft's desire to make things "simple" - meaning "automatic" - for Joe Sixpack; there's a fundamental incompatibility between a home entertainment system, which Windows has become, and an operating system for getting work done. (Here's a rule of thumb for you: any time you see stuff which starts without the user asking it to, look for malware to pop up in short order.)
These worms pretty much all reproduce the same way, at least in terms of how they jump to and from PCs. They have an AUTORUN.INF file and an executable of some kind. When you put the stick in the PC, Windows finds AUTORUN.INF "automagically". You can find documentation of some of the possible things which this file can do, but basically, the worm version will either run the executable immediately, or modify the Windows Explorer default behaviour so that the worm will run as soon as you open the stick by double-clicking on it. The executable will make a copy of itself and AUTORUN.INF on all the disk partitions and shared drive connections which it can see, and then open the root folder normally. (This takes a fraction of a second, but you won't notice it.) The executable will then sit around in memory and every time you insert a removable storage volume (such as another memory stick) or map a network drive, it will copy the worm "kit" to it.
Sometimes the executable will live in a fake \RECYCLED folder, which is quite clever because hardly anyone ever opens the recycle bin on a memory stick, and because the folder doesn't contain a real recycle bin structure, the worm will be safe, even if you empty the bin while the stick is in the drive.
Now, in theory you can prevent certain drive types from executing the contents of their AUTORUN.INF files using a registry value (NoDriveTypeAutoRun). But this is hard to do in practice. First, it's a per-user key, which in a corporate environment is harder to manipulate reliably than a per-PC key. Secondly, there are several bugs known for it. And thirdly, a little-known registry key called MountPoints2 contains cached information about every memory stick or other removable device which your PC has ever seen, and that overrides the NoDriveTypeAutoRun value if you insert a volume which the PC already knows about.
The only solution I could find from Microsoft is typically light and nimble: prevent all USB storage from running. This is fine if the aim is to stop people using memory sticks altogether, but didn't you just have a 4GB stick custom-printed for everyone in the company, and tell them to make their own backups on it?
Anyway, there seems to be a solution: a one-shot, quick way to prevent AUTORUN.INF files from being used on a PC, from any medium. My colleague and fellow low-budget Windows hacker Emin Atac thought up the idea, and I spent all of 15 minutes testing it. Now it's your turn (well, "the world is our beta site" works well enough as a corporate mantra for Microsoft).
All you do is to copy these three lines into a file called NOAUTRUN.REG (or anything.REG) and double-click it. Corporate network people can transform it into a script for their favourite command-line registry manipulator, or maybe make it a system policy thingy.
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
This hack tells Windows to treat AUTORUN.INF as if it were a configuration file from a pre-Windows 95 application. IniFileMapping is a key which tells Windows how to handle the .INI files which those applications typically used to store their configuration data (before the registry existed). In this case it says "whenever you have to handle a file called AUTORUN.INF, don't use the values from the file. You'll find alternative values at HKEY_LOCAL_MACHINE\SOFTWARE\DoesNotExist." And since that key, er, does not exist, it's as if AUTORUN.INF is completely empty, and so nothing autoruns, and nothing is added to the Explorer double-click action. Result: worms cannot get in - unless you start double-clicking executables to see what they do, in which case, you deserve to have your PC infected.
The only downside of this is that if you insert a CD with software on it, you have to explore it by hand to find the setup program. Of course, if that means your kids install less software, that could also be considered an upside.
If you want to check that the registry settings of this hack are in place, open Regedit, walk down to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping, and you should see something like this:
(*) If you don't know the difference, Wikipedia is (probably) your friend.
Subscribe to:
Posts (Atom)
